Common texture memory budget?

Hi, I’m working on a sprite animation system that requires 2048x2048 textures per animation.
The scene will need to display any of these animation at any time, and all those animations needs to be loaded.

How many textures can I expect to load on desktop nowadays?

A 2048x2048 texture has roughly 4 Mio. pixels. Assuming you are using regular ARGB textures, with 8 bits per channel, that’s 4 bytes per pixel. So in total that’s 16 MB for the texture. Usually you also have mipmap levels, which adds another 33%, making the texture just over 21 MB in size.

According to the Steam hardware survey the average PC on Steam has about 2GB of video memory nowadays. That’s enough for more than 90 such textures. A bit less in reality, as you can’t use every last bit of VRAM for your textures. A high-end PC will have 8+ GB.

Using texture compression you could reduce texture size by a factor of 4, or even more, depending on the format.


Thank you for this detailed answer, it’s stackoverflow quality :smile:

I didn’t know a compressed texture remains compressed once loaded in the GPU memory

Yes, most GPUs can render some format of compressed textures directly. If you set the format of your texture to Compressed in the Pipeline Tool MG will handle it for you and choose the right compression format based on the target platform (e.g. DXT on desktop). Note that texture compression isn’t lossless.

1 Like

That’s why the compressed texture formats are all block based. A 4x4 square block is friendly to the GPU’s parallelism, the value table in the block is used to look up what value to use for each pixel of the 4x4 block and that’s pretty snappy. They end up as a whole bunch of indexed color tiles.

I have tried 16bits and Compressed options, but the results aren’t good at all.




Compressed looks right except for whatever you have going on with your silhouette?

Did you compress everything, such as also compressing a normal-map? You can’t reasonably compress a normal-map for use on anything with curvature without everything going to hell (aside from using 2-channel encoding and inferring Z).

You can compress normal-maps on mostly planar surfaces without a disaster, but texture compression and normals is and probably always will be an open problem.

There is no normal map, this is just a 2d sprite, rendered using the spritebatch.

Ah, the edge issues might make sense then depending on compression. DXT1 uses 1-bit alpha which could easily do that.

DXT seems the only compression availlable on my system. Windows7/DX11

There something I should mention, my sprites only need grayscale and alpha informations.

Ideally, I’d like to process the texture from the pipeline with only an Alpha and Grayscale channels, this would make 16bits pixel without loss of information, and have the spritebatch apply a mask color; Is this possible?