Revisiting Texture Compression

For quite a while now, I have been advocating in favor of DDS compression. I am pretty damned obstinate, but eventually if enough people yell at me, I get a clue. I have come to appreciate that there are some cases where DDS compression is not a net win; this blog post explains when it happens and what we might do in X-Plane 10 to work around this.

DDS - The Good, The Bad, the Ugly

DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:

1. Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
2. Because small versions of the image (the "mipmap pyramid") is already in the file, we save time down-sizing the image with the CPU, another win for load time.
3. Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.

The bad is that the DDS file does not contain the original uncompressed file. If the user unchecks "compress textures to save VRAM", DDS files remain compressed. If the image file contains details that don't compress well, they're going to get splatted and stay splatted.

What If VRAM Grew On Trees?

My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don't compress textures, the user runs out of VRAM faster and has to go down a level of resolution...and once that happens, everything starts to look ugly.

But what if the user has 1 GB of VRAM? At this point, we've limited the maximum quality the user can see because we don't have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.

If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.

The Best Of Both Worlds

This is my thinking for version 10. (These are just musings, we haven't coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.