A question came up in the comments to my previous post:
Any suggestions on the best way to edit DDS files on a Mac?
The answer is simple: do not edit DDS files!!!
The problem is simple: DDS is a lossy compressed format. Every time you go from an uncompressed/losslessly compressed format (like PNG, TIFF, or BMP) to a lossy format (like DDS or JPEG) you are going to lose a little bit of image quality. So if you re-open your DDS, edit it, and resave, your graphics program is going to make a round trip and reduce quality.
Therefore the work flow should be:
- Edit the original PNG or photoshop master file.
- When done, re-export to DDS.
So each time you work, you work from a lossless or uncompressed master (like PNG or a gimp/photoshop file) and then re-export to DDS.
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.
I’ve been meaning to write a post about the difference between general purpose flight simulators and AAA first person shooters for a while; a particular feature in X-Plane 10.04 brings some of these differences to light.
A typical high-end first person shooter is a closed game; the art content and the rendering engine ship together, and the art content is authored specifically for (or repurposed for) that particular rendering engine. The content is also completely available ahead of time; it can be authored without worrying about rendering engine changes or the addition of third party add-ons. Similarly if a rendering engine change requires revising all art content, this is at least possible, since all art assets live in house.
Compare this to a general purpose flight simulator. The rendering engine and art content may be revised on different schedules. The artists building third party content have limited access to the developers writing the rendering engine, and the rendering engine acts like more of a platform than a closed product.
Because X-Plane’s rendering engine is a platform, rather than part of a closed product, we try to keep optimization and performance work generic. When possible, we put in optimizations that act automatically without author participation. When we do have optimization advice, it tends to be generic advice that applies over a wide range of rendering engine revisions. (For example, using less OBJ ATTributes and atlasing many small textures into one big texture have been good advice for at least the last seven years.)
Sometimes, however, it becomes necessary to put in authoring features that are somewhat specific to the rendering engine and optimization. This is what has happened with cockpit pre-filling.
Before we go any further, you may want to read about pre-filling here. (One thing I am trying to do is to put the specific tutorials and documentation into permanent articles and not blog posts that are lost in the archives after a few months.) Basically when we pre-fill, we draw part of the airplane early on to mask out clouds, saving fill rate on the GPU, improving framerate.*
For the 2-d panel, we put in pre-fill in X-Plane; no artist intervention is needed. But for the 3-d cockpit, we can’t easily pre-fill without you setting some check-boxes on your airplanes.
The problem with the 3-d cockpit is that it is, in its entirety, rather expensive to draw. So we can’t just draw the entire 3-d airplane (for the purpose of masking clouds) or we’d be burning a possibly large amount of CPU to save a possibly large amount of fillrate. The right trade-off depends on the actual plane, and X-Plane can’t figure out automatically what the right thing to do is.
Hence the pre-fill check-box in X-Plane 10.04. With the pre-fill check box, you (the author) mark your content for optimization to hit the right balance of CPU and fill rate savings. (See the articles linked above for guidelines on how to set the flags sanely.)
Fortunately if the check boxes are set wrong, the worst thing you get is poor frame-rate (not crashing). But this is a rare case where third party authors can (and have to) input tuning data directly into X-Plane.
(And for concerned users: if an airplane doesn’t have the pre-fill check-boxes set up, the performance is the same as 10.03 – there’s no loss, this is just an opt-in optimization.)
* If you are asking at this point “why didn’t you guys do this years ago, you idiots?!?” the answer is: because it never mattered before. X-Plane 9 simply doesn’t use much fill rate, so it never made sense to spend CPU time to save fill rate.
X-Plane 10.04 is out for beta. A few notes:
To get 10.04, you must run the updater and check “get new betas as well as updates”. The updater will not get you a beta unless you specifically ask for it, and X-Plane won’t nag you to update if the patch is only in beta. (This is our preferred method of running betas, and all future betas will be like this.) There are some pretty major fixes to ATC and AI aircraft behavior, so it could be a beta worth getting.
We are starting to transition more of our various websites to WordPress; this is an on-going process. The eventual goal is to have all of our various web info into WordPress (on either the main site or the “developer”* site, which will grow out of this blog) and drop the wiki. MediaWiki makes everything possible when it comes to content management, but it makes nothing easy, and controlling spam has been a real problem. Eventually all of the knowledge-base articles that the sim can link to now will be browsable from those sites, but for now we’re still working on building up the infrastructure in our few free moments.
And speaking of developer resources: I am working on a release of scenery docs and updated tools; it’ll take a little bit to get everything together. I am getting hammered with requests; a complete release should get most people where they need to go, so I am trying not to jump in and write one-off emails answering questions; better to focus on permanent docs I think.
Finally, please don’t email to ask me “did you fix my bug yet.” If it’s not listed as fixed in the release notes, it’s not fixed. We’re trying to be accurate in the release notes so that you don’t have to ping us every single release, which burns your time and ours. Not all bugs will be fixed this beta; we have enough high priority ones that we’re going to get fixes out as quick as we can.
* The developer site will include aircraft, scenery, and ATC authoring info; the SDK website will remain separate, as LR doesn’t own the SDK IP. (It’s more like FSUIPC that way.)
X-Plane 10.03 is now final; here’s a little bit of what’s coming up:
- For a while we were “pushing” betas to all users via the auto-update system. We did this because we had critical crash fixes we wanted to get out quickly. Fortunately, that phase of the release is now over and 10.04 betas will only be available if you opt in and check the “beta” box in the updater.
- For 10.04 we are continuing to tune performance, fix bugs, improve the look of the sim, etc. In other words, it’s more stabilization and polish.
- Aerosoft has built a few custom and lego brick European airports for X-Plane 10; these will be available as part of the update for users who have scenery installed. This might be in 10.05 depending on how quickly I can get the installer/updater work done.
- Tom is working more with the airport lego brick library using WED 1.2; I fixed some WED bugs last week and will try to get some releases out soon.
I’ll post more on framerate in the next few days.
This is an authoring “gotcha” in X-Plane 10:
Do not use a degenerate UV map if you are using bump maps. If you use both techniques, your object will have black splotches in HDR mode.
Let me define what I mean:
A degenerate UV map is a UV map where the “U” and “V” axis (that is, the horizontal and vertical axes of your texture) are not moving in different directions across the face of a single triangle.
The most common case is when all three vertices of a triangle are mapped to a single point in the texture, giving you a “solid color” triangle (that is, the whole triangle picks up the color of the single point of the texture.
You can also have this problem if you use “1-dimensional” texturing – that is, all three texture points for a triangle are along a line in the UV map or two of the three points are colocated.
If you need to use bump maps for your OBJ and you need a “single color” spot, separate the UV map of each vertex of the triangle by a little bit (even just one pixel).
You’ll know you have this problem when you see some of your polygons show up as pure black when HDR lighting spills on them. Here the top of the APU/air conditioner on the jetway has a degenerate UV map. In HDR mode it shows as a black area despite the spill light. This kind of artifact will show through any geometry that should normally cover the affected area.
Why This Happens
(What follows is strictly for the computer graphics nerds – you don’t need to understand this to fix your OBJs).
For the computer graphics nerds: in order to apply a tangent space bump map, you need three basis vectors to create a 3-d space for the normal vectors; the tangent space bump map is then essentially a perturbation of the regular normal vector. (Or put another way, the tangent space coordinate space system defined by U, V, N is used to transform the tangent space bump map back into world space. For the degenerate case of no normal map, the normal map can be thought of as 0,0,1 and the transform is a no-op from what we would have had anyway.)
Some engines require that the U and V axes be specifically passed per vertex. X-Plane, however, reconstructs the U and V map from the UV map of the model. When the UV map of the model is degenerate (e.g. it doesn’t form distinct non-zero length basis vectors along the output triangle) the coordinate system of the tangent space normal map ends up degenerate and the output normals suffer from a divide-by-zero.
The divide-by-zero is burned into the G-Buffer and the artifacts are thus persistent.
One of the major components of the new ATC system in X-Plane v10 are the taxi layouts. We sometimes internally refer to this as the “taxi network” because what it’s REALLY comprised of is a network of taxi segments attached to other segments at taxi nodes. The concept is pretty simple, a node connects two or more segments together and it’s a place where a decision could be made by the ATC system in order to change directions. Every single land-based towered airport in the world has it’s own taxi network.
To give you an idea of what a network looks like, here’s one for Seattle (click to see it clearer)
White segments are runways, green-ish (my wife would say “seafoam”) segments are taxiways, red segments are taxiways inside of an active-zone* and the white dots are the nodes. For ground operations, this is what ATC knows about and it’s the ONLY thing ATC knows about. It doesn’t know about buildings or obstacles in the way, it only knows about the pavement. Anytime ATC wants you to get from one point to another, it has to give you a routing composed of a connected list of these segments. The only exceptions are the start and end segments. ATC is only allowed to go “off the grid” to get you onto or off of the network. So if you’re at a gate and you request a taxi to runway 34L, it first tries to figure out the fastest way to get you onto the network. It does this by calculating whether you’re closest to a node or a segment on the network, choosing the closest one and then giving you a straight line to that point. Now you’re on the network. The opposite happens for end points.
So that’s how you get in and out of the network, but what happens along the way? It’s not all that different than the GPS in your car. ATC analyzes essentially every possible routing from your start/end nodes and chooses the one with the lowest cost. Note that I said lowest cost, not shortest distance. Think about the best way to get to work in the morning. Do you take all back roads? Do you maximize highways? Do you avoid tolls? Your decisions are based on far more criteria than the mere distance. The ATC system is no different. Distance is just one of the contributing factors that goes into it’s cost calculations.
Some (but not all) of the other things in the costs are segment type, segment usage, segment angle and the aircraft’s mode of operation. These can be fairly complicated so I’ll summarize them quickly. Segment’s have different types. They can be one way or two way just like streets in a city. Obviously the cost of using a one way street depends entirely on the direction you want to go. If you want to go the legal direction, the cost is nothing out of the ordinary. If you want to go the wrong way, the cost is REALLY high. In other words…only do it if you have no other options! The final segment type is “runway”. ATC tends to avoid taxiing you on the runways because that’d be terrible for airport efficiency…especially if the runway is an active runway. Another contributor to cost is whether or not the segment is already marked to be used. In other words, if another aircraft is taxiing southbound on a particular segment and you want to taxi northbound, that’s a potential problem, so the cost is high. If you’re going in the same direction, it’s no big deal. Segment angle is important as well. ATC does it’s best not to issue routings that result in steep taxi angles. 747’s have trouble making 150 degree turns for instance. Lastly, there’s your mode of operation. Remember how I said ATC hates using runways for taxi purposes? There’s an exception. When you land, it’s often beneficial to continue taxiing on the runway since you’re already on it and you’re already going quite fast. All of these factors contribute to the cost weighting and the route chosen for you is the one with the lowest cost at the time.
So where do these networks come from? Where does the metadata come from? Well, there are thousands of airports in the world that need these taxi networks so that ATC can provide service. It was important to us that ATC would function at any airport out of the box so Ben wrote some insanely cool algorithm that runs “on-the-fly” when you load up an airport. The algorithm looks at the pavement, erodes it inward leaving the “average” center points of all of the edges. This works pretty well but it’s not without it’s problems. The first problem is that it has no clue what the pavement is to be used for. Is it an apron? Is it a taxiway? Is it an access road? Is it a shoulder on a runway? Pavement is generic in X-Plane so there’s no way to know. The result, as you can see in the screenshot above, is that sometimes you get routings on small access roads. Another problem is algorithmic “noise” that’s causes the taxi lines to be quite zig-zagged and wavy. This is why the AI planes often look drunk when they’re taxiing. Often, the segments are not “reduced” or “smoothed” as much as we’d like. You can see the entrances to each runway tend to have a “Y” shape to them because of the “fillet” on the taxiway. This is a byproduct of the erosion code. There is code in there to reduce it as much as possible and “snap” the edges to the runway but it has to be generic enough to work reasonably well at thousands of different airports. Most of the time it causes no problems but there are cases where the “Y” becomes extremely wide because the runway has a thick shoulder created with a strip of pavement. One final problem is the lack of metadata. The active-zones are stamped out around the runways proportional to their size so seldom do they line up with any painted hold-short lines. We have no clue what the taxiways are named. I know what you’re thinking “Why not use the painted taxi markings and signs to aid in the algorithm’s decision making”. That was actually one of the first things we tried and found the data to be too sporadic to be useful and it made the algorithm very slow and complicated.
So if the algorithm has so many problems, why are we using it? Two reasons. First, the alternative is that no airports would have ATC capabilities on the ground until a user made a custom layout by hand. Second, the algorithm was created to be a stop-gap solution, not a substitute for human data! The REAL taxi networks need to come from a human! Once they are made, they’ll be added to the apt.dat and distributed with the sim moving forward. This means that over time, human data will replace the algorithm’s data and taxiing will get better. The taxi network generation is one of the major features of WED v1.2 which will be released in the coming weeks. Authors can create a network for their airports relatively easily. In my first time using WED, it took me only 2-3 hours to create the network and I’m completely clumsy using any kind of CAD type software. Someone who knows what they’re doing could do an equally complex airport in about an hour I would guess.
The layout in the first screenshot above is an autogenerated one. That’s NOT what you’ll be using if you go to KSEA in the simulator and that’s because I made a custom layout. If the sim sees a custom layout, it always prefers to use that. Here’s what my custom layout looks like.
So you’ll notice the lines are straight! There are no taxi segments through buildings anymore, there are no taxi segments on the access roads, there are no “Y” branches at the runway entrances/exits. Also, not visible from this height, the segments are lined up perfectly with the taxi paint and the active-zones perfectly coincide with the hold-short markings as well. I’ve also named each segment properly so that ATC can tell you exactly how to get to your destination e.g. “Taxi via Alpha Charlie Two Foxtrot Delta”.
There really is no substitute for human data. It definitely results in a much more realistic and far less problematic experience.
*An active zone is a taxi segment that’s protected by ATC because it’s adjacent to or in some way affected by an active runway. This is how ATC knows what to protect with hold-shorts and it’s also how ATC knows when it’s time to talk to Ground vs. Tower.
Fill rate: when we talk about fill rate, generally what we’re talking about is your GPU’s ability to fill in individual pixels to make the final image you see while flying. (The actual components of GPU throughput get a lot more complex, but we’ll keep things simple for now.) Two key things to note about fill rate:
- It only comes from your GPU – not your CPU.
- The bigger the size of X-Plane’s window (or the higher the full screen monitor res), the more of it you use.
Therefore I can offer this very simple test as to whether you are fill-rate limited:
If you are running in windowed mode and making the window smaller improves frame-rate, you are fill-rate limited.
(There is actually one important exception to the above test: if you are running out of VRAM, making the window smaller uses less VRAM for the main window + off-screen buffers, which can help fps. So be sure to see whether cutting your texture res helps fps – if it does, you are out of VRAM.)
Fill rate gets used up by:
- A larger rendering window. This is the number one consumer of fill-rate. Double the size of the window in each dimension, you use 4x the fill-rate. That adds up quick!!
- Clouds tend to be fill-rate intensive.
- HDR mode is significantly more fill-rate intensive than non-HDR mode.
- The 3-d cockpit is more fill-rate intensive than 2-d and external views, particularly with HDR enabled.
- Shadows, to a limited extent.
X-Plane 10 contains a stat called “cpu load” in the framerate output data line; I will describe its full meaning and implication in another blog post, but generally low CPU load (e.g. < 0.7) means you are fill-rate limited. If your CPU use for one core is 100% (this means 25% in the task manager for Windows users on a 4-core i5, but 100% in top for Mac/Linux users no matter what the number of cores) then you are almost certainly not fill-rate limited.
Optimizing Fill Rate
X-Plane 10.03r1 will post in a little bit – this is our first attempt to finalize X-Plane 10.03. It is not the end of the bug fix and performance tuning work for X-Plane 10. But if we can get a stable 10.03 we can use it as a baseline and limit betas to those who check the “get betas” check-box in the installer.
X-Plane 10.03r1 contains fill-rate optimizations for the 2-d and forward-no-HUD views; we’ll have to see how much they help people, but they should help you a bit if you are fill rate limited, flying a plane with a 2-d cockpit, and are seeing low fps with clouds and/or HDR.
Once 10.03 is final, we’ll start 10.04 and I will attempt to make a similar set of optimizations for the 3-d cockpit. Note that the 2-d optimizations do not apply if you have a plane that uses the 3-d cockpit for the 2-d view. (Since all of the new X-Plane 10 default planes do this, we’ll need the 3-d optimizations in 10.04 to see the performance benefit with the 747, Baron, and other new default planes. The Cessna, Cirrus Jet, and Piaggio from X-Plane 9 should all benefit immediately.)
Your Mobile GPU Is Light But Not Fast
Here is a table I culled from Wikipedia: it is a table of GPU performance for the “top end” cards for ATI’s last 4 generations of hardware.
| CARD |
DATE |
GP |
GT |
BW |
GFLOP |
| 4870 |
Jun 08 |
12 |
30 |
115 |
1200 |
| 6970M |
Jan 11 |
21 |
32 |
115 |
1305 |
| 5870 |
Sep 09 |
27 |
68 |
153 |
2720 |
| 6970 |
Dec 10 |
28 |
84 |
176 |
2703 |
| 7970 |
Jan 12 |
29 |
118 |
264 |
3789 |
GP = gigapixels/second of fill, GT = gigatexels/second of texture, BW = GB/second of memory bus bandwidht, and GFLOPS = gigaflops/second of MADD. At least I hope – see the original table.
Now I have inserted one mobile GPU (the 6970M) into this chart. So the first thing you can see is: the 6970M provides in a laptop the power that was available in a desktop about two years earlier, more or less. That’s a big step back in time.
The reason is simple: mobile GPUs are typically cut down in their core configuration – there’s no way you can run a 150W full power GPU with those 3 fans in a laptop.
If you have an iMac, you have a mobile GPU. Even the older iMacs which didn’t have the “M” designation on their chip, those were mobile too. In fact, you’ve got a mobile GPU on a huge screen. (Super-size to the 27″ iMac to get the 4x fill rate boost and you pick up 1.7x the pixels; if you get the big iMac with the cheap GPU you have a mid-range mobile GPU on a 2560 x 1440 screen!)
Some Kind Of Summary
I’m not entirely sure what my main point here is…perhaps the executive summary is:
- We (LR) are working to optimize fill rate in X-Plane 10. Fill rate is not the only performance bottleneck we are working on, but it is a very important one. Some of this is in X-Plane 10.03r1, some will come in later updates.
- You can determine whether you are fill-rate limited by resizing your window.
- If you have a mobile GPU in a laptop or iMac you may have less fill rate than you would expect.
At this point I am mostly done investigating weird video card behavior: these two pages are now reasonably accurate for X-Plane 10.
We are still trying to resolve as many of the known issues as we can, but now that we know what cards are in and out, it gives me more time to work on performance and scenery tools.
Happy New Year! I will try to get a few more posts out over the next few days; we spent a lot of December with our heads down trying to fix as many bugs as possible despite the chaos that the holidays always inflict on any company.
We had a slight fire-drill with beta 8 last night; it turns out it crashes on Windows, so we pulled back to beta 7. X-Plane 10.03 Beta 9 will come out today and fix the Windows crash and 1 or 2 other issues.
Right now we are “pushing” betas to everyone; this is not the norm and we will go back to the normal process (where users opt in to betas) once the 10.03 beta process completes. Since 10.03 has so many stability fixes, we want to make sure everyone gets them. We’ll lock 10.03 down before proceeding to additional performance tuning.
For December I had four things I was trying to work on: stability fixes, backward compatibility, performance enhancements, and third party support. I was only able to make progress on some fronts. At this point we have most of the hardware support issues stabilized and we’re close to closing up the crashes. (There is no short term fix for running the sim out of address space unfortunately.) We’ve done some performance tuning and a lot of analysis, but a lot of the work to act on the analysis is yet to happen.
The front where I made no progress is in third party support. So starting this week I am going to try to dedicate one day a week to some kind of third-party-only activity, whether it is getting out the docs on the new v10 authoring features, getting out scenery tools, etc. We have a lot of “almost ready things” and I don’t want to keep authors waiting.
