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.
Yesterday I got a bit cheeky regarding feature requests for X-Plane 10. Here are a few slightly more serious thoughts regarding the feature request process.
The major features that we are putting into X-Plane 10 were decided, for the most part, a long time ago. Those who we met in France two years ago won’t be surprised by the major items on the list: weather, ATC, airports, and new scenery, new shaders. For that kind of major feature work, we have to start an initiative very early on. Heck – global sun shadows (which I believe we will ship in v10, God willing) were in the works before version 9.0 shipped – it took that long to get an implementation that was useful! (In fact, the v9.0 version was not released because the quality was bad, which is why I am always nervous about announcing features in advance; it ain’t over until it’s over.)
So while it’s exciting to see so many people discussing X-Plane 10, realistically if a feature is a “big” feature and we haven’t started it now, it’s not going into 10.0. That train left the station over a year ago.
There have also been two complicating factors that have cropped up during the X-Plane 9 run:
- Microsoft closed ACES, which definitely changes what we want our next major release to look like.
- The iPhone came along – until the first iPhone release, we had no idea that it would be such a big product.
While we have to plan our big features in advance, the market we are going to ship into changes during development.
So bear with us – a lot of what I see are good ideas that we will get to soon, even if they don’t go in the initial roll-out.
With X-Plane 10 on the way, it seems that the various X-Plane forums are just filled with users listing off their favorite feature requests. If there is one uniting theme for these requests, it is this: they are pretty much all requests for X-Plane to more accurately model some neglected aspect of reality.
I would like this relationship to be two-way, with give-and-take. It doesn’t seem fair that in every case, we should have to change X-Plane to model reality. So I humbly submit to the X-Plane user community: my requests for changes to reality to ease X-Plane development.
No Wind Near Water
My first request is a simple one: can we simply not have any more wind over the ocean? Ocean waves are hard to model. They are non-sinusoidal, they don’t repeat, they’re refractive, and they go for miles. If we could simply eliminate the wind, then we could model the ocean as a nice calm glassy lake, which would be quite a bit simpler to get right.
Only One Building
My second request is a modest one: from now on, I would like everyone to live in the same type of uniform house. It can be a nice house (several stories, with a pool in the house), but everyone’s house should be the same. We have some new instancing technology for version 10; it reaches peak efficiency when a single building is repeated ad infinitum. So if you could all agree on a single house type, it would be good for everyone framerate wise.
(I realize that some of you in subdivisions in the US that already do this; hopefully the rest of the world can take a hint.)
No More Intersecting Roads
Alex and I have spent just a crazy amount of time trying to cope with what to do when two roads intersect. So my third request is: no more intersecting roads. I would like all roads to cross each other by some kind of overpass. This will eliminate a lot of artifacts.
In fact, for extra credit, if all roads could be aligned to be precisely north-south or east-west in a grid, that would be good for RAM use.
No Variation in Climate
This one isn’t so important for me, but I think the art team might appreciate it. It turns out that different parts of the world have different temperature variations and rainfall, and that in turns makes the local color of grass, trees, etc. a bit different. This just makes work for our artists – they have to draw everything several times for the different climates. It would help us out a lot if you could all live in places with the same annual rainfall and temperature variation.
(Just in case this climate thing turns out to be true, I suggest everyone settle on the “hot dry” climate pattern – we have pretty good textures for that.)
Pave the Bay
Finally, when in doubt, use asphalt. We have some new shaders in version 10 that will make asphalt look pretty good.
Anyway, this is my list – I am sure the other X-Plane developers will have other requests. (I suspect Austin’s life would be made easier if weather was always CAVOK, and Chris’s life would be greatly simplified if there weren’t any other airplanes in the sky.)
Do you have any hints as to when this new version of reality might be released, or what its minimum system requirements are?
Quick airplane links:
- Carenado’s Mooney M20 J is out, available on the X-Plane.org store.
- Javier’s T34c Mentor is out, available at X-Aviation.com.
Pictures available in both links.
Over the last two years, we’ve been working on the X-Plane rendering engine, setting up the code to take advantage of multiple cores when possible. Most of these changes are in X-Plane 9 already: multi-core creation of 3-d scenery, multi-core loading of scenery, multi-core loading of textures.
X-Plane 10 will leverage this work, pushing even more work to multiple cores. And yet, nine women cannot have a baby in one month. The ultimate limit on framerate will be based on the performance of one core pushing data to your graphics card.
So how many cores do you need, and is it better to have a few fast cores or more slow cores?
I can’t give you a firm answer, because I don’t know how important money is to you, I don’t know which rendering settings you care most about, and X-Plane 10 isn’t finalized. (And even if it was, we often improve performance in patches.) But I can suggest our attitude to how cores are used.
A Graphic Analogy
With graphics cards, the companies target different markets. The “enthusiast” market is the top end, where money is no object and maximum performance is the goal. Below that you have “performance” cards (a good value for the money but not as fast) and “mainstream” (which by video game standards means “slower than snot” – main stream users don’t need fast 3-d graphics to check email).
When it comes to rendering features, we expect X-Plane to be efficient enough to meet the performance expectations of a given slice of the market. In other words, if you have bought a top-level graphics card, we need to be efficient enough to let you run at 8x FSAA on a huge screen with per pixel lighting – that’s what is expected of the enthusiast crowd and that’s what the cards are built for.
But if you have a mainstream card and get 5 fps with per pixel lighting, well, too bad. You’ve got a cheap, low powered card, you need to dial down the sim. Here our goal is only to give you a way to run X-Plane at all. (And frankly, if X-Plane could run at 60 fps on a mainstream card, it means the max rendering settings don’t take advantage of top end hardware!)
Core Considerations
At this point we expect pretty much any modern computer to have at least two cores, and users with single core machines are going to have to make serious graphic quality sacrifices to run X-Plane. (This is already true for version 9.)
When it comes to version 10, I think we will categorize “a lot of cores” (e.g. 4, 6, or more) as enthusiast – some of the top level rendering options may not function well with less than four cores, but dual core machines should at least run decently with some rendering options enabled.
How far we go toward utilizing really high core count (Austin upgraded to the new Mac Pro and now has 8 hyper-threaded i7s) I don’t yet know. My guess is that we will get at least some measurable benefit from up to 8 cores.
Trading off clock speed for core count is a difficult choice. Obviously if you had a choice of one core that was twice as fast as a 2-core CPU, you’d take the speed – you’re getting the same total computing power but the clock speed can help frame-rate. But the trade-off is almost never formulated like this, and it’s too soon to have hard data from the sim itself.
For what it’s worth, the latest generation of CPUs is really fast, so it is unlikely that you’d upgrade to a new CPU and not get some serious benefit, whether it comes in cores or clock-speed. The users I have heard from with new iMacs seem quite happy with their machines.
I got this bug report from Austin this morning (found in the in-development version 10 code):
yter bug
0: go to kcae with no scenery installed at all
1: open the 777
2: go to aircraft:aircraft and situations
3: go to second tab
4: set total num acf to 1
5: go to first tab
6: select ‘carrier catshot’
7: release the brakes, with throttle at idle
8: enjoy the cat.. ease the plane gently onto the water, gear down, pwer off
9: note that the water is ‘hard’… the yter is telling us that we are on land not water. hit brakes. stop. u r walking on water!
The first thing to note is how specific and small each step is. These steps are much more precise than most of the bug reports we get. And yet, they must be that specific – the bug was so tweaky that skipping virtually any of those steps will cause it to not appear.
The biggest problem I see with bug reports sent to me is the use of “any”, e.g. “open any aircraft”. That’s not very specific! And Murphy’s law says: the one airplane I pick will just happen to be the one airplane that you haven’t tried and happens to not show the bug for some strange reason.
So always be absolutely specific. When we ask for tiny steps, it’s not that we don’t know how to use the sim – it’s just that we need to use the sim exactly the same way you did!
EDIT: bug report pages.
Be sure you understand which bug base you should be using (E.g. are you reporting a bug against the plugin SDK, the sim itself, or a scenery tool like WorldEditor.) If you don’t know what program you are filing a bug against, you probably shouldn’t file a bug at all – just contact tech support.
There’s a real difference between a useless beta (e.g. what we have with WED now) and a useful one. While the purpose of a beta program is to fix bugs, a beta can be useful if the features users must have work. I don’t think I will have time to finalize WED 2.0 this year, but I do think I will be able to fix the really nasty bugs, the ones that make it useless.
To that end I have fixed a number of crash-on-export bugs. To the users who filed complete crash-on-export bug reports: thank you! It was quite an education to see what was in some of these projects polygon-structure-wise.
If you filed a WED export bug, I may have requested feedback if you didn’t include the WED file. Basically I would like the minimal materials to fully reproduce the bug by opening the package and picking “Export to DSF”. For many packs this is just the Earth.wed file, although sometimes textures or text files may be necessary.
A number of the crash bugs are caused by degenerate polygons. For example, if your polygon crosses itself in an X shape, not only is this illegal in X-Plane, but it also drives the exporter crazy. With the next beta, WED will select polygons that failed to export to help you locate such problems.
I am down in South Carolina with Austin and Chris, working on integration issues with the new ATC system for X-Plane 10. One issue Chris is working on now: how do you fit the wide open design options of Plane-Maker into the narrow FAA categories for aircraft. If someone builds a rocket powered lighter-than-air piano with a tilt-rotor and a lift fan, how many miles of separation does that aircraft need from the 747 in front of it? What SRS category is Sponge-Bob Square-Pants, or a Steinway piano, or Snoopy’s dog house? (And don’t even get me started on some of the weird creations Propsman has sent me!)
Our current solution is to analyze the structure of the plane and use the most conservative criteria available. If your aircraft weighs a lot, it’s a heavy, no matter how you built it. If it has jet engines, it’s a jet, etc. This way airplanes modeled after real life will get correct categorization, and custom designs will at least receive some kind of vaguely sane handling.
X-Aviation has released the Duchess, pics here.
Carenado is coming to X-Plane, initial pics here.
I realized I have slightly better test shots of global illumination than the ones that got out a week ago. These are from only a day or two after the last shots.
This is the Cirrus again, with landing lights and strobes; you can see that all of the airplane’s lights contribute dynamically to the lighting on the fuselage and doors as they move. (Yes, that is heat blur on the engine; the heat blur still needs a lot of tuning.)
This shows airplane-mounted lights interacting with custom scenery. In this case the standard Cirrus (with global lights attached) casts both strobe and multiple landing light spill on LOWI. One of the powerful results of global illumination is that we get correct lighting interaction between diverse content, including third party content.
Finally, this shows an airport beacon lighting a plane and vice versa. The global lights on the airport beacon are inside an animation group, making them “sweep” the airplane, which can in turn animate the airport beacon. With global illumination, there are no rules about who lights who.
