alternative texture compression technology?
Author
Hi, I've recently written an applcation which uses compressed textures streamed from disk at many frames a second to a texture mapped onto a quad. I then combine multiple layers using pixel/vertex shading - thats all working great.
However, the stored compressed textures are considerably larger than the video files from which they came. I am currently using dxt1 compression, I was wondering what other options for texture compression are there? Does open gl/graphics hardware only support dxt1..5? or are other texture compression technologies supported?
Depending on your video card, NVIDIA vs ATI, different texture compression algorithms are supported. Check the appropriate website for a document outlining these. For instance this document from NVIDIA shows all supported texture formats including compressed formats for various chipsets.
Sounds like the format you are streaming from disk is more lossy, and therefor smaller, than DXT. If that is the case, there isn't much you can do.
Sounds like the format you are streaming from disk is more lossy, and therefor smaller, than DXT. If that is the case, there isn't much you can do.
Quote:Original post by dginside
I am currently using dxt1 compression, I was wondering what other options for texture compression are there? Does open gl/graphics hardware only support dxt1..5? or are other texture compression technologies supported?
Not really, unless you consider quantization a method of compression. In the sense of a "real" compressed texture format, only S3TC/DXTC1-5 are available for standard colour images. There used to be support for paletted textures (which was a pretty nice high quality compression technique), but support was limited to nVidia cards prior to the 6800.
Some other rarely used vendor dependent formats exist(ed), but those are of limited use for general purpose texture mapping.
Quote:
For instance this document from NVIDIA shows all supported texture formats including compressed formats for various chipsets.
A little offtopic - Looking at the NV44, it seems that this chipset will store RGB8 textures as unpadded 24bit values, instead of padding them up to 32bit as all previous chipsets did. That's very interesting, since it can save a lot of memory. Does this mean, that the NV44 can perform unaligned texture lookups on 3 byte texel data ?
Quote:Original post by Yann L
A little offtopic - Looking at the NV44, it seems that this chipset will store RGB8 textures as unpadded 24bit values, instead of padding them up to 32bit as all previous chipsets did. That's very interesting, since it can save a lot of memory. Does this mean, that the NV44 can perform unaligned texture lookups on 3 byte texel data ?
I don't know if you've noticed, but the "tick" mark on the specific part of the grid is coloured yellow. It may be that's just a print error, or it also could be that it isn't supported natively even though there isn't a precision substitution.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
