Thanks to Captain Peter Hager for sending me his A340 as a nice test case for texture compression. Peter (like many aircraft authors) has never been very happy with the artifacts introduced by DXT compression.
First the basics: DXT1-5 are a series of texture compression formats. They store the same number of pixels in a smaller number of bytes via clever encodings of the pixels.
When your image has no alpha channel, the savings from DXT1 compression are 8:1. (Modern graphics cards store RGB images in 32 bits for alignment, so the 4-bits-per-pixel DXT encoding is an 8:1 savings, not the 6:1 you’d expect on paper.) RGBA images take 8 bits per pixel, for a 4:1 savings. That’s as much as reducing the image size by a factor of 2 in each dimension.
DDS is an image format that contains a compressed image. DDS files load faster (because the image is already compressed), look better (because the image is compressed using a slower, higher quality process before sim load) and let you pick the DXT algorithm choice. (In some cases, the choice between DXT3 or DXT5 matters!) However, once an image is compressed into a DDS file, the pixels lost in compression never come back – DXT is a lossy compression format! (This is just like saving a JPG as a PNG – if the JPG quality was too low, the PNG will contain the same blocky artifacts that the JPG had.)
Compression is useful for more than just saving VRAM – because the amount of data needed to texture a given pixel is smaller (4 bits per pixel instead of 32) compressed textures can speed up framerate if the memory bus between the GPU and its own VRAM is congested.
Now let’s look at some pictures.
This is the Swiss Air livery at extreme res, uncompressed, sourced from a PNG. This is our reference image for how good the original image can look before we start trading off quality for VRAM.
This is the same image, extreme res, texture compression on, sourced from a PNG. It just looks awful. The graphics card has done the compression, and it has done a fast job, not a high quality job. (In the driver’s defense, X-Plane asks for a fast compression rather than a high quality one to avoid slowing the sim down.)
This is also compressed!!! But in this case the livery was pre-compressed using XGrinder/DDSTool (which in turn uses libSquish). DDSTool sets libsquish for maximum quality and then takes quite a while to grind each texture, but the results are better use of those compressed bits. (DXT is a lossy compression, so more compute time can find a better use of the finite quality available in the compressed texture.)
Finally, this is the uncompressed texture at “very high” res – that is, taken down one resolution level. Compare this image to the compressed one above. For an alpha-blended texture, the trade-off is one “size” increment (2x smaller on both sides for 4x VRAM savings) vs. compression. I submit that the compressed version is a better way to save VRAM than down-sizing.
Have Your Cake and Eat It in X-Plane 10
In X-Plane 9 you had to make a trade-off: ship a compressed image in a DDS file and have the very best look be extreme res compressed or ship a PNG file, and have the texture look terrible when texture compression is on. You can see from the above images what the options looked like.
In X-Plane 10 you can do both. If you ship a DDS and a PNG file, X-Plane will load the PNG file when texture compression is off and the DDS file when it is on. The result is a pre-compressed texture for users who need texture compression and an uncompressed texture for those who can afford the VRAM.
VRAM and Memory
One last note on texture resolution for users: most drivers use virtual address space to load textures, and thus texture memory eats into X-Plane’s 2/3/4 GB address space limit. Therefore with high VRAM cards (e.g. a 3 GB card) it probably isn’t possible to absolutely max out texture res until we go 64 bit. For example, on the Mac (where the driver uses a lot of address space and we only get 3.5 GB) running the sim on extreme + uncompressed texture res will almost always run you out of memory.
One thing I have noticed from looking at user’s settings and our own machines is that the textures resolution selector goes in pretty big jumps. Each resolution change cuts VRAM by 75%, so if you are over VRAM (and having performance problems because of that), the next setting down will probably leave VRAM unused.
So I have a todo item to look at putting incremental texture resolutions in that derez the scenery but not the airplane, for example, to hit some in-between points. In that context, we may be able to support mixed compression, where some airplane elements remain uncompressed, but the scenery is compressed.
The recommended practice for developers remains the same:
- If your textures look better without compression, ship DDS and PNG files, and pre-compress using XGrinder/DDSTool.
- If your textures don’t improve much by running uncompressed, ship only DDS files, pre-compressed with XGrinder/DDSTool.
One Exception: Orthophotos
There is one exception to the X-Plane 10 practice of shipping both DDS and PNGs: if you are using orthophotos via either a .pol or .ter with the LOAD_CENTER directive, use DDS and only DDS.
LOAD_CENTER causes your images to be reloaded at high or low res depending on the distance from the user’s aircraft to the image; this can save a lot of VRAM by reducing resolution where the user cannot see the detail. Because DDS contains pre-resized images, it is much more efficient than PNG for load center; I therefore recommend DDS-only for orthophotos.
1 small correction: I didn’t send the A340 🙂
We did talk about this issue a few times though and I was experimenting with the various texture options vs. rendering settings just today.
I didn’t compare the current XGrinder with other options like GraphicConverter, primarily because I haven’t managed to build xptools on Lion/Xcode 4.2.1 yet.
peter
Sorry, that’d be Peter Hager – I will correct the post.
Keep them coming, I always learn something very interesting in these blog posts.
Yes the blurry textures are very unconvincing, but the issue i am having (and yes it is related) is huge performance swings by textures, I can go from 41fr to 3-4 frames in an instant just by moving to a new angle, Airports are worse, they sink you faster than the Concordia, worse is amazingly is KSEA, either i am not configured correctly or it is an issue, an article explaining this would be a benefit, but at the moment it is annoying in the fact you are shifting madly from great fr to zero fr, XP9 was far more forgiving in this area, but no matter what settings i use my textures are still very blurry and jaggy…
This has nothing to do with textures. Changing your camera angle changes your FPS because you’re changing what objects have to be rendered in the background.
Thanks Chris I understood that, but what of the textures on the .obj which is the airport flies and if they are very large, i have reduced a lot of building textures (some were 10mb +) to make them far smaller (3mb) than the original files with no loss of quality, surely this would have a benefit, when rendering the airport when you focused on it.
Curious… tried it for the first time and the .dds is 5.6MB versus 1.3MB for the .png, which seems counterintuitive.
PNGs are internally compressed – the size of PNG on disk is NOT indicative of VRAM used!!
Can you please clarify? Does a 5.6MB .dds result in less VRAM used than a 1.3MB .png??
Yes. PNG memory use is 32 bits per pixel, pus a 33% overhead for mipmapping. DDS with DXT1 is 4 bits per pixel + 33% overhead for mipmapping, DXT3 and DXT5 is 8 bits per pixel + 33% overhead for mipmapping.
You can also observe this directly – the rendering settings show VRAM use for textures.
“If you ship a DDS and a PNG file, X-Plane will load the PNG file when texture compression is off and the DDS file when it is on. “
Wow – how does this magic happen. In .pol and .obj files should we omit the texture file extension?
It’s automatic. Include a valid extension (PNG, DDS, your choice) and the sim will fish for the right file.
Thanks for information!
And yes, I’ve been testing textures in DDS compressing them with DDSTool and with DDS plugin on Gimp and XP show them different in a Radeon card (but not in a nVidia 560GTX). Worse with DDS plugin on Gimp, of course.
Thank you Ben,
I read your post on the train to work this morning. It’s been a long day waiting to get home to apply the learnings, but it’s been worth the wait.
Before today I could only run XP-10 with resolution set to “high” without exceeding VRAM. This evening I’ve started creating some .DDS versions of my aircraft and scenery objects using XGrinder and am now able to run very comfortably within my VRAM limits with resolution set to “Very High” and compression on. Most importantly, the aircraft and scenery objects look virtually as good as before, and the terrain looks so much better.
Thanks again.
Al.
Ah, interesting. I’ll implement support for both DDS and PNG into OpenSceneryX.
Strange enough texture-copression enabled or not make NO difference on my system.
Textures are always crisp and clear.
my card Asus ENGTX285
Leen de Jager
Would this be a fesable option for scenery textures?
Yes! But in some cases it’s not necessary. For example, we didn’t think the terrain textures benefited a ton from uncompressed. The road textures do benefit, however.
Any suggestions on the best way to edit DDS files on a Mac? My “software of choice” is Photoshop CS5 but can’t find a way of directly playing with DDS files. I can probably used a different package (Graphic Convertor) to get them in and out of PS but then quality/functionality may suffer.
Any advised workflow?
Cheers
XG
Yes: DO NOT edit DDS files!!!!!!!!!!
This needs a blog post, hang on!
Thought that was as obvious as re-saving a jpeg. Each time you re-save a lossy compression format you lose more of the original data.
Building textures? Sorry for not being specific.
I am trying to understand all the automated options here:
It would seem that there are more than just a couple:
1. The case where an object file includes only a single texture
A. a DDS File
B. a PNG File
C. another allowed Texture Type
In this case what is the function of Texture compress off Vs on.
What if two or more different objects have only one but different file types?
How about the case where different objects have different combinations of all three possibilities? One of the above (2) and both DDS and PNG (1)
In these cases what is the function of Texture compress on vs off?
2. The case where one specific object file includes two textures (DDS and PNG)
A. Texture compression is off = use PNG
B. Texture compresson is on = use DDS
I will start using the recommended DDS compression for my objects.
Thanks for the explanation .
I think you’ve made this much more complicated than it really is. There are three rules in X-Plane 10 governing image loading:
1. Search order is DDS, PNG, BMP when tex compression is on, PNG, DDS, BMP when tex compression is off. Note that we IGNORE the suffix in the art file and simply search for any root name match, using the formats listed above in the order listed above.
2. DDS loader: the file is always compressed because it is pre-compressed.
3. PNG/BMP loader: the file will be compressed if and only if texture compression is enabled; it is compressed on the fly and results are ugly.
Note that you can never have two objects referring to the SAME texture with different file formats because X-Plane ignores the suffix of the file and goes by its own internal search order.
So really, enabling compression is only a mechanism for dealing with objects which would otherwise swamp a less than adequate video card. ( objects which are supplied with only .png or .bmp textures.) In this case, X-plane is the compressor of last resort, and must perform the function in line and with minimimum overhead.
Thanks for the clarification.
Well, compression and reducing res are two ways to reduce texture res to make the working set fit on the card.
And what if you’ve checked the Hi Resolution checkbox in Plane Maker’s Miscellaneous Objects page?
BTW, all this will go in the docs or wiki, right?
Currently no effect. I’m not sure the behavior should be documented. The idea is _not_ to document exactly what X-Plane’s quirky behaviors are; the idea is to provide _general_ authoring strategies that will produce content that works in a predictable way so that X-Plane can evolve while maintaining compatibility.
So: the res box tells X-Plane to prioritize texture res to those particular objects.
X-Plane will use either PNG or DDS depending on settings.
That’s pretty much all you need to know to plan out your airplane.
I think the idea of allowing different texture resolution options for VC and scenery is a very good one. It´s almost impossible to read gauges and labels and handel switches – i.e. handling the aircraft – without at least high res. Carenado advices customers to set resolution to extreme and to turn off compression. And that’s not just because of eyecandy. But I´m fine with lower resolutions of the scenery, in fact I often can´t tell one from the other.
Good to see that you are really going into VRAM /performance tuning since I´d really like to stick to my rather new 250$ 1GB card instead of burning another 300 $ for a new XP10 dedicated gpu. Would prefer to spend it for some nice XP addons instead 😉
Thanks
Flo
Their recommendation is not necessary; _all_ airplane-attached objects get at least one level of “res bump” relative to the world, so at “very high” (one notch down from max) the airplane is already maxed out.
Do you plan to provide DDS files for the default planes? E.g. the C172 has only PNG files.
Regards,
Heiko
Yes – we need to do a once-over and make sure we have DDS, etc.