Alternatives to DXT texture compression
Author
I`m using the DXT compression heavilly, but I wondered if there isn`t something even better (haven`t spotted anything else in DirectX).
Or maybe there`s some other way around this ? I once noticed a texture decompression pixel shader discussion somewhere, but this has got to be slow since it`s not HW implemented, it`s just a shader.
So are we going to be stuck with DXT forever, or is there something else that I`m unaware of ?
I wont be able to help you, but as far as i know, shaders are always run on hardware, so shaders wont be as slow as running something on software, unless DX somehow emulates shaders on software. That, i do not know.
Also, at humus.ca there was a 3D Demo showing texture compression, but i dunno if its for GL or DX or both....
Also, at humus.ca there was a 3D Demo showing texture compression, but i dunno if its for GL or DX or both....
Some textures are suitable for run-time procedural generation, and can be made much smaller with the right tools. Check out Allegorithmic's stuff.
The advantage of using hardware-supported compression formats is that they *stay* compressed in hardware; i.e. they save bandwidth when doing texture reads and so forth.
You can of course implement your own compression schemes using shaders and the like, but you won't get that bandwidth savings. Unfortunately for those advantages we're "stuck" with the hardware supported formats right now.
You can of course implement your own compression schemes using shaders and the like, but you won't get that bandwidth savings. Unfortunately for those advantages we're "stuck" with the hardware supported formats right now.
Indeed, the Allegorithmic stuff is only useful if you are constrained by resource file size limits. They even have a library for converting the procedural textures to standard DXT textures once they have been read in from the disc or network.
Quote:Original post by AndyTX
The advantage of using hardware-supported compression formats is that they *stay* compressed in hardware; i.e. they save bandwidth when doing texture reads and so forth.
You can of course implement your own compression schemes using shaders and the like, but you won't get that bandwidth savings. Unfortunately for those advantages we're "stuck" with the hardware supported formats right now.
Yes, you are right, but they only stay compressed in VRAM not the cache. AFAIK on modern cards, DXT1 is the only format which actually stays compressed in the cache as well.
Cheers,
Tom.
What exactly don't you like about DXT? That might help people with suggesting alternatives. Overally, the various DXT formats (including some of the newer non-standard variants) are pretty good general purpose formats. They do have drawbacks, but understanding those limitations is the biggest step towards avoiding "bad" textures.
Some people really like VQ (vector quantization) methods, but recent hardware doesn't support that anymore. You can implement it yourself, but then you're back to having methods that aren't HW supported, so you lose lots of bandwidth and cache benefit. You also have to do the decompression yourself. It isn't hard, but it's still more expensive than "free", which is what it costs with DXT.
If you're looking for something that's compressed more than DXT ... I don't think you're going to find much, without sacrificing quite a bit of quality. At 4bpp, DXT1 is fairly small.
If you're looking for something that looks better at similar ratios (4bpp or 8bpp), then it depends on your art. In some cases, palettized textures will look better. Notably, if high frequency detail is important and you don't have a huge number of unique colors. On some console platforms, this is really your only choice ... on some newer platforms you can't really do this at all (unless emulated through shaders).
Some people really like VQ (vector quantization) methods, but recent hardware doesn't support that anymore. You can implement it yourself, but then you're back to having methods that aren't HW supported, so you lose lots of bandwidth and cache benefit. You also have to do the decompression yourself. It isn't hard, but it's still more expensive than "free", which is what it costs with DXT.
If you're looking for something that's compressed more than DXT ... I don't think you're going to find much, without sacrificing quite a bit of quality. At 4bpp, DXT1 is fairly small.
If you're looking for something that looks better at similar ratios (4bpp or 8bpp), then it depends on your art. In some cases, palettized textures will look better. Notably, if high frequency detail is important and you don't have a huge number of unique colors. On some console platforms, this is really your only choice ... on some newer platforms you can't really do this at all (unless emulated through shaders).
Is it safe to compress a tangent space normal map with DXT or is it possibly "dangerous"? These maps are mostly blue - they can be probably compressed very efficiently, can they?
Wikipedia says
Quote:
The notable exception is the compression of normal map data, which usually results in annoyingly visible artifacts. ATI's 3Dc compression algorithm is a modification of DXT5 designed to overcome S3TC's shortcomings in this area.
DXT will make a mess of your normal maps, which is why ATI designed 3dc compression as an alternative.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
