Mark Cass wrote:

guys,
finally have some good news. uploading DXT1, DXT3, and DXT5 compressed textures is working. i still need to implement compressed sub textures and test very small textures.
the issue was the tile size. i wrote an iterator into the driver to test all possible tile sizes and found the one that worked. well, actually two that worked. DXT1 has a different tile format than DXT3 and DXT5 which share the same format.
Nice to hear it works.

my next question involves extensions. should the GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions be enabled? the only reason i ask is that i think the complete description of the extension includes the ability for the driver to compress the textures. as was mentioned previously, adding this ability to the driver could result in legal problems as s3tc is intellectual property of S3/VIA inc.
Ian has already answered the part about GL_ARB_texture_compression.
GL_EXT_texture_compression_s3tc is a problem. You're not supposed to enable it if you can't guarantee that you can always handle the associated s3tc texture formats - and you can't guarantee that without software compression/decompression. But if you're not announcing it, nobody will use the dxt formats (even for precompressed textures) you just made to work (nwn and others will check if the extension is present). You could do what I did, don't enable the extension if software decompression/compression is unavailable per default, but make it possible to enable it via driconf. btw it's kinda ironic the extension can't be fully implemented - after all, we're talking about a Savage chip here!


Just the other day, I had some strange idea how to write a s3tc compressor which would be legally unproblematic. I _think_ the format itself cannot be patented, only the compression apparatus (which is, btw, just math, but that's not the point here).
So, use straight BTC[1] (block truncation coding)/CCC[2] (color cell compression) (there are plenty of references to these papers on the web) to compress! This works because s3tc is an improved btc/ccc, your textures would be correctly decompressionable by any s3tc decompressor.
RGB_DXT1: use CCC. Instead of two base colors and two (or one, depending on the ordering of the colors) derived colors, only use the two base colors. That's all. Of course, quality would be much lower, only 1 bit of the 2 bit index is used.
RGB_DXT3: same as RGB_DXT1 for the color part. Alpha part is no problem (just uncompressed 4bit alpha anyway).
RGB_DXT5. same as RGB_DXT1 for the color part. For alpha, use BTC (instead of 2 base values and 6 derived (or 4 derived and two fixed values, depending on the ordering of the two base values) only use the two base values. Not good quality (only 1 bit of the 3 bit index is used).
RGBA_DXT1: problematic (not straight CCC). Probably non-infringing implementation would just use only one color, the second color would be used for the transparent case. So all pixels (safe the transparent ones) would end up with the same color within a block...


Software decompresion though is a problem, if that's also covered by the patent. Using CCC/BTC would lead to errors, which could be very significant (unless you have compressed according to the above mentioned scheme, of course). In fact, in some cases the results could be completely wrong (for RGBA_DXT1, and RGBA_DXT5 at least, due to the different interpretation needed based on the ordering of the base values, which BTC/CCC decompressor would simply ignore).

Roland

[1] Image Compression Using Block Truncation Coding, Delp/Mitchell, IEEE Transactions on Communications 27: (9), 1979, pages 1335-1342
[2] Two Bit/Pixel Full Color Encoding, Campbell et al., SIGGRAPH ‘86 Conference Proceedings, Computer Graphics, Vol. 20, No. 4, August 1986, pages 215-223



------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to