I have very big alphamaps where only some spots have non-black values. This makes these textures an ideal target for lossless compression. I’ve read about panda texture compression capabilities and I’m sold on the TXO format. Is it possible to achieve lossless compression in a TXO texture (like with PNG)?
Secondly, what mode should I use for maximum compatibility? I could save two files for every texture, one png and one compressed TXO, that way if the graphic card doesn’t support the compression algorithm I can use the png. But, how could I find out if the graphic card supports the TXO compression? Should I worry about this stuff at all? How common is compression support? Does Panda have something to do this safe fall-back for me? It would be cool if panda uncompressed the TXO by software when the graphic card doesn’t support the algorithm, for example…
Also, I know the TXO format isn’t guaranteed to remain the same between panda versions. But, do you really expect it to change frequently?
Sadly, no. None of the common real-time compression algorithms support a lossless compression. In fact, they’re not like the compression algorithms used by JPEG and PNG at all; they’re all based on building a unique color palette for each 8x8 (or so) region, and using a bitmask to index into that palette. This is very easy for the graphics hardware to decode at runtime, because a pixel lookup is still found at a predictable location in memory. The technique results in a loss of color resolution, and relies on the fact that in the human eye, visual perception of color has less precision than visual perception of brightness.
You can ask GraphicsStateGuardian::supports_compressed_texture_format() for a given format. But generally you don’t need to do this; Panda will do this for you automatically.
The three standard compression modes, DXT1, DXT3, and DXT5, are extremely common and practically universal these days. Even cheap integrated cards provide it. You would have to go to a very old graphics card to find one that didn’t provide support. That said, there are a few buggy drivers that ostensibly provide this compression support, but do it very poorly or slowly. Unfortunately, it’s impossible to know when you are running with such a driver, since it won’t tell you.
Panda does in fact provide this feature, when it is compiled with the squish library (as it is by default).
Realistically, no. But you should design your art pipeline as if it will, and plan to rebuild your TXO files for each new version of Panda. You should think of the TXO files in the same category as BAM files (and in fact, they really are another form of BAM file). The TXO file actually stores a Texture object in a form very close to Panda’s internal Texture object layout, so that it loads very quickly with a minimum of data reformatting; but it means the file format changes every time we change some detail of Panda’s Texture object. (As with BAM files, we make an effort to maintain backward compatibility in the loader, but we don’t guarantee to preserve this backward compatibility forever.)
Note that if all you want is to store pre-compressed textures, you can also use the DDS file format, which is something of a de facto standard.
Thanks, that was really helpful. From reading that, I guess I’ll just use TXO with one of the standard compression methods and forget about it. About my pipeline, I’ll just keep a copy of egg2bam.exe around for every major version of Panda I use in case I need to reconvert the textures.
I forgot to say, the reason I don’t use DDS is that I can’t write DDS from Panda, and my editor needs to be able to write the alphamaps. This is not a big deal as I could write png’s and then use an external tool, but it’s a small convenience.
Also, with TXO, Panda will uncompress unsupported textures for me with libsquish, do I get this benefit with DDS too?
Apart from that, is there a performance difference between TXO and DDS? As in, which one loads faster?
Note that you’ll also need to keep around all of the panda dll’s that egg2bam.exe depends on (or compile a static version of egg2bam.exe).
Yes, this happens at a higher level than the texture loader, so it is done no matter where the textures came from.
I haven’t measured them, but I would expect TXO to load faster, since it doesn’t have to massage the data much, and DDS definitely does (Microsoft stores textures upside-down from OpenGL and Panda’s convention, and it takes a little bit of effort to invert a compressed texture in memory). Still, the difference is presumably minor.
