Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Texture compression DDS / S3TC


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
14 replies to this topic

#1 spek   Prime Members   -  Reputation: 997

Like
0Likes
Like

Posted 15 September 2011 - 06:56 AM

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?

Sponsor:

#2 Vilem Otte   Crossbones+   -  Reputation: 1567

Like
3Likes
Like

Posted 15 September 2011 - 10:29 AM

Lower quality


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)??


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?


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?


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

Or does OpenGL / GPU convert the data?


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)



My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com


#3 MJP   Moderators   -  Reputation: 11781

Like
1Likes
Like

Posted 15 September 2011 - 12:18 PM

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.

#4 spek   Prime Members   -  Reputation: 997

Like
0Likes
Like

Posted 15 September 2011 - 12:44 PM

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?

#5 Vilem Otte   Crossbones+   -  Reputation: 1567

Like
0Likes
Like

Posted 15 September 2011 - 12:54 PM

Sorry for forgetting to mail you a year ago. It suddenly got so busy with people offering help on T22


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?


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.


My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com


#6 MJP   Moderators   -  Reputation: 11781

Like
0Likes
Like

Posted 15 September 2011 - 03:11 PM

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

#7 Martins Mozeiko   Crossbones+   -  Reputation: 1422

Like
0Likes
Like

Posted 15 September 2011 - 03:43 PM

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.

#8 MJP   Moderators   -  Reputation: 11781

Like
0Likes
Like

Posted 15 September 2011 - 05:19 PM

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

#9 spek   Prime Members   -  Reputation: 997

Like
0Likes
Like

Posted 15 September 2011 - 11:39 PM

Right! I'm locked and loaded now, time to implement it, and start the compressor! Thank you all

#10 Martins Mozeiko   Crossbones+   -  Reputation: 1422

Like
0Likes
Like

Posted 16 September 2011 - 01:28 AM


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

Oops! Yes, you are right. BC7 = BPTC_xyz_FLOAT, BC6H = xyz_BPTC_UNORM.

#11 spek   Prime Members   -  Reputation: 997

Like
0Likes
Like

Posted 16 September 2011 - 05:32 AM

One more question. I managed to create a DDS file now with the ATI_Compress tool. Works like a charm, but... does anyone know how to make multiple Mip-Map levels? The DDS writer in ATI_Compress_Helper only makes 1 level by default. Now I could try to make my own writer, but maybe it can be done with some easy adjustments.

Thanks
Rick




#12 MJP   Moderators   -  Reputation: 11781

Like
0Likes
Like

Posted 16 September 2011 - 01:14 PM

Compress won't generate mips, you have to generate them first and then compress each mip level individually. In our texture pipeline we generate the mips ourselves, but you could use another library to do it if you want.

#13 mhagain   Crossbones+   -  Reputation: 8281

Like
0Likes
Like

Posted 16 September 2011 - 05:07 PM

Definitely faster rendering; I've benchmarked it up to 20% faster. Quality can drop off quite badly depending on the texture you're using though; for something like lower resolution 2D GUI textures it can be unacceptable.

Make sure that you load the DDS natively and that you're not going through any software decompression/recompression stages too.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#14 360GAMZ   Members   -  Reputation: 133

Like
0Likes
Like

Posted 09 January 2012 - 03:10 AM

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


MJP, this post wasn't all that long ago, but wondering whether you've since come across a decent compression tool that supports BC6/7.

#15 MJP   Moderators   -  Reputation: 11781

Like
0Likes
Like

Posted 10 January 2012 - 12:57 AM


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


MJP, this post wasn't all that long ago, but wondering whether you've since come across a decent compression tool that supports BC6/7.


Unfortunately not. I've been meaning to look into it more, but haven't gotten around to it yet. I do have a hacked-up version of the DX GPU compressor that will do BC6H for cube maps and mip levels that's sitting on my PC at home, but that's about it.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS