Various X-Plane 9 Bug Fixes

A quick update on a few X-Plane 9 bug fixes we have in the works. We will hopefully cut a new beta of X-Plane 96x in the next few days.

• Linux DVD recognition was unreliable and required work-arounds; my attempt to fix this in X-Plane 964 made this work, but we have a real fix.
• We have a handful of hang-on-startup problems with NVidia cards and Windows 7. I am working directly with a few users to figure out what's going on, but I hope to have a work-around in a patch as soon as we ID it.
• We have new installers that I need to roll into beta; they will address DVD location issues on Linux and also improve net performance.

The numbering scheme for v9 is a little bit odd at this point. Since we are putting so few changes into each build, Austin has been numbering them as "release candidates" - that is, 962 was final, then he cut a 964 and 965. 964 and 965 were both only available by checking "get betas", and both turned out to have defects. When 966 is ready, it will be available via "get betas", and we will promote it to a "real" release if it turns out our bug fixes actually fix things.

So: egg on my face for being 0 for 2 with 964 (in that both my QuickTime fix and Linux DVD fix actually made things worse).

ATC Part II - A Dilemma

Here's a thought experiment for you: you have a new version of X-Plane with new global scenery, new rendering engine options, new weather, a whole fleet of new planes, and new ATC. That new ATC is rewritten to support realistic IFR flight, the AI planes participate, the system includes ground ops and it uses audio files to "talk". But the AI planes don't have real-world liveries, and they don't follow real-world schedules for major airports. What do you do?

1. Release this new version of X-Plane with the ATC as is, and continue to improve it in a patch.
2. Release this new version of X-Plane, but ship the old ATC from version 9, because while the new ATC is better, it's missing some features that some users have asked for.
3. Delay the release of the entire sim because ATC is missing some features that some users have asked for.

Clearly options 2 and 3 aren't options at all; you wouldn't ship the old ATC (which is clearly inferior to the new code) just because there are more features you could ship, and you wouldn't withhold the rest of the new version's features for the same reason.

No feature is ever done unless a program is dead. Austin hired me about five years ago to work on the scenery system, and it is no more done now than it was five years ago. It is a lot better than it used to be; more efficient, better looking, more realistic, etc. But the bar for what is possible keeps moving. That's part of what makes working on flight simulation software so interesting.

In yesterday's post I tried to clarify why we are using real physics in the AI ATC planes; a lot of the discussion surrounding Austin's original announcement made some assumptions about where CPU time is spent that aren't correct. This post describes how features are incrementally added to a release - without understanding release planning, Austin's description of 20 AI planes makes no sense.

Stretching the Playdough
Programs aren't just born whole, complete, never to be modified again. If there is one consistent misunderstanding of software, it's this notion that you "build" software the way you might build a bridge or a house. The truth is, software is made out of a building material that is nothing like bricks or steel, and thus the engineering practices have to be quite different.

If you build a house and decide you want a different exterior floor plan, you're pretty much hosed. No one is going to change the outer shape of a house because the materials used to build the house are not particularly pliable to modification. The cost of moving a foundation is about the same as building a new foundation, so modifications are made as minimal as possible.*

By comparison, code is a lot more like playdough than bricks or concrete. You want the master bedroom a little bigger? Great, we'll just streeeeeetch it out. Code is always modifiable after it is "finished" - if treated right, it never hardens and sets, and this is why successful programs are often on version 10. The problems a computer program tries to solve change, but code can change with them.

So my first take-away point is this: if we add a feature to a program later, it is not because the program was "incomplete" or "unfinished" before - perpetual improvement is the expected norm in a healthy computer program. In fact, perpetual improvement is desirable because it lets us match changing technology and because it lets us incorporate feedback we get from our user base.

(There's an old saw in computer software that the reason to put out version 1 is to learn what you did wrong so you can make version 2. That's a bit of an exaggeration, but the truth is that the only way to get really solid user feedback is to put something out there and then listen.)

Roadmapping

Given that we expect our software to change perpetually, how do we plan? The answer is that we need a road map for the next several steps that the software will take as it evolves. By knowing where we are going we can be reasonably well-informed on the features we code now.

A road map of features needs to be prioritized for two considerations:

• What do users want first? The things we code first, we can ship first, so high priority features should go first.
• What features have to be implemented first? You can't build the roof of a house first, and we couldn't have programmed orthophoto paging of DSFs until we programmed loading DSFs themselves. Sometimes the features "have" to go ina certain order for programming reasons.

ATC AI Airplanes

At this point we finally have enough common vocabulary to sanely discuss the AI airplanes for X-Plane's ATC. So far I have tried to establish that:

• The AI airplanes are going to get better over time.
• We will almost certainly ship ATC AI before the AI airplanes are perfect.
• The order that we implement ATC features will be a mix of what we think is most important and what has to go in first for engineering reasons.

The first stage of the roadmap was to use X-Plane's built-in AI planes as AI traffic. There were a lot of reasons to do this as the first step:

1. The code's already there, so it let us get some airplanes moving around quickly. Inventing a fully separate system from scratch would have taken time away from the rest of ATC.
2. Virtually every optimization that has been suggested (and several that haven't been) can be applied to the AI ATC airplanes, so there's plenty of room to get faster. (If we thought we couldn't optimize, we might not have put the flightmodel in for AI at all.)
3. By sharing the flight model code with AI, the optimizations we do pay twice - to make ATC faster and to make the framerate faster for all users.
4. Inventing a new way to make airplanes (only for ATC) would mean two sets of editing tools, which would invariably mean worse tools in all cases.

With the AI planes running, we then have a lot of ways we can improve things. We can optimize performance. We can optimize memory use. We can increase the airplane limit. We can virtualize the flights (so far away flights exist only in the ATC DB and don't use a "real" AI plane). We can sever the 1:1 mapping of airplane model to flight. We can recycle airplanes when they get too far away to be adding anything to the user experience.

Which techniques will we do, and what will the airplane limit be? I don't know. Optimization really needs to be driven by testing - that is, we need to improve the system by measuring it to see what the next best step is, not by speculating about what problems we might hit in the future. Over time, we will repeatedly optimize and the capabilities of the system will steadily grow.

If you want to know the final specs and capabilities for the ATC system, I fear you'll have to wait until X-Plane 10 ships. When we are in development, any planning for future features is just that: a plan. As we hit real bugs and learn more about the features, the plan can, and often does change. Thus estimates of what X-Plane 10 will do won't be truly reliable until we ship.

* I should be careful here; I used to have these conversations with Sergio, who is a professional architect among other things, and he would have to correct me on a million different aspects of construction technology.

ATC Part I - Real Physics

This is a repost of a reply I wrote on avsim that sort of grew out of control. In part II I will try to explain what we're doing with the ATC system and how far we will get in X-Plane 10.0. Anyway, post follows.


I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y'all started under the assumptions that:

1. The flight model is going to be too expensive to run on AI planes and
2. A table based flight model would be faster.

Those are both questionable assumptions at best...pretty much everything you can conclude from that is, IMO, dubious.

(I should mention at this point that I am unaware of any "dumbing down" features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)

Here's the short version:

The most expensive part of the flight model is ground interaction - that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is "clearly in the air" (e.g. an initial test shows it has high altitude) the FM isn't very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.

So if we want to make the FM faster, there's really only one place to attack: ground interactions - it's the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes - since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) - that adds up. If we are willing to trust that the AI planes don't screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.

Now what if we did some kind of 'lo-fi' AI, whether it's table based or it simply says "move the plane forward by this much" (E.g. a sort of track-based system)? If we want the airplanes to 'sit' properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM - the wheel-ground collision checks. So the total savings of a 'lo-fi' AI flight model would be very small, because at best we might partly improve the performance of code that doesn't have much impact on the sim.

(To understand why you can only boost performance by attacking the biggest pigs, see here.)

However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time...the time spent building a separate flight model could have been spent performance-tuning the real flight model...even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.

Besides my explanation above of why a lo-fi flight model wouldn't really be a win, two more comments:

In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than speculate how a system may perform and write a ton of code up front before you have real data. This is what we are doing...the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it's going to work reasonably. IF we hit data that says "no we have to do something radical", then we will...when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.

And finally, dude, the real FM looks good. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane's suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you're at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it'll be hard to go back to a 'synthetic' FM.

* This may not be a safe assumption...what if a microburst hits an AI plane?

Light Levels: Don't Panic

One of the comments on the suburban preview screenshots I've heard in a bunch of places is "I hope it's not going to be that dark" or "could you guys add more light"?

At this point, light levels in our previews are not reflective (no pun intended) of how the sim will really look. The reason is simple: the light model is not fully debugged (who am I kidding -- it's not even remotely debugged) and it only takes one light model bug to completely throw off the light levels. So I think light levels are going to be a case where the sim's lighting looks a bit funny right up until the last bug is swatted - it's just the nature of those kinds of bugs.

To give you an idea of how much change there is in lighting from version 9 to 10, here's a short laundry list of sim changes that affect lighting:

• Dynamic Exposure. X-Plane 10 reduces the effect of emissive (_LIT) textures base on the brightness of the sun. In X-Plane 9, emissive textures have the same impact regardless of time of day; thus a lighting effect that looks good at night will look too strong during the day. (In real life, you eyes would adjust for the sun and the artificial light would seem less bright.)

• Linear Light Mode. This gets confusing fast, but basically, our eyes perceive light in a non-linear way; we are more sensitive to low light levels than bright light levels. Computer graphics mimick this behavior; the result is that most computer lighting models are physically incorrect in some circumstances. Using the non-linear eye-based behavior has been the norm for while because it was cheaper hardware-wise, but these days it is possible to do physically correct linear lighting. We are adding this wherever we can; the correctness varies with rendering settings since physically correct lighting is more expensive GPU-wise and we don't want to hurt fps for low-end users.

• Deferred Rendering. X-Plane 10 has two rendering modes: a forward renderer (which is a lot like X-Plane 9) and a deferred renderer that supports global illumination and an HDR rendering space.* This creates a certain amount of chaos because the code for forward and deferred rendering are separate, and they seem to develop separate, unrelated lighting bugs.

• Global Illumination. X-Plane 10 supports global illumination in deferred rendering mode, which means that thousands of lights can light up any part of the scenery system. Thsi means that (for the first time) an object may be lit by dozens of light sources at once. It turns out that the linear light model is a lot more important when we have more than one light source. (In fact, Alex and I realized that we needed a linear light model when looking at highways lit by streetlamps.)

• New Light Billboards. X-Plane, like most flight simulators, uses billboards (textured squares that face the camera) to draw the light effects near a light source, like glare and bloom. The shape, textures, and equations for the light billboards are heavily revised in version 10.

• Clouds. The weather system is being rebuilt, including new shaders for cloud puffs. Since cloud puffs aren't like solid buildings or airplanes, they have their own shaders with their own light characteristics. We are also experimenting with increased ground visibility, which affects fog.
  

If there's a take-away point, it's this: lighting isn't just one piece of code in X-Plane - it's the sum and interaction of a large number of features, all of which are being heavily worked over. Only when all of the features work correctly and work together in harmony will we have what appears to be sane lighting.

* Some users may confuse HDR, which just means an image with increased dynamic range for light levels, with the more common effects that games ship once they have an HDR render: bloom and tone mapping. Bloom is when bright light sources "blow out" and splat light around nearby areas; tone mapping is a technique to visualize that high dynamic range on a normal monitor - often it is used to simulate your eyes adjusting to variable light levels.

I do not think we will ship bloom in version 10.0; I experimented with it and found it had almost no value. First, there are very few scenes in a flight simulator where bloom is that useful; it seems to be a lot more useful for interior rendering, like you'd see in a first person shooter. Second, X-Plane already has a number of bloom-like effects, including halos around lights via billboards, sun glare, etc. With most of the important cases already covered by ad-hoc effects, my early experiments with bloom weren't very promising. We may revisit bloom later, but I don't think it's as important as other effects for now.

Similarly, I don't think we will have dynamic tone mapping because we will have an overall dynamic exposure control running all of the time. Again, the value of tone mapping is more obvious with first person shooters, where you can go from interior to exterior and you want the world to be 'overpoweringly bright' for a while. By comparison, pilots do their best to preserve their night vision, and the interior of an airplane is designed to match that; instruments auto-calibrate their brightness to the overall light levels, making tone mapping less important.

Next-Gen Cities

A few days ago Tyler posted some pictures of the "auto-gen"* for X-Plane 10's global scenery.

First, a few notes on hardware and performance: Propsman took these pictures on a new iMac, so that's a core i5 and a Radeon HD 5000 series GPU - that is, a pretty decent system. Hardware technology continues to advance rapidly (especially on the GPU front), so there's a big difference between a 'decent' system bought today and even a hard core system from two years ago.

I don't know what your performance will be like. I do know that the system is performing well enough so far in its not-really-all-that-optimized form that we think we can ship it, and more importantly I know that we can turn the level of detail down in a number of ways to lighten the load as needed.

The most expensive feature you see here is the real-time 3-d global shadows. Heavy shadowing combined with heavy 3-d does add up and hit the system hard, but I think we'll be able to have intermediate shadow settings that should be more affordable.

X-Plane 10 will use hardware instancing if your GPU is capable of it, and it makes a big difference in the amount of 3-d you can show.

X-Plane 10 is also quite a bit more fill-rate intensive than X-Plane 9; if your GPU is having fill-rate problems with version 9, some version 10 features will be out of reach. In the past, X-Plane has been light on fill-rate, so we've had users running with cut down cards (like a GeForce 8400) without realizing that their card isn't that fast.

Some users have asked about architecture and localization. I expect we will not ship out of the box with multiple local regions; however, the library system allows us (or any third party) to provide new artwork sets for local, architecturally reasonable buildings.

Finally, it might be a bit difficult to see in these pictures (because they are focused in on the detail), but the 3-d buildings you see here work with the real-world roads. In the past, we've had a clash between the buildings and roads vs. the terrain texture. This is a problem we are solving for X-Plane 10.

* Auto-gen, meaning bulk buildings that populate the world in urban areas...whether it's really auto or gen or anything like autogen in the past is a complex discussion that will have to wait.

The Scenery Site Is Wikified

This summer Tyler migrated the X-Plane scenery SDK documentation to X-Plane's main wiki. I just put in a series of redirects, so that the old URLs for the top level pages will point to the various wiki sub-categories. The wiki contains the most recent information now, as well as up-to-date download links, etc.

At some point I will try to replace the individual scenery documents (part of the library.php script) with redirects to the appropriate wiki pages; until then I will leave the old site in place.

LSD.glsl

Too trippy not to post:

Fun With Servers

Just an FYI: when it rains it pours. Normally betas increase load on our set of update servers. To compound this, one of them is suffering a midlife crisis^H^H^H^H^H^H^H^Hhard drive failure.* We're working on it now; hopefully it will be resolved in the next 24 hours.

EDIT: the update server is back up - our host not only swapped out the drive, but the whole box. We'll have to take it down one more time in the future, but for the most part I think we're out of the woods.

Another note on servers: Chris has restructured X-Plane for Android to separately download the art assets from our servers, rather than contain all art assets in the actual download. What he found after several painful weeks was that the Android store is not yet reliable for large apps. While the official app size limit is 50 MB, many phones have problems with their configuration that cause downloads to fail. When the user buys our app and the download fails, they get angry at us. (X-Plane may have been, until it was restructured, one of the largest Android game APKs. The other games with large amounts of 3-d content were already doing separate downloads.)

We originally wanted to build a monolithic app (everything in the APK) because we thought that this would provide the simplest, easiest configuration to maintain, and thus hassle-free installation for our users. You get the APK, you install it, you fly! Unfortunately, the Android Market isn't reliable for such a large download, so we had to re-evaluate.

The new system downloads only the core app from the Android Market and then pulls the art assets from one of our servers. So far this appears to be an improvement. If/when Google provides an integrated solution, we will probably switch back to it to simplify the process again (right now we have two points of failure: the Android Market and our server farm, which, per the above notes, sometimes does fail). But for now, we'll host the apps and try to give people the best download experience we can.

Finally, I will try to roll out at least a beta of new installers some time this week. The new installer simultaneously downloads from multiple servers, with a more efficient HTTP implementation; this should hopefully result in better download times and also lower server load per demo.

* Chris pointed out: most normal humans don't know what this ^H^H^H^H is about...it's nerd-speak for the delete key, e.g. to undo a text. ^H is control-H, which you may find works just like the delete key. Yes, I'm a huge nerd.

Plausible, Realistic, Procedural and Algorithmic

Alpilotx pointed me toward a thread on the org discussing Austin's work on the weather system. The thread turned into a bit of a he-said-she-said with regards to Outerra and whether it could some day be combined with X-Plane.

This blog post will be a discussion of various general approaches to scenery and the trade-offs we have to consider, e.g. plausibility and realism, procedural vs. algorithmic and data driven design. But first, a brief note on Outerra. As I have said before, we are already aware of Outerra, so there is no need to email us. The bottom line is that we have a set of mostly done features for X-Plane 10, our goal is to finish X-Plane 10, and we are not even spending one brain cell considering putting a new rendering engine into X-Plane while we are trying to get 10.0 done.

Defining Some Terms

One of the problems with comparing scenery system approaches is that a real productized approach to scenery rarely fits into a perfect bucket or matches a single theoretical techniques. So here are some approximate terms, designed to generally describe an approach. They're not going to be perfect fits, and even the definitions will fluctuate in different contexts and forums.

• We can say scenery is plausible when it looks like it might exist somewhere in the world. Plausible means that roads don't go straight up over a cliff, trees don't grow in the ocean, etc. In other words, plausible scenery is scenery where absurd things don't happen. Plausible scenery is great when you don't know what an area should look like. A lack of plausibility is often a bug.
• We can say scenery is realistic when it correlates closely with what is really present at a given location on the Earth. So if there really is a lake behind my house, realistic scenery has that lake. Plausible scenery might have a lake, a forest, or something else believable for where I live (the Northeastern United States). A giant sandy desert would not be plausible for my location.
• We can say scenery is procedural if the detail in the scenery comes from some kind of algorithm that produces results. For example, a fractal coastline is procedural.
• We can say scenery is data driven when the detail comes from some source of external input data. Our mountains are currently data driven - that is, the mountain shape basically comes directly from the DEMs we use.
• We can say scenery is artist driven if the look of the scenery comes from art assets created by an art team.
• We can say scenery is algorithm driven if part of its look comes from the transformational process that converts data from one form to another.

(I'm sort of drawing a line in the sand here with procedural vs. algorithmic, but what I'm trying to contrast is a program that generates 'information' out of thin air vs. a program that creates information out of other information. For example, in X-Plane 9, European capillary roads were procedural. We had no real data, so I wrote an algorithm that made them up in a manner that was consistent with underlying terrain. In version 10, these roads will be algorithmic; we take OSM data and then do some processing to make it suitable for X-plane. This is definitely a line in the sand kind of definition.)

So Are We Plausible or Realistic?

So the first question is: is the goal of X-Plane global scenery plausibility or realism? The answer is: a bit of both. Austin's posts on the subject virtually always bring up plausibility. The reason for this is simple: he is not too worried about the amount of realism we've put into the scenery, but he is not happy with the bugs. He wants the bugs gone. So every time he and I speak, he says "and make sure it's plausible!"

But we're not going to remove realism just to fix plausibility bugs. I expect that the next global scenery render will be at least as realistic as the last - that is, we're going to use better data and we're not going to make up data where we had real information before.

There are limits to realism. We don't expect the global scenery to ever be as realistic as a custom scenery package for a small matter. But realism does matter. Part of the joy of flying in a flight simulator is seeing the real world. Where we can have more realistic global scenery, we consider it to be a win, and we are always looking to be more realistic than the last render.

Plausibility for the version 10 render is going to take two forms:

1. Bug fixes. Any time something screwy happens, it's not plausible. Sometimes these are code bugs that must be fixed, and sometimes they are data conflicts. For example, the water data sasys "water" but the elevation data says "hill". Combine them and you get water going up a hill. We have to write code to resolve this, somehow.
2. We are reworking the way cities are rendered, because even at their best, the old approach, procedural buildings with algorithmic roads over land class photos, did not look plausible, even at its very highest setting. So this is a feature request to fix a plausibility problem.

Algorithmic or Procedural

I've discussed this before (and forgotten about the post). But to expand the discussion, we need to consider not only algorithmic and procedural data processing, but whether we are driven by procedural generation, input data, assets created by artists, or some combination. (In practice, all systems require a mix of data, art assets, and procedures and algorithms, it's a question of the blend.)

I've been working on global scenery for a few years now, and over time I've come to appreciate the importance of artist input (via art assets) into any scenery process. Simply put, if you want scenery to look good, you need to make it reasonably straight forward for people who are good at making pretty pictures to control the look of your visual results. A few years ago I viewed the scenery process as strictly a question of data conversion and visualization, but now I see it as finding a way to merge art assets and data into a cogent final product, with the art assets being used in a way that the artists can control. In practice, this often means making sure that the art assets come in a format that artists are comfortable with or can learn without too much pain.

As I said in the previous post, our approach is becoming more algorithmic and less procedural as higher quality source data becomes available. (For example, we don't have to generate European roads when we can import and reprocess them.) But our approach over time has always been heavily artist driven. By this I mean: our input data is algorithmically processed into a final form that makes sense only in the context of art assets, and we have a pretty good idea of what those art assets will look like when we design the algorithms. To use roads as an example again, our task with OSM is to convert OSM road data into a road network that will visualize nicely with road art assets created by an artist.

Procedural Compression

One way to view procedural scenery is "creating lots of information from little or no information". But another way to think of it is as a compression technology. As was correctly pointed out on the org forums, you use less storage specifying the overall location of a forest than you do specifying every tree individually. The compressed form (store the forest location) can be equally plausible. It will be less realistic if the original tree locations were based on real world data, but it will be equally (unrealistic) if the original tree locations were procedurally generated. Put another way, pushing procedural processes out of the scenery generation process and into the flight simulator makes DSFs smaller.

When I first started working on X-Plane 8 DSF scenery, not only was DVD size a factor, but so was load time; we had one core and it wasn't a very fast core. Anything we could do to make loading faster, we did. Thus we pushed a lot of work into the scenery generation process, including procedural processes, to keep load time down.

Times have changed; we now have dual core machines as a baseline, and often quite a few more cores. Thus over time we are starting to move procedural processes back into the simulator, trading load time (which runs on multiple cores) for generation time and file size. So perhaps a more accurate statement would be: our scenery generation process is becoming more algorithmic and less procedural, and X-Plane itself is becoming more procedural. This is driven both by more input data (which must be processed up front) and more compute power on the host (which lets us shrink file size, and thus use DVD space for other things).

X-Plane 10

Here's how this plays out in practice in version 10:

• Some (but not all) of the building placement work* has been moved into X-Plane; a bit of expensive precomputation is still done at DSF generation time.
• Some (but not all) of road processing has been moved into X-Plane; a lot is still done at DSF generation time.
• Where possible, we are moving from a multi-layered approach to terrain to a pixel-shader-based approach to terrain. This cuts down overdraw and uses the GPU more efficiently. (The simplest example: in X-Plane 8 and 9, cliffs have separate terrains from hills. In X-Plane 10, a single terrain sits on both the cliff and the hill and changes its appearance based on the actual slope; this texture change is computed by the GPU.)

In other words, X-Plane 10 is making the logical evolution to better balance the computing resources we have to improve plausibility and realism.

I Recognize That Scenery

Thanks to Dominic for sending me this link...these guys are building an airship^H^H^H^H^Hhover^H^H^H^H, well, it's weird looking. Hrm...that airport they're landing at in the simulator looks strangely familiar.

100 Mile Visibility

First, Happy New Year! As is typical, I've been quiet on the blog because things have been insanely busy here at work. Just to give you an idea of the insanity:

• There will be a 9.63 relatively soon - the bug driving this is some Linux distros not finding the DVD. But we'll get a few new datarefs in there too.
• We have new updaters and installers to get tested, again addressing Linux DVD issues, but also with updated web download code that should give a nice speed boost.
• Chris has been working hard on Android. X-Plane for Android is pretty much the biggest APK anyone has tried to ship, and as a result we've hit a number of problems with the market that we are going to work around.
• All that's just the side show; X-Plane 10 development is of course the meat and potatoes.

Now, about visibility. X-Plane 9 restricts ground visibility to 25 nm (about 46 km) in an attempt to prevent you from seeing off the edge of scenery tiles. Many users have expressed (some more persistently than I would have liked) an interest in longer range visibility. Austin recently posted a note to X-Plane.org discussing level of detail and distance management in the new weather system, and users immediately picked up on his mention of 100 nm visibility. Here's what we're thinking; all of this is subject to change as we keep working on the product.

First, visibility: you can come up with a formula for the distance to the horizon based on height above a sphere: d = sqrt((r+h)^2 - r^2) where r is the radius of the planet and h is the height above the planet. Since the Earth is roughly 6 million meters in radius, we get a visibility to the horizon of:

100 meters: 34.6 km
500 meters: 77.4 km
1000 meters: 109.5 km
10000 meters: 346.5 km

Clearly a little bit of altitude lets you see a long way.

But there's more to it than that: X-Plane has always changed the visible distance with altitude. The 25 nm limit applies to surface observations (which is what you get from a METAR). As you move up into orbit, that distance is scaled out to the horizon distance, so that you can see the whole planet from orbit. That scaling can reveal the edge of DSFs, which are blended into the planet when volumetric fog is enabled.

So here is what I think we really need to do:

• We do need a larger 'surface level' maximum visibility, so that distant features are visible from the ground.

• We need a scaling from ground to upper atmospheric visibility that gives us more visibility sooner; one of the problems with version 9 is that the increase of visibility is slow, which gives mid-elevations a hazy look.

• In the long term, we need to load more DSFs, probably twelve instead of six. X-Plane 10 already has some improvements in how scenery shift is done, but my guess is that we can't productize this until we have a 64-bit build (since more DSFs chew more memory), so I expect this to happen in a patch.

• We need to add elevation displacement to the whole-Earth planet render, so that the blend between DSFs and the planet don't have huge height gaps at high-elevation locations. I am hoping we'll have this in 10.0, but it is not coded yet. (Usually we recut the planet textures last, since they are cut off of the DSFs.)

• We need to improve the quality of haze, fog and atmospherics. In real life, atmospheric scattering reduces the contrast of far away terrain. I believe that correct scattering could make a huge difference in the quality of the transition from DSF to planet, the required tex res (we need less if we scatter more), and generally it would be a big contribution to the realism of the image.

  I'm not sure how much of this we'll get into 10.0; I have a prototype of Sean O'Neil's atmospheric scattering shader from GPU Gems 2 running in the sim, but I don't think it's shippable. I do hope we'll get at least some scattering in place, with improvements in patches.

That's a road map, at least. If there's a take-away point, it's this: increasing visibility is complex and involves a lot of parts of the sim and there are still significant parts that need work. So I really don't know if we'll hit some kind of hitch or problem that requires us to back off visibility.

Austin's comments about 100 nm visibility reflect what the slider in the sim happens to be set to now. It's also a design goal of the new weather system - that is, we want the new weather system to handle significantly larger distances (and have better scalability) than the old one did.