Is there code available for offline compression/decompresion to/from the GL_ARB_texture_compression format?
I’m interested in distributing textures with my software in compressed format (glGetCompressedTexImageARB), but if I do so I need to decompress them manually for machines on which the extension is not available.
I know this isn’t really smart, but want to try anyway (for-fun).
If there isn’t any code publicly available, could someone provide me details on the compression scheme so I can reverse engineer it? I’ll share my code if I succeed.
If I’m understanding you correctly, I think you’re heading down the wrong track. The actual compression method used is dependant on the individual machines drivers/hardware. If you compress textures on your machine with the algorithm implemented in your driver, you may not be able to decompress it on another machine.
Texture compression is standardized and games have been distributed with precompressed textures for years. In D3D you simply use the textool to create compressed .dds files, and then everything is taken care of for you. As for OpenGL, I have never used compressed textures with it, so… you’ll have to wait for a better answer
If you have Photoshop, you can use nVidias tools to compress your textures and store them in DDS-format.
To decompress your textures manually, you might want to take a look at nVidias code, AFAIK there is open-source stuff, though i am not sure. Other than that, there are some other libraries, too. I think DevIL (formerly known as OpenIL), allows you to load DDS files. DevIL is open source, so you might find what you are looking for, in there.
All current games distribute there textures in compressed form. Today most use the DDS format, because it also decreases load-times. Also precompressing the textures can yield better quality, than using the built in compressors of the GPU.
Actually, the ARB_texture_compression extension provides an API to handle compressed textures but does not define/specify any compression format.
The most used compression formats are in the DXTC family (also known as S3TC). The compression formats are exposed by additional extensions, see for example the ‘EXT_texture_compression_s3tc’ extension.
DXTC/S3TC is supported by all NVidia/ATI cards at least since GeForce 1 I think. I’m not familiar with other platforms but it really is the most used compression format nowadays.
Also, just to eliminate any confusion, S3TC and DXT formats are the same thing. Why/how the name changed to DXTC, I’m not sure. Perhaps because S3 is a company name?
I’m aware of what it stands for, and out of curiosity, does anyone know how it got called that? It seems kinda messed up to associate that texture compression with DirectX, when really it’s completely unrelated (other than the fact that MS exposes the hardware functionality in DX).
Is Microsoft going to start calling other texture formats DXA8R8G8B8? Maybe they should just claim IEEE standards as their own and just brand floating point numbers used by graphics cards DXFP.
remdul: Yes, it is pretty standard, but you need to query (when downloading) and supply (when uploading) the actual, internal DXTn format. That was what I referred to when I wrote it’s universally supported - there simply isn’t a 3D card+driver combo I’m aware of that handles compressed textures, but doesn’t do DXTn compression (and therefore reuse it) in OpenGL.
So while there by OpenGL specification isn’t a promise, if the hardware supports DXTn and it’s supported on Windows (at least all current consumer offerings), I’d say that if the OpenGL implemenation also supports texture compression at all it’s DXTn (there really aren’t many performant options to it).
In practice, I’d say you can depend upon it. If compression is supported, DXTn is.
Zengar: I didn’t know nvidia had released their DXT lib src. Thanks for pointing it out! (Do you have a direct URL, or is it only in the SDK? My google-fu only found mentions of it, but no direct link).
Originally posted by ebray99:
[b]Is Microsoft going to start calling other texture formats DXA8R8G8B8? Maybe they should just claim IEEE standards as their own and just brand floating point numbers used by graphics cards DXFP.
But I digress.
Kevin B [/b]
S3TC was invented by S3 and I guess they licensed it to MS which renamed it.
I’m sure they didn’t like the name S3.
It’s the usual not invented here, but brand it as MS.
Originally posted by remdul: I’m interested in distributing textures with my software in compressed format (glGetCompressedTexImageARB), but if I do so I need to decompress them manually for machines on which the extension is not available.
I know this isn’t really smart, but want to try anyway (for-fun).
There’s nothing wrong with that approach. Today all cards have supported DXTC for many generations, so coding for them and providing a decompression workaround for older cards if you care about them is perfectly acceptable practice IMHO. That’s what my framework does anyway. If you want some simple decoding code I have it in my framework: http://www.humus.ca/index.php?page=3D
It’s quite simple to decode actually, and you could easily write your own from the specification in the Appendix of GL_EXT_texture_compression_s3tc
Originally posted by remdul: I’m aware of that, but I’m trying to do that with ARB_texture_compression instead of DDS compressed textures.
DDS is perfect format for distributing compressed textures and is it’s the same compression as used in GL_EXT_texture_compression_s3tc.
Originally posted by ebray99:
[b] I’m aware of what it stands for, and out of curiosity, does anyone know how it got called that? It seems kinda messed up to associate that texture compression with DirectX, when really it’s completely unrelated (other than the fact that MS exposes the hardware functionality in DX).
Is Microsoft going to start calling other texture formats DXA8R8G8B8?[/b]
Microsoft licensed S3TC from S3. DirectX is a vendor-neutral API though, so it wouldn’t look good to call it S3TC I suppose. I guess DXTC was more natural in that context, but if it makes you any happier, in DX10 it’s not called DXTC anymore, but BC (as in Block Compression). Basically:
DXT1 -> BC1
DXT3 -> BC2
DXT5 -> BC3
ATI1N -> BC4
ATI2N -> BC5
Originally posted by tamlin:
[b]So while there by OpenGL specification isn’t a promise, if the hardware supports DXTn and it’s supported on Windows (at least all current consumer offerings), I’d say that if the OpenGL implemenation also supports texture compression at all it’s DXTn (there really aren’t many performant options to it).
In practice, I’d say you can depend upon it. If compression is supported, DXTn is.[/b]
Let’s not make it harder than it is. Just check for GL_EXT_texture_compression_s3tc instead of GL_ARB_texture_compression. Problem solved. If GL_EXT_texture_compression_s3tc is supported you can supply precompressed textures in S3TC format, otherwise you cannot.
No. ARB_texture_compression is a generic interface with no particular format. ARB_texture_compression alone does not mean you can use S3TC. EXT_texture_compression_s3tc is an extension on top of the ARB_texture_compression interface that exposes S3TC specifically, so that’s the extension you’re looking for.
