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.

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.

X-Plane for Android

As some have noticed on the org and on FaceBook, Randy mentioned that we may be able to ship X-Plane Mobile for Android. Some users were quite befuddled to learn that we were aiming to ship X-Plane Mobile for Android so soon when X-Plane 10 is delayed. Here's the full story.

Chris, the third and most recent addition to the X-Plane programming team, began a port of X-Plane Mobile to Android a while ago; this was the second port of X-Plane Mobile after our port to Palm WebOS. He was able to accomplish most of the port fairly quickly; hence the video floating around the web of X-Plane on a Nexus One back in May.

Unfortunately we ran into some issues that stopped ship; it looks like Google may have them fixed shortly, hence our hope of finally shipping the app. So while Chris has spent a little bit of time recently working on the last few Android issues, our hope is to release a product that we already put development time into a while ago.

Updating to OS X 10.6.x

If you have a DirectX 10 or 11 class video card (that is, a GeForce 8nnn or newer or a Radeon HD card) and you're on a Mac, consider updating to OS X 10.6.x if you're still on OS X 10.5.8.

10.6 has performance enhancements in the video drivers that I suspect will benefit X-Plane 9 users, but it will really matter for X-Plane 10. We need OS X 10.6 to expose some of the OpenGL extensions that these cards have. Thus 10.6 will get you faster frame-rate, more realistic lighting, and more efficient VRAM use.

(If you have an older card, I don't know if you'll get any benefit, although I doubt you'll see a performance loss.)

Using Glass Objects in Planes

X-Plane 9 allows you to categorize objects as being on the plane's outside, inside, or glass. X-Plane depends on these flags being right for a few things:

• The draw order of the airplane is determined by the object types - glass is drawn last to avoid translucency artifacts.
• Interior light from the plane is only spilled on the "inside" objects.
• Glass objects are excluded from shadow calculations to avoid having opaque windows in the airplane shadow.

It is important that you use these flags as intended; X-Plane 10 depends on this information as well, and X-Plane 10's global spill and global shadowing algorithms are more sensitive to incorrect categorization of objects than X-Plane 9's forward renderer.

In particular, you should have glass for the airplane windows in an attached object tagged as type 'glass'; do not attach your glass to the cockpit object, which cannot be categorized as glass. If you have an old plane with glass in the cockpit, consider cutting the object in half in a 3-d editor and attaching the glass separately.

(You should also use our prop disc animation, rather than use an OBJ for prop discs; the OBJ format doesn't contain the z-buffer tricks necessary to make the prop look right.)

The Four Minute Mile

Sometimes these posts get off topic, sometimes in the direction of the art of computer programming, sometimes in the nature of the industry, and sometimes with pictures of the pets. This post is going to go off a bit into the subject of project management.

Randy and Tyler posted what was becoming clear (by the lack of an already existing beta): our estimated release date for X-Plane 10 was incorrect. Software project delays are pretty common, and often when a third party add-on is delayed, the community jumps to speculate about "what's going on" inside the project and tries to infer whether the delay is an indication of serious problems.

I'd like to try to reframe the issue of delays in terms of an analogy. You ask me: how fast can you run a mile? I tell you "4 minutes and 15 seconds". I then run a mile and you time me. My time: 6 minutes, 10 seconds.* What can we learn from this episode? I think we can learn two things:

• For a computer programmer, I am surprisingly fast - a six minute mile isn't to be sneezed at when you spend your days sitting on your ass in front of a monitor drinking coffee.
• My ability to predict my own speed is not very good. I was pretty naive to think I could run a 4 minute mile - that's what world class athletes run. My estimate was off by a fairly big error margin.

One thing we should not conclude is that because my mile time was 2 minutes slower than estimated, that I am a slow runner. The estimate sets up an expectation, but if the estimate is wrong, it's not a useful metric of efficiency.

The same applies to X-Plane; we missed our original projected ship date because the estimation of when we would be done was not a very good estimate. This isn't good for a few reasons:

• It creates uncertainty for third parties as to when a platform will change.
• It makes it difficult for marketing to properly plan a roll-out.
• It makes it difficult to balance the value of more features vs. an earlier release date (since we don't know how much "time" we are trading for "features" if the time estimates are wrong).

But the delay is not at all a black mark for our team - on the contrary, they're working their asses off and creating some really great work.

When looking at a project that will be delayed (because the original schedule was wrong) there's a few things you can do:

1. Add more people. This is quite often the wrong thing to do - please read the Mythical Man Month to understand why. Once your team is the right size, adding more warm bodies usually makes schedule delays worse and hurts efficiency.
2. Remove features. This is the only real way to bring in a ship date.
3. Move the date back.

When Austin and I were working on X-Plane 8, we hit a similar scheduling problem - what we had set out to do was going to take a lot longer than we thought. (Like X-Plane 10, we had just doubled the team size and begun a project that involved massive rewrites, which made it hard to ship until the work was fully complete. Sound familiar?) The difference? With X-Plane 8 we had contracted to ship with an external distributor for Thanksgiving, so we had to go for item 2 - we cut scope. What we cut was the world - that is, we shipped new global scenery only for the US, and the existing ENVs for the rest of the world. We also had to ship the artwork we had on hand, despite being unhappy with its quality. We didn't finish the rest of the world and graphics we were happy with for another 11 months.

Option 2, cutting scope is painful and hard. Sometimes it is the right thing to do. In the case of X-Plane, however, we have the luxury to move the date back. With that in mind, we're trying as hard as we can to keep feature-creep minimal and finish what we've already bit off, so we can get the release done and out the door.

* My mile time is not 6 minutes, 10 seconds...I would be astounded, and quite possibly in the ER if I could run that fast for any sustained amount of time.

Curved Roads

At this point I can say with 99% confidence that X-Plane 10 will feature bezier curved roads. In X-Plane 9, a road is a line segment; you can simulate curved roads by using a lot of line segments, but the global scenery roads are pretty chunky.

X-Plane 10 allows for a road to be a bezier curve, allowing the specification of smooth curves with a small amount of data. This sets us up to trade off visual quality and performance using a rendering setting.

A few notes for authors:

• Like all of the new v10 road features (and pretty much all of the new v10 scenery features), you don't have to use bezier curves in your roads. They are there as an option if you want them.
• X-Plane 10 will not make curves for you; road data that is defined as line segments in the DSF will be rendered as line segments. (This follows the principle that DSFs contain pre-processed scenery data, and the sim shows DSFs exactly as they are written.)

Pay No Attention to the Documentation

The DSF specification alludes to bezier curved roads; this "old way" of encoding curves was never supported in the sim - all versions of X-Plane ignore this data. The "old way" was how we thought we might do curves some day.

The version 10 curve encoding is different; the "old way" will continue to be ignored in version 10. So: do not use the DSF spec to try to make curved roads now. I will post detailed documentation on curved roads once version 10 is available to authors.

A Cliff Shader

I have been stingy with pictures of next-gen global scenery for one reason: it's really hard to get a nice shot of the global scenery that doesn't show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can't take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn't finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.

I figure if it's obvious that the shot isn't a production shot, I can get away with posting it though.

A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.

So alpilotx sent this test: it's all of the Innsbruck area painted with a test texture. What's new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.

We are adding the cliff shader to version 10 for a few reasons:

• Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
• Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
• Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won't respond to GPU distortion.

Will X-Plane 10 Have X?

If I could have a dime for every email I have received that asks some form of "will X-Plane 10 have X" (where X is a feature or enhancement), I wouldn't need to actually work on X-Plane anymore. (If you think your email triggered this post, well, there are approximately 100 other users who have asked the same thing.)

Simply put: I have no idea and I'm not going to try to answer these questions any more. Here's why:

For as long as I have been involved with X-Plane, Laminar Research has provided free patches to the simulator throughout a major version run, and those patches have included not only performance enhancements and bug fixes, but also major new features.

So the question "will X-Plane 10 have X" can really mean one of two things:

1. Will X-Plane 10.0 have feature X immediately 'on the DVD'?
2. Will X-Plane 10.x ever have feature X in a free patch before the major version run is over.

I can answer the first question, because we are relatively locked down on what features are still on the table for 10.0 vs. what must wait, but I think it's at best confusing to do so. If a feature isn't on the DVD, it might be in a free patch within weeks; it might be available by the time you get your DVD. Whether a feature is on the DVD is of interest to us as we plan our release, but I don't think it actually makes a huge difference to users with internet connections.

Consider 64-bit - it's something we want to look at during the version 10 run but we're not going dig into it until after we get 10.0 out. So will 10.0 be 64-bit? No. But there will probably be a 64-bit patch available for free. I think you can see why I don't want to post "X-Plane 10 will not be 64 bit."

I cannot possibly answer the second question, because versions run over several years, and what we code for the end of the version run will depend on market conditions and technology that don't exist now. One of the nice things about patching X-Plane frequently is that we can revise our plans as conditions change.

Consider the question "how many cores will X-Plane 8 utilize" had you asked the question during X-Plane 8.0. When X-Plane 8.0 came out, the answer was "only one" and we had no road-map to change that. For that matter, multi-core machines were rare and exotic beasts at the time, so multi-core wasn't a priority.

Within the three years of X-Plane 8's major version run, we ended up supporting multi-core for scenery mesh loading, something that couldn't have been easily predicted at the beginning of the version run.

Finally, a note on release planning: now is absolutely not a good time to ask for features. The features that will ship in X-Plane 10.0 have already been determined, and since we'd like to ship X-Plane 10 sooner rather than later, I don't think there's anything you can say that would make us add a feature to 10.0.

All future features are going into a 10.x "bucket" for planning purposes. Since Austin, Chris and I are up to our eyeballs in code and the art team is red-lined too, we're not spending any time sifting through 10.x buckets right now. If you send us a feature request, the very best case is that we dump it in a holding list for later; the worse case is that we lose track of the request in the chaos.

That doesn't mean that we don't care about 10.x. It's just that we are very much heads down in the 10.0 release now and won't look up until it's done.

Draped Object Geometry in X-Plane 10

I have mentioned a few of the scenery engine features coming in X-Plane 10 that will be of interest to authors: global illumination, conditional parts of OBJs (to cope with variable rendering settings). There is another general feature coming that will make authoring scenery a lot easier, I hope.

X-Plane 9's rendering engine has the ability to drape geometry. Draped geometry are meshes that are 'dropped' onto the terrain and hug the underlying base mesh perfectly. The most common example of this is the runways: because the runways 'drape' the ground, the runway shows any curvature and bumps from the underlying base mesh. This is who we create sloping and non-flat runways.

Authors can drape geometry as well, using a draped polygon (.pol) primitive in an overlay. Such draped geometry is useful any time you want to add more "paint" to the ground, e.g. to put down a taxiway, parking markings, dirt, grass, a driveway for a house, you name it.

There is one case in X-Plane 9 where you cannot drape geometry: in an object. In an object, all geometry is aligned to the object, and will only interact nicely with the ground if you get lucky. For example, if you model a house with a sidewalk, the sidewalk won't "sit" on the ground if the ground turns out to be sloped. You can use ATTR_poly_os to hide the artifacts, but ATTR_poly_os really can't cope with mismatches between the OBJ and the terrain under it.

X-Plane 10 will introduce a new object attribute: ATTR_draped. Draped geometry in an object is actually draped down onto the terrain when the object is placed in the scenery. This means that the draped part of the object will hug the ground perfectly with no interference or Z thrash. You get all of the quality of a draped polygon with the convenience of an OBJ.

There are a few possible uses for ATTR_draped:

• Any time a 3-d model needs some ground details attached to it, e.g. the driveway near a house, draped geometry provides a good fit with the ground and good alignment with the object.
• Any time you want to include a pre-made ground decal (E.g. a painted parking spot on a taxiway), the ground detail can be modeled as an object using draped geometry.

ATTR_draped will facilitate creating and sharing custom details for airports and streamline the authoring process.

Scenery Compatibility and Version 10

This is my expectation for scenery compatibility in X-Plane 10:

Scenery based on DSFs, OBJs, and other version 8/9 file formats should work with X-Plane 10 unmodified.

This includes orthophoto scenery based on DSFs - we're not throwing that code out.

The new rendering engine features for version 10 (and there are a lot of them) are extensions - new ways to render things, new types of art assets.

I do believe that we may drop support for ENV scenery files in version 10. We've had DSF for six years now, and ENV's capabilities (a 500m mesh, very limited orthophoto resolution) aren't useful to today's users. You can use DSF2Text/XGrinder to extract custom object placements from an ENV for use in a new overlay.

We may also drop support for OBJ version 2. (Yes, we still load OBJs version 2.) OBJ version 2 is the OBJ file format from X-Plane 6, the one before OBJ 7. If you have any old OBJs (version 2 or 700) you can use XGrinder to automatically batch convert them to OBJ8.

Coping With Variable Rendering Options In X-Plane 10

X-Plane 10 will have rendering options for global illumination and global shadows. This leaves one question: what if the user has these features disabled?

The plan for version 10 is this: the OBJ file format will have some extensions to allow conditional commands based on rendering settings. A few notes on these conditional commands:

• They will only be based on rendering settings.
• They will be evaluated once when the object is loaded. (If rendering settings change, the object will be reloaded.)

The idea is to be able to change which lit texture you use or remove a set of shadow polygons depending on rendering settings.

The conditionals are evaluated once at load time so that the object can be fully optimized based on the particular set of conditionals used. For example, if your drop shadow (with ATTR_poly_os) is fully removed at load time (because global shadows are on) your object now has fewer attributes, which is good for frame-rate.

This is very different from ANIM_hide. The hide animation may or may not hide depending on datarefs; to keep this fast, you cannot "hide" an attribute, only triangles. This means you "pay" for your atttributes no matter what.

The motivation for both designs is this: if the set of attributes in a file never changes (e.g. they are either conditionally removed at file load once, or they are always present regardless of animation) then we can optimize the attributes of an object once knowing how they relate to each other, to create the leanest, meanest OBJ.

No One Has All of X-Plane 10

I commented on this before, but, like the Funniest Joke in the World, no one team member has all of X-Plane 10. We're all working away madly at our own parts, separately. This means that if one of us has code or art that isn't quite ready for prime-time, it hopefully doesn't slow anyone else down too much.

I mention this because I see a lot of commentary on the X-Plane 10 preview pictures where the comment is analyzing a part of the picture that actually isn't X-Plane 10 at all! Those pictures are coming right off of developer machines, and that developer probably has some new stuff and some old stuff. Not only does the developer probably not have everyone else's parts of X-Plane, but that developer probably has everything except his own work turned off or way down to keep sim load time down. I don't fly with 20 AI planes when I work on scenery, and Austin doesn't load full scenery at max res when he works on the flight model.

So when you look at the screenshots, just bear in mind that they are showing one new piece of technology pretty well, and pretty much everything else on screen is going to be hit or miss.

Orthophotos Are Not Going Away

I mean to blog this a while ago, and Austin has moved on to new missives about the future of X-Plane, but:

A while ago Austin posted to the news list describing our approach to global scenery (that is, the scenery that ships with the sim), and he said some, well, rather disrespectful things toward orthophotos:

Orthophotos are garbage. I see this all the time. I am zooming along in an airplane looking that rooftops of WalMarts painted flat onto the ground. And the rooftops are blurry. And pixelated. And with a magenta or purple tint. And with big blurry shears right through the middle of them when they fall between offset satellite passes. It looks just terrible.

So first let me point out a few obvious things:

1. There was never any chance that the global scenery would be based on orthophotos - not in v8, not in v9, not in v10. Simply put, we can't ship you 900 DVDs in a dump-truck. Orthophotos of any reasonable quality are too large for covering the entire world in the base X-Plane product. This is not a change or new to v10.

2. X-Plane is very capable of handling third party orthophoto scenery. We invested a bunch of engineering in this in the v9 run, and that code is not going away in v10. X-Plane will page orthophotos on multiple cores so that you get smooth flight and crisp images. If you want to see some orthophoto that don't look blurry or pixelated, look here.

3. DSF-based scenery that works in X-Plane 9 will work in X-Plane 10, unmodified. We are not getting rid of any modern scenery file formats.

Beating Ourselves Up

Austin continues in his rant^H^H^H^Hdiscussion, with this:

Then, to make the 2-dimensional, blurry, pixellated, mis-colored, distorted roof of a WalMart painted on the ground look even worse, if you throw in some REAL roads or auto-generated buildings, they invariably fall ACROSS the roof of the WalMart painted on the ground, compounding the wretched orthophoto with an Escher-like rendering-error. This looks terrible, and is not even plausible.

This is a critique of the version 8 and 9 global scenery. In fact, it is an observation of the fundamental problem with the urban global scenery: we never found a way to synchronize the real-world-driven and real-world derived 3-d scenery (real roads with plausible buildings and forests in between) with the photo-based land-class textures running underneath.

Ironically, this is not a problem with orthophotos (that is, specific photos placed in the world where they belong) per se. It's really a problem with how to combine 3-d with land class textures. I don't believe anyone has solved this problem yet for global scenery; if you look at FSX, there isn't a lot of real world vector data to interfere with the land classes and their autogen.

In fact, orthophotos can look very good when they are combined with 3-d in a correlated way. For example, take a look at this screenshot of FlyTampa's KBUF . They are using an orthophoto but they are putting matching 3-d on top of it, which makes things look good close up.

The Global Scenery Problem

I'll leave you with this thought: the problem for the version 10 global scenery is to combine:

1. the plausibility that you get from having synchronized 3-d and ground textures.
2. the detail we've come to expect in photo-based scenery textures.
   
3. the realism you get from using real vector data for the real world.

The current global scenery manages points 2 and 3 but fails pretty badly on point 1. That is what we are trying to address in X-Plane 10.

Airport Layouts: Your Cutoff is 10/10/10

If you are planning on submitting an airport layout to Robin so that it is used to flatten terrain in the X-Plane 10 global scenery, please submit the layout to Robin no later than October 10th, 2010 (that is, 10/10/10).

If you have an incomplete but useful layout (e.g. the airport border is in place but not the taxiway signs, you can still submit it; we only consider border outlines and the pavement itself when flattening, not markings.

You do need both the border outline and all existing pavement. The reason for this is that the airport border is used to change the land class to grass, but water is only converted to land (if we have a coastline error) base on real pavement.

More info on airport layouts and how to submit data to Robin can be found here.

Revisiting Texture Compression

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:

1. Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
2. 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.
3. 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.

Feature Requests for X-Plane 10

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:

1. Microsoft closed ACES, which definitely changes what we want our next major release to look like.
2. 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.