Volume textures - performance and memory

Started by
4 comments, last by MJP 13 years, 7 months ago
Naively, even a 32-bit 256x256x256 volume texture would take up 64Mb, which to someone who was programming when GPUs were first appearing is massive. If you only had once such texture, I suppose 512^3 would fit in a GPU memory but would I be right thinking this would be a total pig?

I'd guess 3D textures use compression algorithms but how good are they? Do they extend algorithms like JPG into 3D to identify sub-volumes of similar colors, or treat the data as a set of independent 2D slices?

What are the realistic limits of volume textures, let's say on a mid-range 512Mb graphics card?

www.simulatedmedicine.com - medical simulation software

Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.

Advertisement
Anyone? I never used a volumetric texture and the potentially massive memory requirements worry me over performance as well as size limitations

www.simulatedmedicine.com - medical simulation software

Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.

I've only ever used fairly small volume textures (e.g. 8^3 to 32^3).

For something akin to standard image compression, you might find some info searching for "Volume Texture Compression" (VTC), although I've never looked into this myself so I'm not sure on the hardware support or compression ratios. I assume it will be similar to regular DXT compression (8:1 to 4:1).

For large-scale volume data-sets, you'll probably have to implement your own data-structure to use instead of a 3D array (3d texture). There's lots of literature under the term "sparse voxel octree", such as a recent presentation called "gigavoxels", which achieves real-time rendering of ridiculously huge volumetric data-sets.
Better question-- what do you need said volume texture for?
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
It's a general question really. With 2D textures I have a feel for what's going on, in terms of how large they might be, how fast, etc. But 3D textures are a new subject to me - I don't even know if they get used much in real life as regular color data, or as input to shaders, or are largely ignored.

I am roughly thinking about how you might use them for an object what has to be totally sliceable in a free-form way, but that question is only an example to help me order my curiosity.

www.simulatedmedicine.com - medical simulation software

Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.

Volume textures won't be compressed in video memory, or wherever they're stored. They'll be stored according the memory layout specified by the surface format you used when creating it. So yeah a 256x256x256 32-bit volume texture will take up 64MB, or likely even more due to padding or alignment requirements.

Volume textures do support the same block compression formats supported by 2D textures (DXT1-5 for D3D9, BC1-7 for D3D10/D3D11). So you can use that to get 4-to-1 or 8-to-1 compression ratios. You can implement your own compression format if you want, but then you'll have to manually decode in the shader (most offline image compression formats aren't suitable for this approach).

This topic is closed to new replies.

Advertisement