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:
- Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
- 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.
- 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.
3 comments on “Revisiting Texture Compression”
I love this idea!
I have been a true believe in DDS textures for a while now but not many developers use them, be it cause they don't care, or they just don't know how to do it. Either way, what you are saying sounds like a great idea.
It is not much of a trouble for me since all my textures are originally png anyhow before they are compressed to dxt/dds.
great idea all around.
have to admit that as a scenery noob, I didn't know that xplane converted all textures to dds. My first scenery KMPI. is chock full of 512 by 512 (in my opinion the sweet spot for look vs perf) textures and 3 'complex' custom buildings (and some bins, weeds, cans, blood and other custom polys) with no major fps hit (haven't heard complaints YET), so things may have moved on since a few yrs ago. not compressing VRAM makes the textures so much better. As I've said before, what on earth will 10 be like if 9 can look so good!
Great idea so far and I'm sure a lot of people would love to see a better looking textures and most people have good VRAM these days and video cards are some how cheap with 1gb ram. The more beautiful x plane 10 looks, more users will switch from fsx to plane for that better eye candy look that was missing in x plane to a certain level.
Comments are closed.