Sign in to follow this  

Alternatives to DXT texture compression

This topic is 4019 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 ?

Share this post


Link to post
Share on other sites
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....

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by osmanb
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.
Don`t get me wrong, I just tend to compress everything that is compressable (I have all my meshes heavilly compressed (10-12 bytes per vertex (position,normal,UV)) and decompressed in VS). I love DXT since it allows me to use 8 times (4 times) more textures. Especially with texture atlases, if you manage to fit everything into 4096x4096, it takes just ~11 MB (with mipmaps), so if you plan your levels/art around this limitation, you can get away without texture switching for level rendering or with occasional reloading of new texture atlas.

BTW, on newest cards, is the highest resolution of textures still just 4096x4096 ? Because, having one 8192x8192 (32 MB at DXT1) would be enough for me for everything. Though, I wonder if that didn`t somehow slow it down due to bandwidth (not sure how texel sampling is implemented in HW).

Quote:
Original post by osmanb
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.
I was just trying to find out if there isn`t some development in this area, so that next generation of cards would bring new and better compression. Apparently, not yet.

Now, if we had free JPG2000 HW texture compression (instead of DXT), that would be something !

Share this post


Link to post
Share on other sites
Quote:
Original post by quasty
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?


For a description of the problem with using DXT to compress a 'traditional' normal map, and how the DXT5 alpha block trick works, check this paper:
http://developer.nvidia.com/object/bump_map_compression.html

BTW: there are of course other ways to store your normals now that there is more processing oomph available in the pixel shader (like storing slopes instead of vectors).

Share this post


Link to post
Share on other sites
Quote:
Original post by quasty
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?

Palletted textures would work better, but IIRC support for them is being phased out. [sad]

Share this post


Link to post
Share on other sites
Quote:
Original post by VladR
BTW, on newest cards, is the highest resolution of textures still just 4096x4096 ? Because, having one 8192x8192 (32 MB at DXT1) would be enough for me for everything.

G80 supports 8192x8192 textures but more importantly, it supports texture arrays - very much negating the need for atlasing. These are exposed in OpenGL via an extension or in D3D10.

Quote:
Original post by osmanb
Now, if we had free JPG2000 HW texture compression (instead of DXT), that would be something !

JPEG is actually a pretty bad compressor for 3D graphics since it makes many perceptually assumptions that do not hold when the texture is warped and modulated with lighting, etc. Indeed they look rather terrible. JP2000 may be better, but I doubt it, simply due to its target usage cases.

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTX
G80 supports 8192x8192 textures but more importantly, it supports texture arrays - very much negating the need for atlasing. These are exposed in OpenGL via an extension or in D3D10.
That`s good to know. Thanks.

Quote:
Original post by AndyTX
JPEG is actually a pretty bad compressor for 3D graphics since it makes many perceptually assumptions that do not hold when the texture is warped and modulated with lighting, etc. Indeed they look rather terrible. JP2000 may be better, but I doubt it, simply due to its target usage cases.
Somehow I don`t see why JPG textures should be terrible for regular 3d meshes. JP2000 takes much less space with same quality. Now, they might not be good for 2D games, but noticing JPG artifacts (when quality is set to 90%-100%) in a game scenario is next to impossible.
Take a look at at Gears Of War, that`s considered best next-gen graphics. No lossless texture compression technique can help it when several objects with different texture resolution are combined into one (e.g. pillars/walls/door). What you see, is huge disproportion among texel resolution. That`s pretty far from JPG artifacts.

Share this post


Link to post
Share on other sites

This topic is 4019 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this