This Is Where SRTM Comes From

My family visited DC this weekend and we went out to Udvar-Hazy, the extension of the Smithsonian aerospace museum out near Dulles international airport. My dad took this picture.

That is one of the two radar antennas (and the telescoping arm) used to scan the earth as part of the Shuttle Radar Topography Mission (SRTM). The SRTM is basically the first really good quality most-of-the-earth elevation dataset, and it is the main (but not only) source of elevation data for the X-Plane global scenery.

The telescoping mast shown in the picture (horizontal) extends one of the two radar antennas away from the shuttle when in orbit; had they not been able to retract the antenna they would have had to detach it and leave it in space. Fortunately the mechanism worked properly, so they were able to bring the antenna back for posterity.

Contractual Ranting

Microsoft extended Windows XP sales yet again, more or less.  But rather than rant about how the Vista user experience makes me want to tear my fingernails off or how brain-damaged it is to try to put DRM into drivers, let me instead focus on Windows as an example of the cost of contracts.

I have ranted in the past about how the boundary between X-Plane and a third party, or the plugin system and third parties, or even two third parties, is a contract.  Consider:

• The named light list forms a contract between X-Plane and objects, e.g. X-Plane guarantees that there will be a named light called "airplane_landing" and that it is a good choice for landing lights.  (This implies that X-Plane won't change what it looks like to be inappropriate for landing lights, and that third parties won't use it for inappropriate uses, like airport apron lights.)
• XPLMGetDataf forms a contract between the plugin SDK and plugins, guaranteeing that there will be a function in the XPLM called "XPLMGetDataf" that takes a dataref and returns its value.  (This implies that Sandy and I won't rename it or change its arguments or remove it all together, and that plugins won't pass non-datarefs in as arguments.)
• Even a paint kit forms a contract - the airplane maker is essentially saying "the tail will be mapped to the upper left of the texture, and I won't remap my UV" and the livery maker is saying "I will put an image in the upper left corner that looks like a tail."

By comparison, the clouds are not a contract - there is no way third parties can customize the look of the clouds, so we can change the algorithm by which we create them pretty much at will. We could switch to a volumetric approach for all clouds or even go back to 2-d without worrying about third party interaction.

Okay - that's a lot of words about contracts...what does that have to do with Vista?  Well...

The Cost of Changing the Contract

Two major aspects of why Vista has been a worse experience for users than Windows XP come directly to the need for Microsoft to change contracts.

• For years, applications have run on Windows with admin rights.  This is not good - it means that any process can do serious damage to the system if hijacked - and on Windows processes get hijacked on a fairly regular basis!
• For years, audio and video drivers have run pretty much unprotected.  This was good from a performance perspective, but also caused a lot of BSODs.  On Windows, drivers are third party components and are quite possibly not checked by Microsoft (especially video drivers) so letting them run without protections is risky.

In both cases, the problem is that the old contract is both (1) poorly designed* and (2) being used by a lot of third parties.  What choice did Microsoft have?  Continue to let apps run in admin mode and hijack the whole machine any time the user picked up a virus?  Or change apps to run in user mode and hope that the applications didn't depend on this guarantee?

(At this point, Raymond might go ballistic and point out that the Windows API doesn't really promise admin rights and apps should not have been doing all of these naughty behaviors in the first place.  I don't know what the Win32 API declares...the difference between what a platform declares and what it does is important enough to warrant another post.  Certainly with X-Plane we have to worry a lot about third parties depending on behavior that was unintentional but turned out to be useful.)

Vista has been a difficult transition because it changed a bunch of rules (that needed to be changed).  In the long term, I am sure that both of these decisions are for the better -- eventually applications won't be counting on administrator rights, so we won't have to fume about UAC (or shut it off), and a hijacked web browser won't be nearly as dangerous.

On the video driver front, the Vista experience is pretty reasonable now - there has been a lot of improvement since Vista first came out.  I expect applications and UAC to take a lot longer - video drivers get revised quite frequently; applications seem to linger around forever.

I'm Not Signing That

If we end up with a situation like this in X-Plane (the contract is used heavily by third parties and not well designed) we only have two options, and they're both bad:

1. Break the contract.  Third party content stops working, users are angry, authors are angry.
2. Stick with the contract and mitigate as best we can.  Usually this means writing more code (slows down new features), using a less optimal implementation (lowers frame rate), etc.

This is why my first reaction to any file format extension is: "is this going to be a PITA in a year"?  The benefit might be visible now, but the cost could plague us indefinitely.

What You Want, Not Where You Want It

If you would like to request a feature, tell me what you want, not where you want it implemented.  I bring this up because many of the feature requests I get are very specific and describe an implementation, not a goal.  (To draw an analogy, it's as if I call a general contractor and say "dig a big hole right here" without telling him "it is for a swimming pool".)

The reason "what not how" is so important is because many of the "how" implementations that people send me involve creating new contracts with third parties.  I am going to try to design the feature with the minimum contractual obligations - that is, to do just what is intended and hopefully not much more.  

But if I can't tell what you are trying to do, I can only say "I won't code this implementation - the cost of long term support due to contractual obligations outweighs the usefulness."  It might be that there is another way to implement the feature that would not put a long term burden on the scenery system or airplane SDK and still provide all of the benefits.

* Poorly designed?  Or perhaps well designed for a previous problem - if the problem changes, the design might not be appropriate.  Or perhaps not even designed at all - sometimes contracts evolve without a lot of central planning.  All of these things have happened in X-Plane.  In the case of Windows, I suspect it's the previous-problem case -- that is, what made sense for much smaller computers where the scope of what could be done was quite limited no longer makes sense for big modern computers that are capable of a more expensive and robust solution...just my speculation.

To Wiki

Thanks to those who replied to my previous post...and my decision is: to wiki.  It's relatively easy to make the Wiki look as good (and I use the term good loosely) as the non-Wiki scenery website. By comparison, it would be very complex to make the scenery web-site interactive and faster to update.  (And update ease is very important - one of the reasons why there is so little documentation on the scenery website is that it is so hard to document.)

So...as a beginning, I have reskinned the wiki.  (If you want the old look, create an account and pick the old skin, called "monobook" in your preferences.)  If you don't like the new look, you can send me a new style sheet or even an existing MediaWiki 1.9-compatible skin...I can install it and can select it in your preferences.

I have also installed some extensions that should help add additional flexibility (for example, the Wiki can now have image-based links).  Over the next few days I will try to clean up the front page a bit to provide a clearer navigation structure.

One thing we will need on the Wiki is...WikiGnomes - that is, users who help to organize and polish the content for readability.

In the long term, I would like to migrate scenery.x-plane.com to the Wiki.  But for now that is lower priority than creating new documentation.

Testing on Old Hardware

If you run X-Plane 9.21 (or 9.22) on a Macintosh with an old ATI or nVidia graphics card (with no pixel shaders), you somehow squeeze 25 fps out of X-Plane*, and you can try a test build, please email me.

Those cards include:

• Radeon 7000-9200, inclusive.
• GeForce 2, 3, or 4 series.

I have a change in the panel code that I need to performance test against older hardware!

* Basically you would have to really crank the settings down - but I think under some really baseline settings these machines might be able to run X-Plane 9 without fogging.

To Wiki or Not To Wiki

You might not believe this (due to the general lack of scenery system documentation) but I do spend some brain power thinking about X-Plane documentation for third parties!

Consider two approaches to documentation:

• http://scenery.x-plane.com/
• http://wiki.x-plane.com/

My question is: which of these approaches is more "readable" or "clear" to you as a third party? Each one (the formal website vs. the Wiki) has pros and cons, but I can't judge "usability" of the documentation myself.  Is it easier to find things on the website?  On the Wiki?  Comments welcome!

(I need to decide where to put future documentation, hence the question "which works better for those who read the documentation.)

The New iPhone Apps Are Here

Besides X-Plane for iPhone (which I now call "X-Plane general aviation" to avoid confusion) there are now two new apps: X-Plane Airliner and X-Plane Helicopter. The helicopter version uses part of the Grand Canyon and the airliner version uses part of Southern California.

All three apps (the general aviation version has a free update) have a fix in the DSF lower that should help avoid crashes.

Basically while X-Plane used to run under memory limits for the phone, it would temporarily go quite a bit over memory the limit during the DSF load, as the DSF loader would use some temporary memory. The new code very carefully purges temporary memory as it runs, and thus never exceeds its final memory footprint. Before 9.04 there was always a risk that your phone was in a tight memory situation to begin with, such that X-Plane going "over budget" would cause the OS to kill it off. (Rebooting the phone apparently purges memory or something.)

So...this is a long-winded way of saying: if you update X-Plane iPhone to 9.04 and still have the app quit at launch (or right after launch), please send us a crash report!

More Aircraft RFCs - Landing Lights

It looks to me like we could afford a few landing light halos on most (but not all) hardware.  This gets a bit tricky in terms of how we make this available to authors...

• We have to allow access without breaking old planes.
• There will be two distinct cases due to very different hardware.

So...I have posted an RFC on the X-Plane Wiki.  Please post your thoughts on the discussion page!

One option (not really discussed in the RFC) is to do nothing at all.  Basically I hit upon this during some routine refactoring of the shaders.  The whole issue can be deferred indefinitely.

Why wait?  Well, I don't believe that an incremental increase in the number of landing light halos is the future.  Our end goal must be some kind of truly global illumination, hopefully without a fixed lighting budget.  It may not make sense to add a bunch of complexity to the aircraft SDK only to have all of those limit become unnecessary cruft a short time later.

(I think I can hear the airport designers typing "why do the airplane designers get four lights and we get none?  Give us a light or two!"  My answer is: because of the fixed budget problem. We can allocate a fixed budget of lights to the user's aircraft because it is first in line - we know we either have the lights or we don't.  As soon as we start putting global lights in the scenery, we have to deal with the case where we run out of global lights.  For scenery I definitely want to wait on a scheme that isn't insanely resource limited!)

Programmers: yes - Dx10 hardware can do a hell of a lot more than 4 global lights.  Heck - it can do a hell of a lot period!  For example, it can do deferred rendering, or light pre-rendering. A true global lighting solution might not have anything to do with "let's add more global lights a few at a time."

Shader Optimization Fallout

Every time I work on a new X-Plane feature, I do a combination of:

• Reorganizing and cleaning up old code.
• Adding new features.
• Tuning performance for this new environment.

My experience has been that the investment in cleaning up old code is more than paid for by faster, easier development of new code - it's easier to code in a "clean" work area.

As part of my work on 930 I am refactoring and optimizing how we set up pixel shaders.  I'm not sure if there will be any framerate benefits in the short term, but in the long term there is definitely an advantage to being able to set up the most optimal shader configuration for any situation.

(Since most of what we draw - OBJs, airplanes, DSFs) can be created by users, we never really know what we'll be drawing...the set of art content X-Plane can handle is almost unlimited.  So it is up to shader optimization code to "find" the optimal setup for a particular stew of OBJ attributes, textures, etc.)

The short term fall-out during beta is unfortunately a certain amount of pain.  It's likely that these changes will introduce graphic quirks with certain combinations of planes.  These are fixable!  The important thing is: if you hit a graphics bug with a particular plane or scenery pack in 930 (whenever we get to beta - we are not in beta yet!) and that bug is not in 921 - report it! It may be that the optimizer is being too aggressive with a particular combination of settings and turning off some critical feature.

I will run the new shader optimizer code through just about every scenery pack and airplane I can find, but invariably there is some magic trick in a third party plane on the .org that I won't have.

One thought for creating fast content: alpha is expensive!  Or rather, let me rephrase that to: if you are not using the alpha channel of your texture, you should not have an alpha channel in your texture.  

(For PNG this means stripping the alpha channel off, rather than having a solid 100% opaque alpha channel.  For DDS this means using DXT1 with no transparent pixels.)

The new shader optimizer detects the case where alpha is not being used and sets up a more optimal code path.  (The old shader optimizer did that too, but only some of the time - in the new code, we will always take this optimization.)

Having alpha blending enabled can inhibit "early-Z" optimizations on modern GPUs, and also require a more expensive blending operation in the framebuffer.*  So if your model doesn't use alpha, strip the channel.

* Some newer graphics cards recognize 100% opaque alpha and provide fast write to the framebuffer.  But even if early-Z-type optimizations become alpha friendly, there will still be optimizations we can make in the sim if we hit the no-alpha case.

Liveries vs. Configurations

I want to revisit the question of whether (and how) the livery system should be extended. In particular, it is my opinion that the livery system should not be extended to allow:

• Replacement of OBJs used for modeling the airplane or cockpit.
• Alternate or modified ACFs*.
• Generally, the livery system shouldn't be used for changing the plane's behavior - it's just paint!

I have commented previously in three parts that the livery system is meant to make easy the integration of third party paint without (a) violating copyright, (b) requiring byzantine installation instructions or (c) requiring the painter and original author to coordinate. I have received requests from a number of very talented airplane authors, asking for the livery system to cover a whole range of new features, most of them involving configuration. I will try to explain in this post how I think should should be handled.

First, to be clear: an aircraft file is the .acf file that contains the X-Plane specific data needed to simulate the plane; the aircraft package is the folder containing that .acf file. A livery is a painting scheme for the 3-d model of the airplane, and a configuration is an instance of a plane with certain features, e.g. with or without G1000, with P&W vs. Rolls Royce engines, etc.

Configurations of an aircraft should be created by putting more than one aircraft file
(.acf) in a single aircraft package. Because the graphic and sound resources needed for the aircraft are accessed relative to the .acf file, you can build a family of aircraft with some common aspects and some unique aspects to each plane.

Files used by an aircraft fall into three broad categories:

• Files found by a fixed formula using the .acf name, e.g. be20_paint.png. Let's call these "file-specific".
• Files found by a fixed formula without using the .acf name, e.g. the contents of the aircraft plugins folder. Let's call these "package specific".
• Files that are explicitly named in the .acf file, like airfoils and OBJs. Let's call these "flexible" (since this naming scheme could be used in any way).

Here's how the important files in an aircraft break down:

• The aircraft paint scheme is file specific.
  
• The aircraft panel background is package specific (but you can effectively have each file use a different panel background by setting the panel type differently for each plane).
• Sounds are actually either, which effectively makes them flexible. Non-generic instruments are package-specific.
  
• Objects, generic instruments and airfoils are flexible.

In other words, if you can live with duplicating your aircraft paint files (and I suspect that in most cases either the plane is built by objects, or the modifications in each configuration warrant paint changes anyway), then every other feature can be set to package or file specific, allowing you to build a group of aircraft around a single real-world plane.

Now if there are aspects of a multi-configuration aircraft package that don't work right now, we can look at possible changes to the sim to make this work. But it appears to me that just about everything necessary to make multiple configurations is already available in the sim now.

As a final note, the question here (livery vs. multi-file aircraft pack for configurations) is one of file formats, and thus of data organization and contracts between authors and programmers. It is not a question of user interface. The user interface can be reshaped to make multi-aircraft packages look like liveries, or liveries look like multi-aircraft packages. But I suspect that most of the interest in extended liveries is on the file-format side.

* The one exception for liveries is the tail number -- given the strange state where the tail number, as painted into the livery, is also written into the ACF, it wouldn't be bad to be able to override this property. Some people are already doing this using plugins.

The impenetrable Object Barrier

Some coding problems are stubborn - I find myself looking back at a week of working realizing that all I really did was prove that a bunch of theoretical improvements don't work in practice.

Improving OBJ throughput is one of those problems.  On a high-end machine, even drastic changes to the OBJ engine make only the slightest difference in throughput - 2 or 3% at best. Every improvement counts, but a 3% improvement doesn't change the game for how we draw scenery.

There is at least one route I haven't had time to go down yet: object instancing.  The theory is that by making many objects appear with only one object drawn, we get a multiplier, e.g. a 2x or 4x or larger amplification of the number of objects we can have.

In practice it won't be that simple:

• To get such an amplification we have to recognize groups of the exact same object.  Grouped objects will have to be culled together.  So we might get a hit in performance as we draw more objects that are off-screen, just to use instancing.
• It may be that the grouping requirement is so severe that it is not practical to find and group objects arbitrarily (instead we would have to group objects that are built together, like clusters of runway lights).  That might limit the scope of where we can instance.
• The objects have to look more or less the same, so some categories of very complex objects won't be subject to instancing.  (E.g. objects with animation where each object might look different.)
• I have already coded some experiments with geometry shaders, and the results are just dreadful - geometry shaders simply don't output a huge number of vertices efficiently, so they don't help us increase our total vertex throughput.  The experience has left me with a "prove it" attitude toward GL extensions that are supposed to make things faster.

When will we know whether instancing can help?  I don't know -- I suspect that I won't be able to find time for code experiments for a bit, due to other work, particularly on scenery creation and tools.

Moving Features to the GPU

A hidden detail of my previous post on variation and terrain textures: variation for flat textures was implemented using more triangles in the DSF in X-Plane 8, but is implemented in a shader in X-Plane 9.  This means that you don't get this feature in X-Plane 9 if shaders are off.

My guess is that this is perfectly acceptable to just about every user.

• If you don't have shaders, you have something like a GeForce 4 or Radeon 8500, and are fighting for frame-rate.  In this case, not paying the price of layer-based variation is a win.
• If you have shaders, you're getting better performance because the shader creates variation more efficiently than the old layering scheme did.

This kind of move of a feature to the GPU can only happen at major versions when we recut the global scenery, because (to utilize the benefit) the DSFs are recut with fewer (now unneeded) layers.  So features aren't going to mysteriously disappear mid-version.

I do have a goal to move more layering-type features to the GPU for future global scenery renders.  There are a number of good reasons:

• DSF file size is limited - we have distribution requirements on the number of DVDs we ship.  So DSF file size is better spent on more detailed meshes than on layers.
• GPU power is increasing faster than anything else, so it's good to put these effects on the GPU - the GPU is still hungry for more!
• If a feature is run on the GPU, we can scale it up or down or turn it on or off, for more flexible rendering settings on a wide variety of hardware.  A feature baked into the DSF is there for everyone, no way to turn it off.

My hope for the next render is to (somehow) move the cliff algorithm (which is currently done with 2-4 layers) to the GPU, which would shrink DSFs, improve performance, and probably create nicer looking output.

Auto-Variation and Repetition

In my previous post I discussed variation as a way to hide the artifacts of land use texturing. Now we can talk about this bug.

What are these weird artifacts that show up over the terrain when shaders are on?  Well, they should (and will in 930) look like this:

But what's going on?  The answer is auto-variation.

In X-Plane 8, variation is created by using multiple layers, each one applying a texture at a different offset.  This technique works on a wide range of hardware, but is inefficient - it causes overdraw (which we know is very bad).  

So in X-Plane 9 I replaced this layer-based variation with a pixel shader algorithm.  This means less information in the DSF (which means smaller DSFs, faster loading and less RAM use), but it also means variation is only visible to those with shaders.  Having the pixel shaders create variation dynamically on the GPU is called "auto-variation" (and is invoked via the AUTO_VARY command in a .ter file).

The artifact above was a bug in the auto-variation shader.  With the code now fixed (the 930 patch will contain the fix), here are some images of how it is supposed to work:

Here we have the texture in question, at two different offsets.


This black and white texture is the "mixing mask" used to select which offset to use.

And this is the final result.

There is a little bit more disruption in the columns of green park.

Dealing With Repetition

I was going to post some pictures of the newly fixed "auto-vary" feature, but before I can do that in a way that makes any sense, I need to explain how X-Plane deals with texture repetition.

Texture repetition is the inevitable result of using "landuse-style" texturing (that is, a repeating single texture representing a type of land).  Typical X-Plane land use textures are 1024 x 1024 at max res and repeat about every 3-5 km.  Unfortunately, our brains are pattern-recognizing machines, and the result of this texturing scheme is that the "grid lines" of texture placement become apparent over wide views.  

We use a number of techniques to minimize this problem.

Lots of Land Uses

Our main tool to combat repetition is to not use a given land use for too large of an area.  This has the advantage of efficiently using the entire set of textures, and (because terrain textures change based on an irregular grid, based on elevation) the changes to textures are both irregular in shape and "plausible" in placement.

In this picture, you can see that the urban residential land use has been interrupted by various forest and grass textures.  This is intentional - Sergio tuned hte land use rules to make sure that we wouldn't have large regions of one land use type.  Those blobs match the irregular grid, which gets its shape from the terrain's elevation.

Variation

In the above picture, you can still see the repeating grid of the residential terrain; observe the right side - you'll see the same repeating vertical pattern of road repeating over and over.  In order to further hide repetition, we use the same texture multiple times, but in offset locations.

Here you can see that the vertical line on the right side has been broken up a bit.

More VRAM

In some cases, a terrain covers such large areas despite the rule set (e.g. for really flat areas) that we use two separate textures and can vary between them.  Here you can see both input textures for our dry square crop land use, as well as the combined results.

In summary, we have three techniques:

1. Add more rules to prevent large spans of a single land-use.
2. Use a texture with multiple offsets (variation)
3. Use two textures and vary between them.

The "Airplane Modeling" Datarefs

I have blogged about this before, but I will try to create one simple explanation of what's going on with sim/cockpit2 and sim/flightmodel2 datarefs.

Sandy and I (with the help of others who helped compile the list) created "new" datarefs (first released with X-Plane 9) , aimed at airplane modelers. These new sections are:

1. sim/cockpit2/ which provides a new set of datarefs for cockpit modeling via OBJ animation and generic instruments.
2. sim/flightmodel2/ which provides a new set of datarefs for airplane exterior modeling via OBJ animation.

These datarefs sometimes include new data that was not available in version 8, and sometimes they simply provide a second dataref with the same information. Why duplicate datarefs? The new datarefs have some special properties, so I wanted to have a complete set of datarefs for modelers with these new properties.

Skip to the end for the rules of thumb on how to use them.

Clean Naming

The new datarefs are designed to have longer, less confusing names; the old datarefs contained a lot of abbreviations - potentially acceptable for programmers (who are used to seeing things like fstat and chgrp on a regular basis) but not good for modelers who do not speek English as a first language. The new datarefs have long names and are more consistent in their conventions. They also contain complete documentation.

Array Sizes

You will see the array dimension of some of the new datarefs as symbolic constants, e.g. [engine] instead of [8]. This is because the dataref generation system we use knows that these new datarefs sometimes track the maximum number of parts in the aircraft structure. This tagging means that it is much simpler for Sandy and I to adjust the datarefs when Austin increases part maximums.

With the old datarefs, if Austin allows for 10 engines, Sandy and I must search for every [8] dataref and decide if it must be [10] - some will be per-engine and need to change, some will be per-battery and will not! With the new system, we simply redefine the "engine" constant to 10 and the datarefs adjust.

(Note that if your plugin really needs to run dynamically with any number of engines, the best thing to do is to read the array size using XPLMGetDatavX.)

Failure Support

There are two ways to view a dataref: before system failures (such that the dataref reflects simulated physical reality) and after system failures (such that the dataref reflects pilot indications). For example, when the pitot tube ices up, the pre-failure airspeed reflects how fast you are flying; the post-failure airspeed reflects how much crud is in your pitot tube.

Pre-failure datarefs are appropriate for animating the exterior of the airplane. For example, if the gear indicator light fails but the gear is working, you want to animate your landing gear based on the real (pre-failure) gear position, so that the gear really does look like it's down from an outside view.

Post-failure datarefs are appropriate for animating the cockpit. For example, you want to use that post-failure indicated airspeed for your air speed indicator, so that pitot ice will affect your generic instruments and animations, as well as the built-in instruments.

The new datarefs are designed to clearly provide two different views:

• sim/cockpit2/ are all post-failure whenever possible, and are thus appropriate for cockpit modeling.
• sim/flightmodel2/ are all pre-failure, and thus are appropriate for external airplane modeling.

Be careful not to swap them! You should always be using sim/flightmodel2/ for your aircraft and sim/cockpit2/ for your cockpit. If the dataref you need is in one and not the other, email me and I will add it to the right place.

Correct Multiplayer Behavior

The older datarefs all return data about the user's airplane. However if you build an object, attached to an ACF, and that ACF is loaded for a multiplayer plane, you will get incorrect results -- the user will see his own plane's actions visualized on the multiplayer plane.

The new sim/cockpit2/ and sim/flightmodel2/ datarefs handle this case correctly: they return data about whichever airplane is being drawn. Thus if your object is attached to airplane number 5 in a multiplayer session, that's the airplane that will animate your control surfaces.

(Plugin developers - outside airplane drawing, these datarefs return information about the user's flight.)

For this reason, you should always use sim/cockpit2/ and sim/flightmodel2/ - not the older sim/cockpit and sim/flightmodel/ datarefs. If the dataref you want is only in the old sections but not the new ones, email me!

What Dataref Do I Use?

Here's the rule of thumb:

• If you are targeting X-Plane 6/7/8, you must use sim/cockpit and sim/flightmodel, otherwise
• If you are targeting X-Plane 9, use sim/cockpit2 for your generic instruments and 3-d cockpit. Use sim/flightmodel2 for your attached objects.

That's all there is to it!

Bug Fixes in the Pipeline

A few things are in the works:

• The X-Plane messaging system, which checks for updates, can hang up if DNS isn't available. I should have fixed this a lot sooner, but this will be addressed in a very small 9.22 patch, in the process of being built now.
• 9.22 will also include Robin's latest apt and nav data.
• For Linux users: 9.22 should work with threaded OpenGL on newer distros - thanks to Jan for sending me the code snippet to fix this!

And on the iphone front: the next X-Plane iphone free update should improve memory use during DSF load.  This in turn will hopefully address the application suddenly quitting on "loaded" iphones (that is, iphones with a lot of email accounts or other background tasks that use memory).  Memory was temporarily spiking as we optimized the DSF during load. I am not sure when this will make it to the iTunes store.

I am looking at OpenAL on Linux, but this will have to wait for 930 and a longer beta program. 922 will also not have a FADEC - 922 is a quick bug fix patch, not a feature release!

Two Video Cards, Two Vendors

The short answer is: this is not a very good idea.

Now with OS X, this configuration is supported, and OS X will cleverly copy graphic output from one video card to another to make the system work well. You will get a fps hit when this happens.

With Vista, this configuration isn't supported. (Snarky comment: it is lame that Microsoft completely rewrote their video driver infrastructure and went backward in terms of configuration support.)

With Linux, I have no idea if this configuration can run. I do know that trying to change my configuration hosed Ubuntu thoroughly and I decided not to break my Linux boxes any more, having spent plenty of time doing that already in the last few days.

For X-Plane, we can't handle this case very well (at best you get the framerate hit) because we need to share textures between the IOS screen and main screen. So if you are trying to set up an IOS screen, you really do need a dual-headed graphics card. For what it's worth, every card I've gotten in the last few years has had two video outputs.

Fun With Menubars

My Mac Pro has just gotten weirder - I put a Radeon HD 3870 into the second PCIe x16 slot. (The machine comes with  a GeForce 8800.)  I now have one monitor in each.

So here's where things get fun:

• Start X-Plane.  60 fps.
• Drag the window to the second monitor.  30 fps.
• Quit, move the menu bar to the second monitor, restart.  (X-Plane is now on the right.)  160 fps.
• Drag the window back to the primary monitor on the left.  100 fps.

What's going on?  Two things:

• On OS X, X-Plane's graphics are rendered by one video card, and that video card (in 921) is the card that has the menu on one of its monitors.
• When an OpenGL window is displayed on a monitor that is not attached to the video card that is doing the rendering, OS X will copy the image from one video card to another, at a cost of some framerate.

So what's going on above?  Well, the 60 fps is my 8800.  When I drag the window, the OS starts copying the graphics, slowing fps.  When I move the menu bar, the 3870 does the rendering, and we get much higher fps.  Once again, put the window on the monitor that is not attached to the video card, and fps hit.

Final note: fps tests of the 8800 vs 3870 with X-Plane 921:

Fps test 2, 8800: 46,49,51

Fps test 2, 3870: 70,75,80

Fps test 3, 8800: 24,25,25

Fps test 3, 3870: 40,41,43

In other words, the 3870 is significantly faster.  I believe that this is due to the OS X drivers, not the cards themselves.  Note that the 3870 is in a PCIe 1.0 slot and the 8800 is in a PCIe 2.0 slot.

Hardware Guidance: Four Cores and DX10

I think we've reached the point where, if you are putting together a new computer and have X-Plane in mind:

• Get a quad-core machine if the pricing is favorable (and I think it should be now).
• Get a "Direct X 10" compatible graphics card.  That would be an nVidia 8, or 9 series (or I guess that crazy new 280 card) or a Radeon HD 2000/3000/4000.  DX10-type cards can be had for $100 to $150.

Quad core is easy: X-Plane 921 will use as many cores as yo have for texture loading (especially in paged scenery), uses two cores all the time, and uses 3 during DSF load.  The infrastructure for this additional scalability (previous builds used two cores, more or less) will let us put 3-d generation on 4 cores or more.  More on this in another post, but basically X-Plane's utilization of cores is good and getting better, so four cores is good, particularly if it's not a lot more expensive.

Now for DX10, first I have to say two things:

1. We don't use DirectX.  We have no intention of switching to DirectX, dropping OpenGL support, or dropping OS X/Linux support.  I just say "DX10" to indicate a level of hardware functionality (specified by Microsoft).  The DX10 cards have to have certain hardware tricks, and those tricks can be accessed both in OpenGL and Direct3D.  We will access them by OpenGL.
2. We are not going to drop support for non-DX10 cards!  (We're not that crazy.)

X-Plane does not yet utilize those new DX10 features, but the DX10-compatible cards are better cards than the past generations, and are now affordable*.  By making sure you get one of these, you'll be able to use new graphic features when they come out.

* The roll-out of DX10 cards has been similar to DX9.  With the first generation cards there was one expensive but fast card and one cheap but slow card.  With DX10, NVidia got there first, with DX9 ATI did.  Like a few years ago, now that we're a few revs into the new spec, both vendors are making high quality cards that aren't too expensive.

Spam My Wiki, Please

User Rs2Play is now the first user to be banned from the X-Plane Wiki.  WikiMedia has some automatic features, like banning all associated IP addresses with a banned user, so if you find yourself kicked from the Wiki in error, email me and I will fix it.  (This would only happen if you were in the same shared IP pool as the user in question.)  Thanks to the users who immediately removed the spam while I was out of the office.

(If we have more spam, I can promote a few users to admin status to ban spammers faster, but so far we have had only one case.)

Unfortunately the situation with the X-Plane SDK Wiki is not as good.  The problem is that the SDK Wiki does not use MediaWiki - it uses phpwiki, so we do not have the rich set of user admin tools that MediaWiki comes with out of the box.  There is currently a user who is (for some reason) attacking the user database by registering fake email addresses over and over.  I do not know what the user hopes to accomplish, other than wasting my time.

The unfortunate side effect is to leave the SDK Wiki user database in a state of chaos.  When I have time, I will be adding some new features to the user signup code and trying to clean out the user base.

Why are we not using MediaWiki for the SDK?  Well, besides history (we used what we found at the time), the SDK Wiki's code is customized to integrate the SDK development tools with the Wiki itself.  This is how you get the latest documentation and user generated content on one page when you look up an XPLM function.

There is no scenery system Wiki - something I have debated a bit.  At this point though I am more concerned with getting the scenery tools out than with updating the documentation; once we have a more complete tool set, then I can ask the question "can users figure out how to use these tools."

(More) Triangle Optimizations

Yesterday I described how triangles and meshes can be optimized and hypothesized that building OBJs carefully could improve vertex throughput.  Having looked at some numbers today, I think the potential for framerate improvement isn't that great...an improvement would come from cache utilization (post vertex shader), and our cache usage seems to be pretty good already.

Simulating a FIFO vertex cache with 16 vertices (an average number - very old hardware might have 8 or 12, and newer hardware has at least 24 slots) I found that we miss the cache preventably around 15% of the time (using a random set of OBJs from LOWI to test) - sometimes we really missed bad (20-25%) but a lot of the time the miss rate might be as low as 5%.  

What these numbers mean is that at the very best, index optimizations in OBJs to improve vertex throughput might only improve vertex processing by about 15% (with the FPS improvement being less, since vertex throughput isn't the only thing that slows us down).

In other words, if I solve the cache problem perfectly (which may be impossible) we get at best 15%.

So this could be a nice optimization (every 5% win counts, and they matter if you can improve fps by 5% over and over) but cache utilization isn't going to change the nature of what you can model with an OBJ, because our cache utilization is already pretty good.

Have a Happy Thanksgiving!

Triangle Optimizations

I've been looking a bit at triangle optimization - first some terminology:

• Indexed triangles means that the vertices in a mesh are referred to by index numbers.  This is the scheme OBJ8 uses.  The advantage of indexing is that if a single vertex is used by many triangles (that share a corner) you only have to include the vertex data once, and then use that data many times by index.  (The savings from indexing depend on how often vertices are shared.)
  
• Triangle strips are strips of triangles sharing common edges.  Because triangles in strips share so many common vertices, they can be stored in a compact form, for a savings of almost 3x.

Back in the old days, triangle strips were critical for performance (hence the presence of strips in the OBJ2 and OBJ7 formats).  However with modern hardware, indexing is more efficient - the slight increase in data size (due to the index) isn't as expensive as the cost of specifying "we're done with one strip, start the next one".  (Consider that if we use indexed triangles, we can submit all triangles in one batch - with strips, we need one batch per strip.)  Thus OBJ8 uses indexing and doesn't provide any strip primitives.

There is one other concept to be aware of: cache utilization.  Graphics cards remember the last few vertices they processed, so if a mesh repeats a vertex shortly after using it, the graphics card can save work.  Triangle strips naturally use a cache somewhat well because vertices occur in close succession.

Strips and DSF

DSF allows for triangle strips (and triangle fans) as a space-saving measure.  Even with indexing, the indices can be compressed if strips and fans are used, and with DSF, file size was a very high priority.

When the DSF file is loaded, the data is rebuilt into indexed triangles (and reindexed - the DSF internal structures don't provide as good indexing as the DSF loader can create) - in version 803 we first started using indexed triangles and found it to be a big win.

MeshTool will generate triangle fans (as a space saving measure) - if you build a DSF by hand (using DSF2Text), use strips/fans to compress file size.

Because DSF focuses on file size, the quality of mesh output is a function of the DSF loader, which has to run while flying.  So while I can imagine some improvements in future performance, I don't expect to be able to get huge wins because the very best mesh optimizing algorithms are much too slow for real-time use.

The DSF loader already produces full indexing and preserves cache utilization from strips and fans - the next logical optimization would be to reorder non-strip, non-fan triangles for better cache use on load; the order in the DSF file may be optimized for file size and not cache utilization.

Optimizing OBJs

Where I believe there could be real improvement is in OBJ8 generation.  The OBJ loader currently loads the indexed OBJ triangles exactly as specified in the file - build a smarter file and we can get faster framerate.  There are two possible ways to win:

• Cache utilization - by ordering vertices for cache use, we can get better throughput.
• Hidden surface removal - by putting the exterior triangle earlier in the OBJ, we can draw them first, occluding the interior of an object, which cuts down fill rate.  (In an airplane, you would want the exterior fuselage first in the OBJ, before the seats inside, so that only the pixels visible through the window are drawn.)

This second form of optimization may be of limited utility in that an OBJ8 optimizer has to respect authoring decisions about translucency, attributes, etc.

I am investigating OBJ optimization now - my hope would be to put optimization into a new version of the ac3d exporter and ObjConverter.

Strips and the iphone

There is one place that triangle strips do matter: the iphone.  It turns out that the iphone will process triangles a lot faster if they are presented in a strip-like order.  So the iphone DSFs are the first to use triangle strips (instead of fans), and the OBJ exporter for the iphone optimizes the OBJ mesh into triangle strip order.

My tests indicate that strip order makes no difference on modern ATI and nVidia GPUs, so there is no point in releasing these optimizations in the main X-Plane tools.  In the long term, I expect our OBJ tools will have two optimization paths - a strip-based path for the iphone and a cache utilization-based path for the desktop.

Why Animating Cars Doesn't Always Work Right

I saw a post about this on X-Plane.org...authors sometimes try to make a vehicle (a car, truck, etc) modeled via an OBJ "drive around" using animation translate commands.  The problem is that sometimes the objects disappear.  Here's what is going on:

X-Plane uses a bounding sphere to decide whether to draw an object.  The bounding sphere is the smallest sphere X-Plane can fit around the entire object; if the sphere is on screen, the object is drawn (even if the object itself isn't on screen).  We do this because we can test whether the sphere is on screen very quickly.

But what if the object has animation?  X-Plane attempts to guess how animation might affect the sphere by looking at animation commands and making the sphere a bit bigger where animation might move the object outside the sphere.  This process works, well, rather poorly. In particular, X-Plane doesn't know exactly how your datarefs will change.  This results in two error cases:

• If X-Plane assumes the animation is more drastic than it really is, we make the sphere too big.  The object will then be drawn even when it is not on screen (because the sphere is on screen because it is too big).  This case hurts fps but does not cause objects to disappear.
• If X-Plane assumes the animation is less drastic than it really is, we do not make the sphere big enough, and sometimes the object "disappears" because the object is on screen but the (too small) sphere is not.

Now let's apply this to objects that are driving around.  Usually this is done via a translate animation command where datarefs feed the object's position.

X-Plane estimates the effects of a translate animation using the largest and smallest key frame values.  But the animation engine will extrapolate beyond these key frames.  So consider these three cases:

• As your dataref goes from -1 to 1, you translate by +/- 1 meter.  In this case, the bounding sphere will be increased in radius by one meter.
• As your dataref goes from -25 to 25, you translate by +/- 25 meters.  In this case, the bounding sphere is increased in radius by twenty five meters.
• As your dataref goes from -1000 to 1000, you translate +/- 1 kilometer.  In this case, the bounding sphere is increased in radius by 1000 meters.

Note that in all three of these cases, the animation works exactly the same!  But by using different dataref and value extremes, X-Plane's estimate of the effects of the animation (and its change to the boundign sphere) can be quite different.

So...if you animate an object and it disappears, it is probably because the bounding sphere has not been increased, perhaps because a translation animation is being sent values outside its minimum and maximum values.

The problem is of course that to have an object "roam" over a large area, it must have a very large bounding sphere, which means it is being drawn a lot more than necessary.

Back From India

I am back from India -- I seem to have done a particularly lousy job of telling anyone I was going off the grid this time, so if you were wondering where I was, well, now you know. I am sorting through about 700 emails now, so it'll be a few days before I can respond to even just the "really time critical" stuff.

Fact or Fiction

More ranting on the question of whether a file format is based on factual information or not. For the sake of taxonomy, let's call this:

• Factual. The file format aims to capture "real world" information. The file spec is thus written against real world norms. Example: a runway is described by the location of its centerline at its threshholds, the type of aproach lighting fixtures, and the material it is built out of. This is all fact that can be verified by going to the runway and measuring it (while trying to avoid 747s).
• Artistic. The file format gives authors a creative platform to create "stuff", e.g. an image, a model; the file format dictates how client applications might interpret that "stuff". Example: OBJs are artistic - it describes what affect on drawing the various bits of the OBJ file have.

Apt.dat is actually a hybrid format - most of it is factual, with one glaring exception: pavement surface areas.

Pavement surface areas are simply an overlapping pile of bezier polygons with holes. There are multiple ways to create a given layout, and you couldn't make an argument that one is "more factually correct" than the other.

Artistic file formats give us a way to be open-ended, and so they are particularly useful for problems that we cannot solve in a practical manner using factual file formats. When we worked on the apt.dat 850 format, I clung to a 100% factual approach for as long as I could, hoping to be able to truly describe "ground truth" about airport pavement. What I found in the end was that real world instances of airport pavement are so varying and weird in real life that almost any factual approach would fail to correctly model important real-world airports. So we punted and simply said "put pavement wherever you want, make it look nice."

The result of going artistic instead of factual is two-fold:

1. The taxiway data in the apt.dat file is less broadly useful to a wide range of client applications; you might be able to infer some aspects of the real taxiways from the data, but the taxiway shape has very little structure to it.
2. You can model just about anything you can dream of - there really aren't any limits.

That taxiways are "artistic" will probably always bug me a little bit from a theoretical viewpoint, but I think there is no question that this was the only practical standpoint.

Final thought: factual file formats are usually not precomputed - that is, if we have a list of runways described by their real-world properties (and not modeled as a collection of textured triangles) then there is probably work that still needs to be done to make the file useful for X-Plane. (That work is done by X-Plane's file loading code.)

Okay - I'm OOTO for a while - see you before thanksgiving!

/ben

Americans: Go Vote!

Lines are a bit long here in Maryland, and we're not even a swing state. Doesn't matter! Go vote!

You Can't Copyright a Fact

Previously I have blogged about a key choice in file format and scenery system design: will the file format be "specification based" or "reality based".

Specification based: the format has an exact interpretation of the data. OBJ is an example of this...the format describes triangles and there is only one interpretation of what that triangle could be.

Reality based: the format models real-world concepts; the correct interpretation is "as close to the real world as possible." The nav.dat file is like that.

I have been reading the OpenStreetMap Wiki and hit upon something I didn't realize: you can't use copyright to protect a derived work from a file that simply contains a list of facts!

Now I am a programmer - I am used to writing code, slapping a copyright notice up top, and assuming that it's now mine...heck, I'm the one getting carpel tunnel from typing it out. But consider the nav.dat file; it contains a giant list of frequencies for navaids. It's a fact that the BOS VOR is 112.7. Is my mentioning of that fact in this blog a derived work of the nav.dat file? Of course not, and it's a good thing too because otherwise we wouldn't be able to state facts without IP conflicts.

The OSM guys believe that they need to change their license to something weirder than the CC-BY-SA license they have now because the CC license uses copyright, you can't copyright facts, and OpenStreetMap is really just a huge collection of facts.

Now at this point I've written six paragraphs too many without the obligatory "I am not a lawyer." I am not one. And I must admit, my biggest concern with all of this is that it gets confusing and hard to interpret, and I'd be perfectly happy if there were only 3 or 4 licenses out there for everyone, you'd pick your favorite flavor, and everyone would know what it means.

Suffice it to say, it never occurred to me that a criteria of a file format might be "protectability" - that is, does the file format allow an author to specify something other than facts, so that it is elligible for copyright protection?

If you are an author, the good news is: pretty much all of our file formats would meet that criteria:

• OBJ and DSF are essentially 3-d modeling containers (DSF is just a damned wierd one).
• Images are copyrightable, so that takes care of your textures.
• Plugins are code, clearly copyrightable.
• ACF files contain, among other things, 3-d models, see the first point.
  
• Apt.dat would be the format most at risk of "factualization", but I think you could argue that the arrangement of bezier curves and attributes is more of an artistic 3-d model than a statement of fact.

But who knows, I am not a lawyer.

(Oh yeah, this whole article is written from an entirely US-centric viewpoint...I am even less qualified to speak of such things outside the US than I am here at home.)

Out of the Office

Starting Wednesday I will be out of the office - Lori and I are going on a 2+ week trip to India!

So first, the obvious: your comments to the blog won't show up until I get back and can moderate them. Similarly, I will be even less on email than I am now. I am trying to dig out my tech support emails as much as possible before I go!

I will announce this before I go: I finally got an end-to-end render of a global scenery tile using CGAL 3.3.1. Andrew did the original work on this, modifying parts of the scenery generation code to handle his NZ scenery. I've been working on the rest of the algorithms and finished it today.

This doesn't mean very much immediately, but it...

• Will fix the instability bugs in MeshTool.
• Will address missing antennas and obstacles in the global scenery.
• Provides a solid basis for building scenery out of just about any kind of data.
• Provides a bunch of nice tools for writing better algorithms, which means nicer looking scenery.

The next steps will probably be to create a new release of the tool set, including perhaps a bug-fixed Mesh Tool, etc.

What Does the Airport Boundary Do

The apt.dat 850 file format defines a polygonal "airport boundary". But what exactly does it do? It does different things when creating DSFs and when rendering them.

Inside X-Plane it has relatively little effect:

• It is one of many elements that counts toward the land area that will be flattened. (Runways and taxiways are also used.)
• We do not actually render any special terrain or fences.

The airport boundary has more of an effect during scenery creation.

• If an airport has an airport boundary, we do not calculate the airport's boundary ourselves - instead f we use the specified boundary.
• All land intersecting the airport boundary is turned to airport terrain.
• The DEM is flattened within the airport boundary to reduce the slope of high frequency bumps.

There is one aspect of airport creation that the airport boundary is not involved in: filling in water to make land under runways. When we create an airport, we actually calculate three boundary polygons:

• The inner ring is closest to runways and taxiways (very close) with very little simplification. It is filled in with land if it is wet.
• A second ring slightly farther from runways and taxiways is also filled in with land if it is wet.
• The outermost ring is a lot farther out, but does not fill in Water. This is the ring that the airport boundary can replace.

Why do we need two inner rings? Well, if an airport is next to the water but not at sea level, we need to induce two sets of mesh points, the outer ones which drop down to sea level and the inner ones which are at airport level. You can see the importance of this at KLGA, where one of the runways dropped to sea level at its midpoint in version 8, but not version 9.

Since the airport boundary polygon provides only one ring, it cannot be used for this purpose. At some point in the future, we might use the airport boundary for rings 2 and 3, or use a smaller version of the airport polygon for rings 1 and 2.

For now, my recommendation is: the airport boundary should trace out the entire airport premesis, not including water.

Naming Names

I'm never quite sure about naming names. There are users whose contributions to X-Plane and its scenery system have been immense - we wouldn't have what we have without them.

But I don't want to make the decision to blog for anyone else - this blog is part of Laminar Research's communications to our users, and I don't want to set up content that leads our paying customers toward third parties who may not want the extra questions/attention.

So I guess for now what I'll say is this: the work I discuss here on this blog is not a solo effort - I have had the good fortune to collaborate with some really good people, and it has made X-Plane that much better of a flight simulator.

To everyone who has helped me with the scenery system: thank you!!

Whatever Happened to XES

If you read the original X-Plane scenery web pages, you'll see references to two file formats:

• DSFs - the files we distribute scenery in.
• XES - the "X-Plane Editable Scenery" file format, which you won't see very much of.

Here's the story:

When I was first working on the scenery system design, we decided on a pre-processed approach, which implied two types of file formats: pre-baked (editable source data) and post-baked (distributable finished scenery). XES is a GIS container format for the source data.

When we create the global scenery, the process is something like this:

1. Import lots of data from multiple sources in multiple formats, so that it is all in one giant tile in our format.
2. Process the data, deriving new information (like terrain type) from existing data (like slope) and fixing problems (like bumps on runways).
3. Export the data as a DSF, which involves additional conversions (such as converting generic road types to x-plane roads) and DSF encoding.

We keep our raw data partly in XES format, and partly in the original raw format, depending on how slow the importer is - some vector formats are very slow to import (or are not already tiled), so we preconvert to XES. Other formats, like SRTM, are so easy to import quickly that we just use the data as is.

If you have ever tried to use MeshTool, you may have used XES files yourself - the landuse and climate data that MeshTool needs are saved as XES files - it's an easy way to encode a few variable sized raster maps with portable enumeration encoding.

WED does not use XES files - when I started work on WED, I realized that the XES container format was too GIS oriented and not application-oriented, so I created a file format particular to WED. WED will continue to use .wed files, which can contain anything that WED can edit.

In the long term, I don't see XES as being used by anyone except for LR internally; WED will continue to have a WED native format, and we will try to use common simple GIS formats for import/export - most likely SRTM hgt files for elevation and .shp (shape) files for vectors.

Precomputed Scenery - the Good and the Bad

This thread on X-Plane.org sparked off quite the discussion. Now a lot of this is a discussion of when LR will have an overlay editor - there are a few overlay editing functions that Jonathan Harris' excellent OverlayEditor apparently does not yet support, sparking this discussion.

(I am not saying that LR should rely on Jonathan to do an overlay editor. But I am saying that the complaints I hear about a lack of overlay editing go down when Jonathan's overlay editor does everything that the file formats can do.)

But another part of the discussion focused on the problem of mesh editing. In particular, the basic terrain in a DSF is a fully baked output of a complex process that starts with higher level GIS input data. In other words, we start with a raster DEM, polygon coastline, apt.dat file, vector roads, and a bunch of config files and hit "bake" and a DSF comes out the other side, with a lot of processing.

This is very different than FS X, which integrates its data sources on the fly. Why did we choose a precomputed route for scenery? It has some pros and cons. (In understanding how we made these decisions, think back to what scenery was like with X-Plane 7 and ENVs and single-core machines.)

Performance

The main benefits of preprocessing scenery are performance related. When you process scenery data into the final scenery while flying, that computer power takes away from the rendering engine, thus cutting down fps. At some point you have a zero-sum game between how much cost there is to loading scenery and how complex the scenery integration can be; you have to pick very simple scenery integration algorithms to keep fps up.

(This is less of an issue as more cores become available, but is still a factor.)

When pre-processing, we can use algorithms that take minutes per DSF without affecting framerate.

Similarly, there might be scenery processing algorithms that improve fps by optimizing the output triangles - but do we have time to run these algorithms during load? With preprocessing we have all the time in the world because it happens once before the DVDs are burned.

Preprocessing also breaks a similar zero sum game between scenery data size and quality; the source data we use to make the scenery is a lot bigger than the 78 GB of DSFs we cut; if we had to ship the source data, we'd have to cut down the source data quality to hit our DVD limitations. With be-baking we could use 500 GB of source data without penalty.

Format Flexibility and Stability

The second set of benefits to preprocessing are flexibility benefits. (Consider the file format churn of the ENV days.)

- With a preprocessed scenery file, what the author creates is what the user sees - X-Plane does not go in and perform subjective integrations on the scenery later that might change how it looks in a negative way.

• There is no need to revise the scenery file formats to introduce new data sets, because new data sets and old are all processed to the same final DSF container format.
• A wide variety of mesh generation techniques can be employed because the mesh generation is not built into X-Plane. This is a flexibility that I don't think anyone has really utilized.
• Changes of behavior in the scenery generation toolset can never affect existing scenery because that scenery is already preprocessed; this help compatibility of old file formats.

Integration Issues

There are some real limitations to a pre-processed format, and they are virtually all in the bucket of "integration issues" - that is, combining separate third party add-ons to improve scenery. In particular, in any case where we preprocess two data sources, we lose the opportunity for third parties to provide new scenery to replace one of those data sources and not the other.

Airport is the achilles heal where this hurts us most; while airport layouts are overlays and can be added separately to the scenery system, the elevation of the base mesh below the airport needs to be preprocessed. This is something I am still investigating - a tolerable fix that other shave proposed is to allow an overlay scenery pack to flatten a specific region regardless of the user setting (so an author can be assured of a flat base to work from).

Preprocessing does fundamentally limit the types of third party add-ons that can be done; with version 9 and overlay roads, we are getting closer to letting road add-ons be overlays (see this post).

It appears to me that integration isn't the primary complaint about the scenery system (the primary complaint is lack of tools) but we'll have to see once we have mesh editing tools (mesh recreation tools really) whether preprocessing still limits certain kinds of scenery.

Note that a lack of tools or a lack of tool capability is not an inherent limitation of pre-processed scenery. We have an incomplete tool set because I have not written the code for a complete tool set, not because it cannot be done.

(The complexity of writing base mesh editing tools is a function of the complexity of a vector-based base mesh - this is also not related to pre-processing per se.)

Tools

In the end, I think the question of tools is not directly tied to the question of pre-processing. Whether we have scenery that is processed by X-Plane or a preprocessing tool, we have the same issues:

• Good tools require an investment in coding user interface.
• The code to convert source data which users might want to edit (like a polygon that defines a lake) to data the simulator might want to use (like a list of 78,231 triangles) has to be written.

I don't think either option (pre-processing or in-simulator processing) reduces the amount of work to be done to create a good toolset.

As a final thought, using scenery file formats that are "easier to edit" (e.g. a file format that contains a polygon for water rather than triangles) doesn't make the total code for scenery tools + simulator any easier; it just moves the task of "processing" the scenery from the tools to the simulator itself.

Threaded FM - Probably Not

I always have to hesitate before posting a possible future direction to my blog - our future plans are a road map, a direction we intend to follow, but if circumstances change, our plans change. (This is one of the great powers of software: the ability to be flexible!) Unfortunately in the past, I've posted ideas, and then when we didn't productize them, gotten back "but you promised X" from users. So now I'm a little bit gun-shy.

But let's try the reverse: what about a feature that I am now pretty sure won't go into the sim?

We were looking at running the flight model on a separate core from the rendering engine.  The idea is that the less work must be done in series with that main rendering thread, the higher the total frame-rate.  But now it looks like it's not worth it.  Here's my logic:

• The rendering engine now runs best on at least two cores, because all loading is done on a second core.  So unless you have a 4+ core machine, X-Plane is utilizing close to all of your hardware already.
• The flight model isn't very expensive - and the faster the machine, the less percent of time the flight model takes (because it does not become more expensive with higher rendering settings).
• Therefore I must conclude: threading the flight model would only help framerate on hardware that doesn't need the help - modern 4+ core machines.

So why not code it?  (Even if the improvement in framerate would be pretty low, it would be more than zero.)  Well, besides the opportunity cost of not coding something more useful, there's one thing that makes a threaded flight model very expensive: plugins.

Plugins can run during various parts of the rendering engine, and they can write data into the flight model.  I bounced a number of ways of coping with this off of Sandy, Andy, and others, and I don't see a good way to do it.  Basically every scheme includes some combination of a huge performance hit if a plugin writes data from render time, a lot of complexity, or both.

So the simplest thing to do is to not try to thread the FM against the rendering engine, and instead continue to use more cores to improve the rendering engine.

This doesn't apply to running more than one FM at the same time (e.g. AI planes and the main plane at the same time).  It's the question of the FM vs. the rendering engine that I think now is not worth the benefit.

Another Programmer

With the iPhone and X-Plane 9, we've been very busy...with this in mind, I am pleased to announce the latest engineer to join Laminar Research.

"Nubblet" would like you to know that the MacBook Pro is, in fact, "hers". :-)

New Installers

The 2.05 installer is now released - this is a multi-language update that fixes a few bugs and makes the map interface more usable. If you have existing DVDs, you may want to use the new 2.05 DVD installer because it scans the scenery folder very quickly when you pick "add-remove scenery".

(The old installer would check the signatures of all scenery files - this one simply checks whether they exist.)

No URLs have changed - installers will always have the same file names and live at the same URLs; you can pick "Get Info" or "Properties" to tell their version (or run with --version on Linux).

I have a ton of emails I need to get through, so if you emailed me, I do apologize; I will try to clean out the pending tech support issues, etc. in the next week.

Releases, Bugs, and the iphone

Sometimes I have one of those weeks where all I do is look at crashes and weird behavior.  This is turning into one of those weeks.  So here's some status on the various bugs floating around.

I should say: you'll find a lot of developers blaming the technology providers for bugs (just look at how many OpenGL developers have blamed ATI for their apps crashing).  Sometimes it's the app, sometimes it's the driver.  More importantly:

• You don't know who's fault it is until you fully understand the bug.
• The fix for a bug might not be in the broken code.  That is, one piece of code can work around a bug in another.

So...you can't necessarily tell whose fault it was from new drivers coming out, us changing the sim, etc.  But...when it's my stupid code, I'll admit it openly - no one should think that a bunch of other smart programmers are screwing up on my behalf.  (This is also useful to other apps developers, who can know that my bug isn't the same as their bug, since my bug was in my code.)

X-Plane: we're happy with 921r2 finally...the final bug (crash on startup on the Mac) was due to an incompatibility between Apple's OpenAL implementation and special memory allocator (which is really just a wrapper around NEDMalloc).  I still don't know exactly what the rules should be (you try reading the C++ spec!) but for now we turned the allocator off on Mac.

(This brings up another issue about bugs - you can't tell whose bug it is by whose code crashes, since one piece of code can sabotage another.)

So the next X-Plane release will probably be 930, with new features.  We may have a few more language patches if needed.

iPhone: the 9.01 iPhone patch is out, and it improves framerate a bit.  We are still seeing crashes on startup for users who have just downloaded the app.  Rebooting the phone will fix this, but please see this post for more info!  We need your help to collect more data.

Radeon 9800 on Windows: for the longest time we've had users reporting "framebuffer incomplete" errors when using catalyst 8.x drivers, an R300 chipset, and Windows with X-Plane 9.x.  I have been trying to reproduce this problem "in the lab" off and on for months, but finally saw it this week.  From what I can tell, we're getting into some low-memory condition and the driver is freaking out in various ways.  The command line options people sometimes use to get past this are probably rearranging memory, not saving it.  I don't know why the Catalyst 7.x drivers don't have this problem.  But...at least I am making more progress than I was before.  Please see this post for more info.

Installers: I am working on the 2.05 installer.  I have seen a number of users report problems running a full install from DVDs, so I am just starting to investigate that.  I will post more when I have something to test.  Unfortunately the problems reported are not something we see here.

The Future of Triangles Part 5: The Technology of the Future

I've rewritten this post about four times now...let me try the brief version.

Basically, X-Plane is not an early adopter of graphics technology. Because of the nature of the rendering we do, we can directly benefit from "more of the same", e.g. if you simply gave me twice as many objects per second or twice as many polygons, we could make the sim look a lot nicer. So we don't need to adopt new graphics technologies until they're proven in games that need them more, like first person shooters. We're a small company with no influence on the industry, so we write the tightest message we can and use new features when the dust settles.

(From a utilization standpoint, we also provide the best graphics to the most people by using card features that are going to become wide spread, so it doesn't make sense for us to gamble on vendor-specific extensions that might not become available to everyone.)

With that in mind, there is some cool stuff that people are talking about that maybe someday we'll get to play with:

• Irregular Shadow Mapping - given a super-programmable card, you can create a rendering scheme that optimizes shadow map creation to remove artifacts.
• Out-of-order blending - the graphics card resorts incoming geometry so that all translucent geometry is drawn back to front. Doing this on the CPU is expensive (and in X-Plane's case, we often just don't get it right at all).
• Multiple dispatch to multiple targets. Even on a big multi-chip GPU (a lot of modern cards are two cards stuck together) the only render to one screen or texture at a time, even if there are a lot of parallel elements. This is good for a few big complex scenes but not good for lots of small scenes. I'd like to see all vendors support dispatch to multiple targets - this will make things like dynamic reflection via environment cube maps potentially a lot faster.
• Voxel Octrees. This is the one I hear a lot about - basically it's a change from 2-d to 3-d data structures on the graphics card to manage fast access to large chunks of graphics data. (Shadow maps, z-buffers, and environment maps are all more or less 2-d data structures.)
  

Will we see this? I don't know. Will Larabbee change everything? Who knows...Intel has to build a high-end graphics card to fight ATI and NV's attempt to get into supercomputing, but if they happen to also build a really nice video card, I can live with that. But I won't hold my breath - the titans need to duke it out without me!

The Future of Triangles Part 4: Pie in the Sky

Per-pixel lighting is something I hope to have in X-Plane soon.  A number of other features will take longer, and quite possibly might never happen.  This is the "pie in the sky" list - with this list, we're looking at higher hardware requirements, a lot of development time, and potential fundamental problems in the rendering algorithm!

High Dynamic Range (HDR) Lighting

HDR is a process whereby a program renders its scene with super bright and super dark regions, using a more detailed frame-buffer to draw.  When it comes time to show the image, some kind of "mapping" algorithm then represents that image using the limited contrast available on a computer monitor.  Typical approaches include:

• Scaling the brightness of the scene to mimic what our eyes do in dark or bright scenes.
• Creating "bloom", or blown out white regions, around very bright areas.

Besides creating more plausible lighting, the mathematics behind an HDR render would also potentially improve the look of lit textures when they are far away.  (Right now, a lit and dark pixel are blended to make semi-lit pixels when far away as the texture scales down.  If a lit pixel can be "super-bright" it will still look bright even after such blending.)

Besides development time, HDR requires serious hardware; the process of drawing to a framebuffer with the range to draw chews up a lot of GPU power, so HDR would be appropriate for a card like the GeForce 8800.

While there aren't any technical hurdles to stop us from implementing HDR, I must point out that, given a number of the "art" features of X-Plane like the sun glare, HDR might not be as noticeable as you'd think.  For example, our sun "glares" when you look at it (similar to an HDR trick), but this is done simply by us detecting the view angle and drawing the glare in.

Reflection Mapped Airplanes

Reflection maps are textures of the environment that are mapped onto the airplane to create the appearance of a shiny reflective surface.  We already have one reflection map: the sky and possibly scenery are mapped onto the water to create water reflections.

Reflection maps are very much possible, but they are also very expensive; we have to go through a drawing pass to prepare each one.  And reflection maps for 3-d objects like airplanes usually have to be done via cube maps, which means six environment maps!

There's a lot of room for cheating when it comes to environment maps.  For example: rendering environment maps with pre-made images or with simplified worlds.

Shadows

Shadows are the biggest missing feature in the sim's rendering path, and they are also by far the hardest to code.  I always hesitate to announce any in-progress code because there is a risk it won't work.  But in this case I can do so safely:

I have already coded global shadow maps, and we are not going to enable it in X-Plane.  The technique just doesn't work.  The code has been ripped out and I am going to have to try again with a different approach.

The problem with shadows is the combination of two unfortunate facts:

• The X-Plane world is very, very big and
• The human eye is very, very picky when it comes to shadows.

For reflections, we can cheat a lot -- if we don't get something quite right, the water waves hide a lot of sins.  (To work on the water, I have to turn the waves completely off to see what I' m doing!)  By comparison, anything less than perfect shadows really sticks out.

Shadow maps fail for X-Plane because it's a technology with limited resolution in a very large world.  At best I could apply shadows to the nearest 500 - 1000 meters, which is nice for an airport, but still pretty useless for most situations.

(Lest someone send the paper to me, I already tried "TSM" - X-Plane is off by about a factor of 10 in shadow map res; TSM gives us about 50% better texture use, which isn't even close.)

A user mentioned stencil shadow volumes, which would be an alternative to shadow maps.  I don't think they're viable for X-Plane; stencil shadow volumes require regenerating the shadow volumes any time the relative orientation of the shadow caster and the light source change; for a plane in flight this is every single plane.  Given the complexity of planes that are being created, I believe that they would perform even worse than shadow maps; where shadow maps run out of resolution, stencil shadow volumes would bury the CPU and PCIe bus with per-frame geometry.  Stencil shadow volumes also have the problem of not shadowing correctly for alpha-based transparent geometry.

(Theoretically geometry shaders could be used to generate stencil shadow volumes; in practice, geometry shaders have their own performance/throughput limitations - see below for more.)

Shadows matter a lot, and I am sure I will burn a lot more of my developer time working on them.  But I can also say that they're about the hardest rendering problem I'm looking at.

Dynamic Tessellation

Finally, I've spent some time looking at graphics-card based tessellation.  This is a process whereby the graphics card splits triangles into more triangles to make curved surfaces look more round.  The advantage of this would be lower triangle counts - the graphics card can split only the triangles that are close to the foreground for super-round surfaces.

The problem with dynamic tessellation is that the performance of the hardware is not yet that good.  I tried implementing tessellation using geometry shaders, and the performance is poor enough that you'd be better off simply using more triangles (which is what everyone does now).

I still have hopes for this; ATI's Radeon HD cards have a hardware tessellator and from what I've heard its performance is very good.  If this kind of functionality ends up in the DirectX 11 specification, we'll see comparable hardware on nVidia's side and an OpenGL extension.

(I will comment more on this later, but: X-Plane does not use DirectX - we use OpenGL.  We have no plans to switch from OpenGL to DirectX, or to drop support for Linux or the Mac.  Do not panic!  I mention DirectX 11 only because ATI and nVidia pay attention to the DirectX specification and thus functionality in DirectX tends to be functionality that is available on all modern cards.  We will use new features when they are available via OpenGL drivers, which usually happens within a few months of the cards being released, if not sooner.)

The Future of Triangles Part 3: X-Plane 9

Before I post anything to my blog saying what might happen, standard disclaimers:

• This blog represents my rambling about the directions I am considering for X-Plane's rendering engine.
• This blog is not a promise or commitment of any kind to deliver any particular feature.
• If I say I am looking at doing feature X, and feature X does not materialize, either in the near or far future, or, like, ever, consider this to be one big fat "I told you so."

With that in mind, I think the direction for lighting in version 9 is to introduce per-pixel lighting.

I don't know what other set of features we'll get with per-pixel lighting, but I am reviewing normal maps, specular maps, and the material attributes.  Per pixel lighting will mean smooth, round, shiny looking surfaces without using a huge number of triangles.

Now there are two sets of hardware that will not be able to support per-pixel lighting:

• Cards without pixel shaders.  (GeForce 2,3,4, Radeon 7000-9200.)  You might know your card does not have pixel shaders because the pixel shader check box is not available in the rendering settings.
• Cards with first generation shaders.  (This is the GeForce FX series and the Radeon 9500-9800 and X300-X600.)  These cards can actually perform per-pixel lighting, but they are so slow that per-pixel lighting will bring them below minimum frame-rate.

So unfortunately, there will be an authoring decision: add more triangles so that per-vertex lighting looks good, or use fewer triangles and rely on per-pixel lighting.  The decision will depend on what hardware you want to target at what performance level.  (For what it's worth, hardware that cannot support per-pixel lighting usually isn't very powerful, so there is something to be said for not having a lot of triangles on these lower end machines.)