Jump to content
  • Advertisement
Sign in to follow this  
spek

OpenGL Texture compression DDS / S3TC

This topic is 2446 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

Hey,

About texture compression... Never used it so far, but I just made an (OpenGL) program that loads a DDS file. So far so good, but before really implementing it in my engine, I need some good reasons. Well, what I can think of:
- No time wasted generating mip-maps
- Smaller disk size
- Smaller > Faster loading from disk
- Extra features such as cubeMap / 3D textures
- Allows to use bigger resolutions

Then on the other hand...
- Lower quality
- Slower rendering?? Or is it actually faster (less bandwidth)??

The lower quality probably depends on the compression settings I guess, and images that really need detail still can use uncompressed formats. But, how bad is the loss really? I can't really see a difference usually. But I didn't have a lot of examples.

About the performance. I've been tought, 100 years ago, that decompressing takes time. Not sure how the video-card does things, but does the decompression hit the performance? The only thing I read is that is can actually boost the performance because less bandwidth is used. In my case I have quite a lot surface textures (512 x 512, 1024 x 1024, resolutions like that).


A last question. How to calculate the video memory usage of a compressed texture? Is it equal to the amount of bytes pixeldata you read? Or does OpenGL / GPU convert the data?

Share this post


Link to post
Share on other sites
Advertisement
Lower quality[/quote]

Not necessarily, while using same space as standard texture, S3TC (DXT1) compressed one can have 8-times the size of uncompressed one actually, while still keeping very good quality - so you can actually have a lot more micro details on texture, even with a little less colors (still not too much visible difference between s3tc compressed one and uncompressed - in most cases...)

Slower rendering?? Or is it actually faster (less bandwidth)??[/quote]

Actually it is faster, less bandwidth, and also u have less memory storage.

About the performance. I've been tought, 100 years ago, that decompressing takes time. Not sure how the video-card does things, but does the decompression hit the performance?[/quote]

Actually S3TC compressions are hardware implemented on GPU, so it won't take any time more than using standard uncompressed texture.

How to calculate the video memory usage of a compressed texture?[/quote]

Memory usage = Number of pixels * Bits per pixel / Compression Ratio

Or does OpenGL / GPU convert the data?[/quote]

The good thing on S3TC compressions is that GPU still keeps them compressed in VRAM - e.g. they're actually a lot smaller than standard textures.

Note that S3TC compressions are a must for Megatextures.

Btw. I think I'm still having some S3TC compression code lying around if you would like to try encoding, but still I don't know if its patented and for how long (I wrote it just out of curiosity and I even read patent, my code is different than what they describe :P)


Share this post


Link to post
Share on other sites
In general compression is going to be a win. It can significantly ease the burden on your memory usage, and it helps with bandwidth as well. The GPU can decode them on the fly (since S3TC is designed to be very simple to decode a 4x4 block) so you don't need to worry about any added cost for the decode. You do have to be careful though with quality, for certain cases it's very easy to end up with a really crappy-looking texture once you've compressed them.

Here are some general tips. I'm going to use the D3D10/D3D11 terminology for the different compression formats, since I don't know the corresponding OpenGL names (sorry!):

1. Use a good compressor! This is key. Some are much better than others. For offline compression, I recommend using the ATI_Compress library. It's dead simple, it's multithreaded, and has great quality. We used to Nvidia texture tools at work since it's open source, but the quality was worse and it was significantly slower.

2. Have the option to opt out of compression for certain textures. You're bound to find a few cases where the hit in quality just isn't worth it...for instance anything with a really smooth gradient usually ends up being paletized pretty badly.

3. Use the right format! BC1 has the lowest memory footprint for an RGB texture, but also doesn't have an alpha channel. BC2 and BC3 do have alpha channels, with different means of encoding them (most people just stick to BC3). For monochrome textures, you'll want BC4. It has 1 hi-quality channel (basically the alpha channel from BC3). For normal maps, you'll want to use BC5 which has 2 hi-quality channels (store XY and reconstruct Z in the shader). If BC4 and BC5 aren't available on your target spec, then you can use BC3 for normal maps and put the X in the alpha channel and Y in the green channel and then reconstruct Z in the shader (those are the two channels with the most precision).

4. For color maps you can get a bit better quality by determining the min and max values in the texture, and then rescaling that range to [0, 1]. Then in the shader you use the min and max to scale it back to the normal.

5. BC6 and BC7 are really awesome (HDR, and hi-quality LDR respectively), but only available on DX11-class hardware. There's also not really any tools support for it yet. The D3DX library can encode to it, but it's super slow. There's also a sample in the SDK that does the encoding on the GPU using a compute shader, but it's pretty bare bones and doesn't support cube maps or mipmaps.

Share this post


Link to post
Share on other sites
Hey Vilem! It's been a while. Sorry for forgetting to mail you a year ago. It suddenly got so busy with people offering help on T22 :)

Thanks for the info MJP & Vilem. These arguments are good enough to put DDS support in the engine. I thought decoding would give a small hit, but having the hardware doing it for "free" is awesome.

Images with compressing quality issues can still keep using uncompressed formats. About that... asides from smooth gradients are there particular cases that have quality problems?
- Textures using the alpha channel for transparency (foliages, metal fences, ...)
- NormalMaps with small details
- Images with a lot of small details, but not varying colors (a sand texture for example)
Most of the images we're using are indoor material textures such as a concrete wall or wood floor btw.

Not sure where BC1..7 stands for. While coding a bit I came across DXT1, DXT3 and DXT5. Are those the same?

Share this post


Link to post
Share on other sites
Sorry for forgetting to mail you a year ago. It suddenly got so busy with people offering help on T22[/quote]

No problem, I watch your T22 blog from time to time and your project looks very very promising!

Not sure where BC1..7 stands for. While coding a bit I came across DXT1, DXT3 and DXT5. Are those the same?[/quote]

AFAIR BC* is naming system of Direct3D, while DXT* are names used in OpenGL:

DXT1 is actually BC1
DXT3 is actually BC3
DXT5 is actually BC5

Actually I think there are also DXT2 and DXT4 (but these aren't used commonly and I'm also not sure if GL implements them), BC6 and BC7 are new things, I think that BPTC is whats standing in OpenGL instead of BC7 in Direct3D.

Share this post


Link to post
Share on other sites
Yeah DX9 used to call them DXT* and the old OpenGL extensions also called them DXT, but in DX10 onwards they started calling them BC* (where BC stands for "block compression"). I have no idea if the names have changed with the newer (3.x - 4.x) version of OpenGL, which is why I just used the DX10 names. For quick reference:

BC1 - 5:6:5 RGB + 1bit alpha. DXT1 in DX9/GL extensions. 1:6 compression ratio
BC2 - 5:6:5 RGB + 4bit explicit alpha (better for non-coherent alpha values). DXT3 in DX9/GL extensions. 1:4 compression
BC3 - 5:6:5 RGB + 8bit interpreted alpha (better for coherent alpha values). DXT5 in DX9/GL extensions. 1:4 compression
BC4 - 8bit interpreted R, similar to the alpha from BC3. Was previously known as ATI1N in DX9, I think it was called LATC1 in GL extensions. 1:2 compression
BC5 - 8bit interpreted RG, basically just double BC4 channels. Was previously known as ATI2N in DX9, LATC2 in GL extensions. Referred to as "3Dc" in ATI marketing. 1:2 compression
BC6H - 16:16:16 floating point RGB. No idea what this is called in OpenGL.1:6 compression ratio
BC7 - 4-7bit RGB + 0-8bit alpha. Actually a combination of different encoding modes, where the best mode is chosen for each 4x4 block to best represent the data. 1:4 compression ratio

Share this post


Link to post
Share on other sites
BC4 = RED_RGTC1 in OpenGL
BC5 = RG_RGTC2 in OpenGL
from http://www.opengl.org/registry/specs/ARB/texture_compression_rgtc.txt (in Core from 3.0)

BC6H = BPTC_UNORM / SRGB_ALPHA_BPTC_UNORM
BC7 = BPTC_SIGNED_FLOAT / BPTC_UNSIGNED_FLOAT
from http://www.opengl.org/registry/specs/ARB/texture_compression_bptc.txt (in Core from 4.2)

Both extensions especially mentions compatibility with DirectX.

Share this post


Link to post
Share on other sites
Right! I'm locked and loaded now, time to implement it, and start the compressor! Thank you all

Share this post


Link to post
Share on other sites

[quote name='Martins Mozeiko' timestamp='1316122987' post='4862230']
BC6H = BPTC_UNORM / SRGB_ALPHA_BPTC_UNORM
BC7 = BPTC_SIGNED_FLOAT / BPTC_UNSIGNED_FLOAT
from http://www.opengl.or...ession_bptc.txt (in Core from 4.2)


I think these are backwards
[/quote]
Oops! Yes, you are right. BC7 = BPTC_xyz_FLOAT, BC6H = xyz_BPTC_UNORM.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!