I Hate the Term Photo-Realistic

Now before you come at me with pitch-forks, I don't hate photo-realistic scenery, and X-Plane's performance with orthophoto-based scenery is very, very good. But...the term "Photo-Realistic"...it makes me crazy. Here's why:

First, photo-realistic scenery links the use of photographs in scenery to realism in its very name, and I don't buy it.

Yes, some photo-based scenery packages are realistic looking, by today's standard of flight simulation. Some are not. Just look at any old photo-realistic package to see what I mean...realistic is a relative term, defined by how much fidelity we expect, and that expectation has steadily gone up. Even with a modern package, a photo-based scenery pack might not be realistic if the photos are not used well.

(For example, is a package that uses orthophotos on the mesh but provides no 3-d in a city still considered realistic now? What kind of review would such a package get?)

Nor do photos have a monopoly on realism. They can look nice when well used, but I would put Sergio's custom panel work up against any photo-based panel. (Sergio does not manipulate photos for his panel, he constructs them from scratching. He has thousands of photos for reference, but the pixels you see are not originally from any photo.)

Second, the term photo-realistic (in the scenery world) is most commonly applied to scenery that applies orthophotos to the terrain mesh in a non-repeating way. But orthophoto base meshes don't have a monopoly on the use of photographs, which can be used to form land-class textures or to texture objects.

Okay, so "hate" is a strong word. But I feel some frustration whenever I see scenery discussed in terms of "photorealism".

Pie in the Sky: Future Rendering Tricks

I've had a few inquiries about environment maps, normal/specular maps in more places than just OBJs, etc. The short answer is: a lot of these future rendering engine enhancements are good ideas that we like, but we have other features that are already partially implemented that we need to productize first.

In particular, one of those half-finished features not only could use to be shipped, but also affects the way just about every other rendering effect works. So better to get these features finished first, and build new effects within the context of these "new rules".

Here are some of the ideas that I've heard kicked around:

• Environment maps on the plane - I like it, it's not that hard to do, and the framerate hit could be ramped up and down with detail. See above about finishing other features first.
• Next-gen texturing on runways (wet runways, environment maps, bump mapping) - I like all of it. The runways really need to be addressed comprehensively, not piece-wise, in order to find a rendering configuration that meets our scalability and efficiency needs. (In other words, we can't just burn tons of VRAM on the runways, and we need a way to render them that works on low and high end computers with one set of art assets.)
• Normal mapping on the ground. I like it, but I wonder if this isn't part of a bigger idea: procedural texturing on the ground. E.g. if we want to add detail on the ground, can we add it with multiple layers at different resolutions with a shader adding yet more detail.

Generally speaking, it's not that hard to push a feature out from one part of the rendering engine to the other. For example, normal maps on facades (if anyone cares :-) would make sense and be a fairly trivial change. I hesitate on polygons only because the ground might require something a little bit more sophisticated.

Going Crazy With Choices

Here's a straw man of why polygons might be different: draped polygons can't have specular shininess right now, and I don't think anyone is complaining. So it's a bit of a waste to use the alpha channel of a normal map for shininess. Perhaps it could be used for something else like an environment mapping parameter.

Hrm...but we would like to have environment mapping on airplane objects too someday. Well, we could go two ways with that. We could just use the alpha channel for shininess and environment mapping...not totally unreasonable but it wouldn't let us have a glossy non-reflective material, e.g. aluminum vs. shiny white paint.

Math nerds will realize that the blue channel in normal maps can be "reconstituted" from the red and green channels by the GPU (at the cost of a tiny bit of GPU power). That would give us two channels to have fun with - blue and alpha. Perhaps one could be shininess and one could be an environment mapping material.

Well, shininess is still no good on the ground. But...perhaps that would be a good place to store dynamic snow accumulation? Hrm...

My point of this stream-of-consciousness rant is that the design of any one rendering engine feature is heavily influenced by its neighbors. We'll get all of these effects someday. If there are features that are really easy, we can get them into the sim quickly, but the only obvious one I see now is using bump maps on other OBJ-like entities (which at this point would mean facades).

Removing Third Parties is a Diagnostic Test, Not a Cure!

In response to so many bug reports I say:

Please temporarily remove your third party scenery, airplanes and plugins and retry. Do you still see this bug?

And in response I get:

No - the bug was with XXX. Thanks!

But...but...but...we're not done yet! The point of removing the third party add-on is divide-and-conquer: to see if the bug is in the core of X-Plane or is caused by an X-Plane-add-on interaction.

If the add-on used to work but no longer does, I want to know where I can get the add-on, who created it, and when it used to work, so I can investigate further! If an add-on stops working because X-Plane was updated and the add-on is not doing anything naughty, that is still an X-Plane bug.

So please: don't give up on the bug just because removing the add-on makes it go away...there is still more to debug!

Marking the Ground? Use a .pol or .lin.

The rule is very simple: if you want to put a marking on the ground, your results will be much better if you use a .pol (draped polygon) or .lin (draped line) than if you use an OBJ. In fact, an OBJ is probably the worst way to put markings on the ground.

Requirements for Good Looking Markings

In order for markings to look good you need to have three things happen:

1. You need to make sure your markings are at the exact same level as the ground itself.
2. You need to use polygon offset to tell X-Plane to tell the video card that these are "coplanar" (at the same height) triangles that must be managed in a special way.
3. You must guarantee that the draw order is: the stuff under your markings, your markings, then the 3-d buildings and other 3-d stuff.

With these requirements we can compare .pol/.lin files to OBJs:

1. .pol and .lin files always "drape" to the ground, so they always meet rule 1 perfectly. With an OBJ you can set the height of your OBJ to 0 but on sloped terrain this won't be correct.
2. .lin and .pol files are always "polygon offset" automatically, so they always meet rule 2 perfectly. With an OBJ you need to use ATTR_poly_os.
3. ATTR_layer_group (or LAYER_GROUP) tell the OBJ or pol/lin in what order to draw, so you can set this correctly in all cases. The default values if you don't specify a layer group are more appropriate to the task of markings on the ground when you use a pol/lin - that is, by default they meet rule 3 perfectly. By comparison, an OBJ may not be in the right draw order.

So we can see from these 3 rules that you will always get the rules right just by using a pol or lin, but you have to be very careful and may still not get the rules right when using an OBJ.

Performance? Think .pol

When you have a large number of small markings, the performance of a .pol is going to be significantly superior to the performance of an OBJ. For example, imagine an airport where you want to draw on-pavement signs for all taxiways and runways. With an OBJ, to get the height right, you'd need to use a large number of small objects. (With one large object, it will be nearly impossible to make the OBJ markings be on the ground when far from the object center.)

When you use a large number of .pol markings that share one common texture and all have the same .pol file, X-Plane merges them behind the scene into one huge object-like pile of triangles. The cost of drawing all of those polygons will be similar to the cost of drawing just one object! That's a huge speed win.

Floating Objects Are Wrong

What I see most commonly in scenery packs that are sent to me and have thrashing problems are OBJs that have a height other than 0. This is simply the wrong way to create overlaid geometry in X-Plane, and it will produce artifacts in a wide variety of situations. At best, the "floating" objects will cause airplanes driving over the marking to look like they "sink in". At worst, the offset you pick will be too small for the video card's resolution and you'll get thrash anyway.

There is no one right vertical offset for all scenarios, and even if there was, it would still look ugly! See the above rules for what an OBJ really has to do.

How Do I Get a .pol into my scenery.

Well that is the $10,000 question. I must admit that I don't know what Overlay Editor's capabilities are in this regard. WED 1.1 will be able to add draped polygons, including texture coordinate editing of the polygons. I've been working on the texture coordinate editor in WED this weekend and am hoping to get some kind of WED 1.1 preview built this week.

With WED 1.1 the process is fairly simple:

• Create your texture.
• Create a single .pol text file that names the texture, so you can use it.
  
• In WED 1.1 you can select the .pol from the list of resources for your scenery pack, and then use the "polygon create tool" to simply draw the draped polygons into place.
• Once the draped polygons are created, you can select the polygon and open the "texture coordinate editor" tab to edit the way the texture is applied to the polygon.

My hope is that this process will be easier than creating markings using a 3-d editor - you can still edit the texture coordinates, but you can do so directly in WED.

Higher-Order Beziers? Probably Not

I was revisiting Bézier curves today. First I should say that the current scheme for handling Bézier curves in apt.dat and DSF is horribly convoluted - I am looking to replace the syntax with something less weird for the next set of features that use them. But I was also looking at the problem of generating curves from high-density line data.

Did you know that a Bézier curve can have any number of control points? This picture illustrates:

Each curve has one more control point than the last. Zero control points is of course a line segment, and two control points is a "cubic" Bézier, which is what we have now. (Note that having one control point in WED does not give you the one-point quadric Bézier you see here. WED gives you a cubic Bézier with one control point on top of an end point.)

But it also show: having tons of control points are not particularly useful for modeling a shape in detail - a string of connected cubic Bézier is probably just as good. And the high-order Bézier doesn't really trace out the control points, so it's not a good way to convert line segments into a curve.

Parameterized Lights, Generic Lights and Plugin Controlled Lights

There are a few changes to 940 regarding airplane lights...I will try to get some permanent documentation on the Wiki, but here's the basic ideas:

There is a new "type" of light in the OBJ8 format, called a parameterized light. A parameterized light is somewhere between a named light (totally as-is, can't be modified, simple to use) and a custom light (totally complex, can do anything, requires a lot of work). In a parameterized light, you control just one or two aspects of the light.

Parameterized lights are aimed at airplanes, not scenery, because typically parameterized lights are customizable and slow.* The goal is to give airplane authors some flexibility without having to invent a huge number of named lights.

Consider, for example, landing lights. A landing light could vary based on what switch controls it (we have 16 now), how big it is (many authors have pointed out that one size does not fit all) or how wide it's view angle should be. (Lights that are inset in a structure might not be easily viewable from the side.) With a parameterized light, we can provide one light definition with 3 parameters instead of a huge matrix of lights.

Generic lights are a new collection of 64 lights that can be used for any purpose, sort of like misc wings, misc bodies, and sliders. The main difference between a landing light and a generic light is that the landing light halo won't show up on the runway when a misc light is turned on. They are meant to be used for logo lights, inlet lights, etc. A series of new named lights will "listen" to the generic switches.

(Tip: combine ATTR_light_level with generic lights to have a light turn on and your lit texture appear at the same time.)

Finally, there is now a plugin override for the beacons and strobes (and in the systems model there can be up to 4 separate sets of beacons and strobes flashing at different times). With parameterized lights you can make two sets of strobes and use a plugin to control when they flash.

The combination of these three things let an author create an airliner that models all of the various lights and their behaviors.

* Slow needs some qualifications here. There are two code paths for lights, the fast and slow path. The slow path IS pretty fast, just not as fast as the fast path. The fast path is expected to be able to draw at least 10,000 lights in a single frame on low-end hardware, while the slow path is expected to be able to draw at least 500 lights per frame on low-end hardware.

500 lights is a lot for one airplane, especially if you have to place them by hand. And most modern computers will easily do thousands of slow lights.

Basically slow lights are not appropriate for scenery objects in the library that might be placed a huge number of times: OBJs attached to roads (e.g. street lights), OBJs used for buildings, taxiway lights. The are plenty fast for airplanes. In the X-Plane world, slow doesn't really means slow, just slower than something else.

Yank That Stick Back

A quote from the .org:

I actually did try the demo before I bought it, and I found it sorta arcadish as I took off with a King Air 200 and performed barrel rolls on t/o lol! That kind of tuned me out!

I don't mean to pick on that particular poster - we hear that a lot, particularly from people who use MSFS. Andy Goldstein points to Bob Hoover as a counterpoint.

More generally, the criticism is that since X-Plane will allow you to do things in commercial airliners that you've never seen in real life, X-Plane must not be realistic. And phrased like that, you can see the possible flaws in the reasoning:

1. How do you know your control inputs match real life?
2. How do you know the real plane is physically incapable of doing such a thing?

The first is the age-old problem of consumer joysticks - to really maneuver an airliner hard you have to put a lot of pressure on the controls - they put up a lot more resistance than a $20 SideWinder.

The second is an issue of falsifiability again - the absence of evidence is not evidence of absence.

Now in truth there are things that X-Plane models and X-Plane does not model. If you load up the airframe too much with fail-on-over-G on and the G limits are set correctly, X-Plane will start removing parts as you try to fly a 747 like an F-16. But we don't necessarily simulate some of the internal things that might go wrong. For example, accelerations on the fuel system might potentially cause flow to the engines to fail, stalling an engine. I don't know how much of this Austin simulates, but we certainly don't simulate the geometry of the fuel lines and the fuel as a fluid flow. So there may be cases where a maneuver is impossible for logistic but not aerodynamic reasons (e.g. you could do it but you'd lose your engines).

With that in mind, here are a few youtube links:

• Bob Hoover flies a Commander like an aerobatic glider - thanks Andy!
• Roll an airliner? It's safe, really!
• The 757 has a lot of power - thanks Andrew.
• I have no idea what happened here...I thought the Airbus computer prevents you from doing this kind of thing.

On that last video: the first time I flew with Austin in his Cirrus (this is before he traded it for a Columbia) he pulled the same maneuver: take-off, very slow rate of climb to pick up speed, and then: yank. Our climb rate was well over 2000 fpm in a single-engine prop for a while.

(Logistic note: please don't interpret this post as an invitation to contact me regarding any aspect of the flight model - when it comes to the physics engine I am just another user, with no special insight. Physics is Austin's domain, definitely not mine!)

Proximate And Ultimate Crashes

One last comment about driver crashes: I try to be fair about the distinction between causation and correlation when it comes to driver bugs; the piece of software that "fixes" a bug may not be the piece of software that contains a bug, and work-arounds happen in both directions between drivers and apps.

Similarly, seeing "ATI" or "NVOGL" in your crash report does not imply a driver bug. It does imply that the crash happened in the driver, but the driver crash may be a proximate cause, while the ultimate cause may be in X-Plane. (Sometimes the stack crawl is also just plain wrong, depending on the severity of the crash.)

OpenGL drivers need to be very, very fast; the whole point of buying that shiny new GPU was to get faster framerates. So driver writers have to make trade-offs about how much error checking they do when an application passes in junk data. If I were writing a driver and debating an error check that would slow performance and prevent a crash of an application that passed illegal data (but not the machine), I might very well skip the error check and say "if the application doesn't want to crash, it should pass better data."

Of course, it's not up to me, and it's not always up to the driver writers; the OpenGL specification actually dictates what outcome are acceptable in various error conditions. Quite often, "program termination" (read: the application crashes but the machine does not) is an allowed response to certain kinds of bad data from the application to the driver, particularly where checking the data would slow performance for all applications and the application should know better.

Pay No Attention To That Last Post

My last blog post may have expressed some negative views toward software upgrades:

I know I'll take some slack for this, but: why did you all go and grab an OS update so fast? What have you gained? The down-side is lost time and application compatibility problems...was it worth it?

That blog post was of course not my real opinion, but rather a recreation of the evil Ben. Always upgrade your software to the newest version whenever it comes out!

Caught With My Pants Down

My friends say I have become a technological curmudgeon...whenever a new gadget or device or operating system comes out, I just grumble about how that it just means more bugs and mutter about how a byte only had 7 bits when I was young.

How did this happen? Pretty simple. New driver comes out, new bugs and interactions with X-Plane, rinse, wash, repeat. This is not a criticism of the driver writers. Those guys have an impossible job: write code that is super high performance in an environment that is highly unforgiving (an X-Plane crashes X-Plane; a video driver bug crashes your entire machine), then do it again when the next hardware comes out 9 months later. As the apps guy integrating on top of this ever-running treadmill of new hardware and drivers (think I Love Lucy) I sometimes dream of a week when none of the software that X-Plane runs on top of changes.

This is not one of those weeks. Snow Leopard came out, and it looks like Apple has been quite successful in keeping the price low; I'm seeing plenty of bug reports against 10.6 and it's only been a few days. Apple ships video drivers with the OS, so Snow Leopard isn't just a new OS, it's new drivers too, as well as possible changes to the OpenGL "middle" layer that Apple provides.

Now about my pants...over the last few years I have been accumulating graphics card + operating system combinations, so I can see a higher percentage of hardware-related bugs "in the lab".* But my wife and I are in the process of relocating to Boston, and this has temporarily separated me from a significant subset of my hardware. The result: driver bugs are coming in and I can't easily reproduce them.

To paraphrase Airplane, I picked the wrong week to quit sniffing OS betas.

(I know I'll take some slack for this, but: why did you all go and grab an OS update so fast? What have you gained? The down-side is lost time and application compatibility problems...was it worth it?)

*Just because it's hardware related doesn't mean it's a driver bug - X-Plane can be the broken app too! Sometimes drivers work around X-Plane bugs and sometimes X-Plane works around driver bugs. I mention this because plenty of apps developers complain on forums about "driver bugs" - but how many of them repost when they discover a null ptr in their code? A driver and an app are two pieces of software that have to be integrated, and bugs crop up on both sides.

Scalability and apt.dat

Beta users, see the bottom of this post for how scalability turns into possible bugs.

In computer science, a program or architecture is scalable if it doesn't totally vomit up a lung as its constituent parts become bigger. For a cleaner definition, see Wikipedia, source of all internet knowledge.

An ant is not scalable - if you made an ant 100 times larger in every dimension, its tiny legs would break under its new weight. (An ant is not scalable because its weight grows faster than its structural strength. Thus elephants are not built like ants.) Geeks: scalability is to computer science as marginal cost is to economics.

Before X-Plane 940, the apt.dat file was distinctly not scalable. The entire file was loaded into memory; as users created more and more taxiway lines and signs and details, we simply used more and more memory. This approach isn't very scalable because authors have the potential to grow the apt.dat file faster than our system requirements can increase.

X-Plane 940 fixes this by not loading the entire apt.dat file into memory. Instead, only essential airport information is loaded into memory, along with a note as to where in the file the airport lives. Whenever an airport actually has to be built into a 3-d mesh while you fly, we go back to the apt. file and load the rest of the data for the one airport we are building, use it, and throw it out. Since 3-d airport meshes are built on a second core, the cost of loading one airport off disk is pretty harmless.

The problem with this fix is that it introduced a new scalability problem. Consider:

• Meshes in 940 are built on as many CPU cores as you have - some users have 8!
• Each CPU core could be working on a different airport, depending on how many are nearby.
• Each airport has to load up the apt.dat file to get the extra airport data.

This means that at times on an 8 core machine we could easily have allocated 50 * 8 = 400 MB of memory just to temporarily hold 8 copies of the apt.dat file.*

This is of course completely silly - there's no reason to load the whole apt.dat file to get one airport, and the fix that is going into beta 8 lets the airport loader surgically grab just one airport. Thus we will be scalable again, because adding more cores won't cause memory usage to go up.

Beta Users: Please keep an eye out for X-Plane running out of memory - if it starts to do so in the next beta it means that some part of this code change munged memory management. We're running stress tests on the sim now, but touching the low level memory nd file handling code late in beta isn't something I like to do.

* While loading 8 copies of the apt.dat file is wasteful of memory, it is not slow; X-Plane uses memory mapped file I/O, so reading a small part of a large file is very fast - just not very virtual-memory efficient.

Marketing And Fact

A while ago, Austin was on FSBreak, and I wrote this post as commentary on his interview. The main point I meant to make was this: from what I have heard from other engineers and seen in my own experience, most software companies prefer to develop new features on top of implementations that are known to have architectural problems. At LR, we fix the implementation architectural problem first, and that has been a net win for us.

Now that's basically a statement of my opinion on software engineering - in hindsight it probably belongs on my programming blog and not here. Unless you develop X-Plane plugins, you're not a programmer; I will try to constrain future scenery blog posts to things that non-programming X-Plane users will notice. If you are a plugin developer, you might want to look at the "Hacks of Life" posts tagged with OpenGL.

Anyway, back to the story...the responses to that blog post were all well thought out comments on X-Plane's quality control process. At the time my immediate reaction was: that's totally off topic - I'm commenting on architecture and they're talking about QA. I do think the authors made fair points.

But in hindsight, I think that there's a deeper issue: one of verifiability. Simply put, my statement that we (LR) rewrite stale implementations is nearly impossible to verify without source code access, something that you can't get for X-Plane. So from the perspective of anyone outside the company, my original statement is not falsifiable (it cannot be proven false) and thus rather useless as a statement of fact. Even though I claim that we make rapid progress on features by keeping implementations clean, you as a user don't care how we develop our features - clean architecture, more developers, or the use of time travel and voodoo dolls, it's a bit moot.

Thus the comments were off topic, but also they were moving away from an unverifiable topic and toward one that users can measure, namely the quality of X-Plane's betas.

There's a fair amount of marketing that gets put out in the tech and games industry. It's a slippery slope from giving a new, real technology a whiz-bang name (e.g. HyperZ is a real technology, and it is good for your frame-rates) to using techno-babble to make the bad seem good (e.g. HyperMemory just means that your video card lacks VRAM and is going to be slow). When new products come out, the feature list is parroted, but it's not always clear whether the new features turn into real benefits.

So what I'm going to try to do with the scenery blog is: try to keep the blog limited to verifiable, measurable aspects of X-Plane. If we ship X-Plane with "psychoactive rendering*", I'll try to explain what the heck that is and why you'd want it, and how you might notice that it's working.

* X-Plane does not have psycho-active rendering, except possibly when I make a mistake in the shaders and everything turns purple.

Test Your Add-Ons Now!

X-Plane 940 beta 7 is out. Now is the time to test your airplanes, scenery, and plugins. We've reached a point where we think we have the new systems code working. Please try the new beta, test your add-ons, and if something works in 930 but is broken in 940, file a bug immediately!

Two Warnings About Normal Maps

Two warnings about normal maps:

1. Make sure that the RGB color underneath transparent sections does not turn black or white! Some image editing programs (in particular Photoshop) will lose the color beneath a transparent area.

   With a normal map, this is very bad - black and white are not legitimate normal map colors, and the result will be bogus normal vectors under the non-shiny part. Normal maps affect more than just specular shiny hilights - the normal map affects all lighting, so having black or white under your transparent (non-shiny) parts is bad news.

   To check whether this has happened, I recommend Graphics Converter, which will show you your alpha and RGB channels separately, exactly as they are in the file.

2. Make sure your RGB value are normalized. The "length" of the normal (as encoded in RGB) must come out to a distance of 1. This is virtually impossible to do using PhotoShop or an image-oriented program...I suggest you use a real plugin to PhotoShop or Blender to create normal maps that are correctly "normalized".

It is also very possible that X-Plane's gamma correction is distorting normal maps, but that's one for me to fix.

Plugin Broken? It's Temporary

I just found out from a user that Chase View Delux doesn't work with X-Plane 940 beta 4. Here's what's going on:

• Plugins often end up running X-Plane code - when you make a call to the X-Plane SDK, the SDK sometimes passes the call right to X-Plane.
• X-Plane 940 beta 4 has heavy error checking on all of the X-Plane code.

Put these together and...X-Plane 940 beta 4 is putting heavy checking on plugins that wasn't there before.

Typically the kinds of problems caught by the error-checking code inside a plugin are not critical, but aren't bad things for authors to fix. Since we will turn off heavy error checking as soon as we get the systems code fixed, plugins will start working again..there's no need for plugin authors to recut anything.

A Slow Motion Car Crash

I'm driving at 55 mph on the highway. I drive over a nail, lose a tire, skid off the road, crash through the guard rail, plunge off a cliff, and die. That's not much fun. But when you get to the accident site, you'll probably be able to piece together what happened. The skid marks, the nail, the hole in the guard rail, the car wreckage below - you can connect the dots.

Now...let's say I'm driving 500 mph. Same nail, same out of control crash. But this time it's going to be a lot harder to tell what happened. Lord knows where the nail ends up, the distance from the nail strike to exiting the highway is going to be a lot bigger, and the car is going to be in smaller pieces scattered over a wider distance. It's going to take a lot longer to piece together what went wrong.

That, in a nutshell, describes the motivation for an X-Plane beta with all of the debug and safety checks on. X-Plane's normal operation is like the car doing 500 mph - when it crashes and dies, there's very little left that can be used to figure out what went wrong. When there is a bug in the code that destabilizes the sim, finding it via crashes in release builds takes a lot of developer time and slows the whole beta down.

With the safety checks on, X-Plane still crashes when something goes wrong - but the bodies and wreckage are all a lot closer to the scene of the crime, and the evidence left around is in much better shape.

One of the side effects of the safety builds is that they catch "harmless" coding mistakes - (harmless in quotes - the bug might seem harmless but who knows if that will always be true). XSquawkBox now quits the sim with an ugly alert box because it reads off the end of a piece of the airplane data structure via the plugin system. This hasn't hurt things in the past, but it's not really correct. Beta 5 should fix the underlying problem, letting you run XSquawkBox again. (The fix will be in X-Plane, not XSquawkBox.)

A Tip For Updating Electrical Systems

X-Plane 940 has a new electrical systems model and it has a few important differences from 930:

1. You must specify exactly how many buses your plane has. 930 provided two buses but then did a bunch of cross-tying behind the scenes in case you didn't have enough power sources.
2. X-Plane 940 requires that each battery and generator be on exactly one bus.
3. X-Plane 940 will not allow systems to be powered by non-existent buses.

Now this can have some strange side effects. Consider the default king-air with two generators and one battery:

• In 930 it has two buses, battery feeds both buses, and each generator feeds one. You could have systems split by bus and they would work unless you lost one generator and the battery.
• 940 defaults this plane to one bus, because on battery power only one bus will be fed.
• This means that in 940 all of your systems will be reset to bus 1.

But wait...if you import into Plane-Maker, the import will trash your system bus selections before you can increase the number of buses to 2. What can you do?

Here's a work-around: before you update your plane, make sure you have two battery and two generator switches on your panel. Then open in 940. The import will set 2 buses and your systems will be preserved.

Of course, by the next few betas this may all be moot because we may get something less crazy in there.

Driver Thrash

I'm seeing a number of bug reports where weird artifacts are showing up in 940...missing pieces of runway, flickering triangles...all sorts of good stuff!

I believe that this is due to some kind of bug relating to threading, X-Plane and the video drivers. I won't say whose fault it is because I really don't know. I do know that the bug appears to not happen on OS X. (But this could simply be because the threads time out differently on OS X.)

The changes to the rendering engine for 940 from 930 are substantial and aggressive - it'll take us a little bit to fix these things.

When you wonder how come programs don't use all 8 of your cores yet, well...this is why...multi-core programming is complex, tricky, tedious to debug, and often involves substantial changes from the original code.

12 GB For the RenderFarm

The global scenery gets cut on "the renderfarm", which is our name for the cluster of computers, each loaded with all of the input data for the global scenery. These computers chug for a few days to churn out the whole planet.

With the next global render I am trying an experiment: using one 8-core Mac Pro as the RenderFarm. We've never had more than 8 processors in the farm at a time; in the past to get 5 processors might have taken 3 machines. The appeal of a single machine is ease of setup; no data to sync between machines, no sorting out which machine did which tile and merging it all back.

Today I upgraded the Mac Pro's memory (again) to 12 GB. I thought the logic of why I did this might be of interest to X-Plane users who are trying to figure out "should I have more memory"?

Basically there are three memory limits we care about:

1. The virtual memory limit per process - generally 3 GB per process for a 32-bit application. If an application wants more memory tan this, regardless of what you have, it is dead.
2. The virtual memory limit for the whole machine. Since the machine virtual memory limit is a function of hard disk space, normal users will never care about this - we can have a huge amount of virtual memory.
3. The physical memory actually used by the sum of all programs actually running. Once all programs need more physical memory than you have, they start using hard drive, and they get really, really, really slow.

In the case of the render farm, our processing program runs on one DSF tile at a time. But with 18,000+ tiles we can take advantage of more cores by processing 8 tiles (using 8 copies of the program running at once) on 8 cores.

This is where memory comes in. Before the upgrade my machine had 4 GB of memory, allowing each of the 8 tiles to use a little bit less than 512 MB of RAM before we ran out of physical memory and started paging. (The OS takes a little bit for itself.)

Normally this is all good -- a typical run might only use 300 MB of RAM. But every now and then we hit New York City or Boston and the RAM use spikes out to 1500 MB or more.

This is okay if just one process hits New York, but what if a bunch of processes hit a big city at once? We blow past the physical RAM of the machine and every tile becomes slow at once. And because they are all slow at once, they take a very long time (hours) to clear this state.

(This state of thrash due to many processes is like 8 people trying to go through a doorway at once. If they would just take turns, they'd be through in a second. But by forcing 8 at once they get stuck. The operating system won't pause a few of the high-memory programs to let the others complete.)

Since the RenderFarm has to run overnight unattended, I upgraded RAM to 12 GB, for 1500 MB per rpocess before thrash. My hope is that for this investment, we'll be able to run the processing through without a human to unjam it.

What About X-Plane

So would a RAM upgrade for X-Plane help? Well we can apply what we know from above to figure it out. Generally, you need enough RAM that X-Plane + all other programs won't run out of physical memory. Since X-Plane is 32-bit (and can only use 3 GB of RAM) you are likely to be fine with 4 GB when running X-Plane + the OS. Any more and X-Plane can't take advantage.

The exception might be if you need to run X-Plane and another big program like PhotoShop at the same time. At that point you might want enough RAM for both to run at the same time.

Lego Brick Code

When Sergio first proposed generic instruments, his model was "lego bricks". The idea was to provide a number of very basic parts for panel makers and let panel makers mix and match. The result would be huge flexibility for airplane authors without code bloat.

The problem with non-generic instruments is that there is such a huge variety of behavior among airplanes...if Plane-Maker were to have options for every possible plane, the "special equipment" screen would require 3000 tabs and be completely unusable. Hence the need for a smaller unit of modeling: the lego brick.

The prop disc is the first feature I have done that is meant to be used only by a plugin, e.g. "lego brick" code. The X-Plane systems code sometimes suffers from the same "code bloat" problem as the instruments: a ton of very specific, very tweaky behaviors that interact in strange ways and become very difficult to manage. It's not that the systems code is bad code - it's that the scope of the problem is simply too large. That is, you can't expect X-Plane to cleanly simulate the systems of every airplane ever in a ton of detail through an a la carte menu of check-boxes.

The idea of the prop disc is: someone (LR or otherwise) can write a plugin that encodes a certain style of prop disc. That plugin can then be picked up and moved around like a generic instrument between planes (perhaps with a corresponding text file to control it).

If someone else comes up with a different/better prop-disc algorithm, compatibility isn't an issue...that person writes a new prop disc plugin and the airplane author selects the one desired. Think of it as sort of a portable flight model that stays with your plane.

So we win in three ways:

• Anyone can write the prop disc algorithm, not just LR.
• The code lives with the plane, to avoid compatibility problems.
• More than one plugin can exist, giving authors an a la carte menu.

That's the theory at least.

Tweaking the Prop Disc in 940

X-Plane 940 allows plugins to customize the prop disc. Details here on the wiki.

I put these datarefs in so that modelers wouldn't have to try to model prop discs with OBJs. The problems with prop discs are many:

• They need to be billboarded, and X-Plane does not provide datarefs for manual billboarding inside an airplane (particularly not to the engine's coordinate system, which can be transformed by all sorts of fun stuff).
• They often need variable translucency, which OBJ does not have.
• They cause all sorts of depth buffer errors, which OBJs cannot manage.

In short, prop discs are weirdly special-cased enough that I thought it would be better to provide a general set of parameter datarefs for prop discs and let X-Plane do the drawing.

These options are not available in Plane-Maker. Why not? That'll be my next post.

940 Beta 2 - Recovert Airplanes

I have ranted in the past about the importance of not treating beta builds of X-Plane as having finalized file formats. Generally a beta should be used to explore, experiment, and test old content, but not to create new finished work or ship product. File formats sometimes change during beta to work around bugs we find.

Another reason not to depend on the file formats of new betas is that sometimes we screw up. In the case of 940 beta 1, the code that converts 930 airplanes forward to the new 940 electrical system is pretty buggy (hence the reports of electrical systems doing wonky things, panel instruments disappearing, and general weirdness).

This one is our bug to fix and will be fixed in beta 2 (at least we think). But to "get the fix" authors will need to open their 930 saved airplane in 940. If you already re-saved the airplane in 940 then the 930->940 conversion code won't be re-run.

I'll try to post some info on the new electrical system on the Wiki, but for now: if in beta 2 you have a bug with a plane that used to work in 930, send us the 930 version of the plane so that we can convert it and watch the conversion screw up. If the plane is already in 940 format we don't know what our conversion code broke and what you edited in Plane-Maker.

Normal Maps in X-Plane 940

X-Plane 940 now supports normal maps on OBJ models (both scenery and airplane). I'll get more formal docs up once the rest of my office is moved and unpacked but here's the details for now:

The normal maps are in "blender" format see here. The alpha channel is optional; if it is present, it serves to modulate the level* of specularity. Opaque means full specularity, transparent means none. You can use this feature to make some parts of an object shiny and some dull on a per-pixel level.

Shininess level is modulated by both ATTR_shiny_rat and the alpha channel, so you need ATTR_shiny_rat 1.0 and an opaque alpha channel (or no alpha channel) to see full specularity.

Normal maps are only available for objects and only appear if pixel shaders are on and per-pixel lighting is enabled.

Normal maps should be PNG format, not DDS - they will not be texture compressed because S3TC compression tends to kill them. (There are some modern formats for normal map compression supported by the newer cards but we don't use them yet.)

* Specular level: most serious 3-d programs let you control both the specular exponent, which controls how "tight" the specular hilights are, and the specular level, which controls how bright they are. X-Plane only lets you control specular level; if specular hilights exist, they are always as the maximum exponent for the sharpest specular hilights.

More Threads

X-Plane 940 beta 1 is out...it will take a little bit to get the release notes and docs on the website completely up-to-date. We're still dealing with loose ends from our migration to the new web site, and most of my office is packed up for a move to the Boston area. I'll try to get docs up as fast as I can given the chaos flying about.

Given the interest multi-core stirred up in previous notes, I will mention one change to 940: with this build we've added yet more multi-core to X-Plane.

In 931, X-Plane will use as many cores as you have to load textures, but only one to build "3-d scenery" (a loose category for the work we do when we make airport taxiways and lines, build forests, and extrude roads).

In 940, this "3-d scenery" is also done on as many cores as you have. This should speed up load times a bit, particularly under very heavy tree settings, and hopefully keep the forest engine running faster for users with more cores.

It also sets us up for long-term growth; X-Plane's visual quality is sometimes limited by the time to build 3-d meshes...being able to do this work on many cores means we can use higher quality algorithms.

Consider for example the roads: my original "road extruder" (the code that converts a vector road into a 3-d model, called an extruder because it builds a 3-d road from a cross section like one of those play-dough toys) made beautiful intersections with stop-lines and cross walks and lots of other great stuff.

It was also really slow. And at the time the sim wouldn't fly at all while roads were extruded, so speed was of primary concern. So I replaced it with the much dumber extruder you see today, where intersections are basically ignored.

Now that we have 3-d scenery build on multiple cores, we can begin to provide rendering options that take more CPU time but produce higher quality results. The trees and airport layouts already do this (in that they take more time and produce slower, more detailed, higher triangle count sceneery at higher rendering setting for the same input DSF ad apt.dat file). With more cores, we can continue this strategy with roads and other parts of the sim without worrying about overloading the one core that was doing this work.

Of course just because we can use 8 cores doesn't mean we do...you won't see 8 cores maxed out very often, particularly if you have simple scenery and a very fast machine.

I am the Spam King!

If I have not emailed you back, it's probably because I've been very busy trying to interleave X-Plane coding and packing up the house. But it is also possible that my email response bounced because my web server has ended up on a bunch of anti-spam "black-lists".

Black-listing seems like a good idea at first: we'll gather up a list of all of the IP addresses from which spam comes from, then publish them. Then your local mail server can use that list to filter spam - you never see it!

In practice it doesn't work so well...example: http://www.mipspace.com/. The IP address for my server (XSquawkBox) is now on this list. Why?

MIPSpace is a list of IP Addresses associated with known commercial marketing companies.

Since my server is used for my own personal email and to run the SDK website, I'm not sure why I am on the list. I have sent them an email to clear things, but in general I hit an anti-spam/black-list bounce somewhat frequently now, and frankly I don't have time to separately try to clear my name from every guilty-until-proven-innocent blacklist that pops up and screws up my email.

If I seem disproportionately grumpy about this, it could be due to one of two reasons:

1. Not replying to emails is generally bad customer service. (Okay, my in-box is backed up four months...that's bad.) I don't like the idea that a customer might perceive us (LR) as being unresponsive because some third party with no skin in the game decides to black-list us.

   The blacklist has no incentive to be accurate - it's not their lost customers if email doesn't go through.

2. I'm not at all convinced that this is going to cut down unsolicited commercial mail and/or spam.

   In the spam case, spammers can send from botnets - they have access to a huge number of ever-changing IPs. Unless we are prepared to blacklist the entire internet, the blacklists are going to pick up more and more false positives while spammers find ways to harvest fresh, untainted IP addresses. The whole IP-reputation strategy assumes that IPs are hard to change. In practice, IPs are very, very easy to change.

   Commercial mail is a lost cause too - even if I am being solicited for commercial mail I don't want, no program or automatic process is ever going to tell the difference between the confirmation of my invoice and a list of discounts from the same company. When it comes to commercial mail, the reputation damage has to be done to the company, not the IP.

   (The company does have reputation to risk - if we are known as a company that doesn't honnor a "do not subscribe" policy, then customers can choose to not buy our products.)

It could also be because I ran out of Viagra and don't have a diploma from a prestigious non-acredited university.

Switch and Bail

I will be out of the office next week - it's August, time to head for the mountains...no cell coverage, no internet, no computers, no electricity...no mountains actually. (This is upstate New York...mountainous to someone from Boston but not mountains compared to what Sergio normally deals with.)

As you know, LR often shows stellar judgement in managing release risk. So in true X-Plane tradition, I swapped in the new revamped website last night, just in time to head for the hills and avoid the fall-out.

Here's the short version:

• I am wicked stupid.
  
• When I did the swap last night, I screwed up the files that manage the auto-update functionality, hosing the updater.
• I fixed these files this afternoon, once the message got back to me.

So if you saw weird stuff happen with the updater or the sim last night, please try again - it should be fixed. If it is still broken, please send an email to Austin and myself - one of us will hopefully be around.

I have also reskinned scenery.x-plane.com and wiki.x-plane.com to match the new site. If you find artifacts in those two sub-sites, please email me - I'll fix it as soon as I can. The wiki site is a MediaWiki skin - it was pretty tricky to get it working, so it may be a bit before I work all the kinks out.

Scenery Tools Bug Base

I have set up a public bug database for the scenery tools. The reason is that I don't have much continuous time to work on the scenery tools - it's very stop and go and will be for a while. The bug base lets you create a permanent record of a problem that I can't lose track of in the heat of whatever is on fire today.

WED is almost ready for a beta, but I am just completely swamped with work right now...for WED 1.0 I worked full time on fixing WED bugs for a significant time when WED went beta; this time around I won't have that kind of time - at least not this year.

So...we'll see how the bug base works out. My hope is that I can post WED, put it down, and pick up work on it intermittently with the bug base providing a record of what remains to be done.

Regarding other tools, there will be at least one more MeshTool beta with an improved shapefile processing algorithm that will handle broken shapefiles better. The ac3d plugin has some bugs filed against it but it's possible that they'd be deferred past the 3.2 plugin.

Accuracy, Plausibility, and OSM

I have been working on OpenStreetMap data for X-Plane this week. Use of OSM for global scenery is going to be a bit different from projects like X-VFR or other specific custom OSM-based scenery.

The issue at hand is accuracy vs. plausibility...

• Accuracy: how much error is there between what exists in the real world and what exists in the scenery. Is that road in the right location? Is it the right type of road?
• Plausibility: does the scenery as a whole look reasonable? Is that road on land or is it in the water? Is that river running up a mountain?

The global scenery needs to prefer plausibility over accuracy. Because we can't check and manually fix errors in the source data for the entire world, and because we don't cut the global scenery very often, it is important that the global scenery err on the side of reduced accuracy (remember, the global scenery isn't that accurate in the first place) rather than plausibility problems that will clearly be ugly and distracting.

The implication for OSM-based global scenery: not everything in OSM is going to show up in the global scenery. This would be true anyway simply due to the need to keep the global scenery compact. (I trust that OSM will grow to the point where it can source scenery larger than we can ship for the entire world.) But the global scenery generator may need to err on the side of not including data that might have plausibility problems.

Fortunately it is possible to build custom scenery from OSM as well. I don't see OSM-based global scenery as replacing efforts like X-VFR and others; rather custom scenery will always be able to use more OSM data , checking the data for accuracy, rather than reducing the data to maintain plausibility.

One technical note: I am working on an extention to the road .net file format that would allow road networks to be draped over terrain. This would allow overlay packages to add/replace road grids without having to know the shape of the base scenery mesh, and make it easier to both create custom road networks and to create the tools that manipulate them.

OSM: What You Can Do

I've been working with OpenStreetMap (OSM) data this week. The great thing about OSM (besides already containing a huge amount of road data) is that you can edit and correct data - that is, OSM manages the problem of "crowd sourcing" world map source data.

I get email from people all the time, saying "how can I help fix my local area of the global scenery". With OSM, you can help., by improving OSM's source data.

Here are two things that will matter in the quality of generated scenery:

1. The oneway tag. Roads that are one-way need to have this tag, or the conversion to X-Plane might have an incorrect two-way road in place. If you don't see the one-way arrows on the OSM map rendering then this tag might be missing.
2. The layer tag. When roads cross, "layer" tells OSM which one is on top (and that they do not intersect). Similarly, if a highway is underground, it's because it has a negative layer. If the layer tag is missing, complex intersections will probably render as junk.

In the US, a lot of OSM is built off an import of the TIGER census road map. Unfortunately TIGER in its previous released form does not contain one-way or layering information. So particularly for US cities, adding these tags will improve the road rendering a lot!

Broken Materials in 931

There is a bug in the newly released 931. When:

• Clouds are set to stratus and
• Pixel shaders are on and
• The airplane has an OBJ that uses ATTR_diffuse_rgb

the attribute is ignored, which typically makes things appear white. The primary example that has been reported to me is the throttle quadrant of the Piper Malibu.

This is simply a bug in the shaders (which is failing to apply the diffuse tinting to ambient-only lighting conditions); I have a fix, but I'm not sure how soon it will be released. We will probably do a small bug-fix release with this and one or two other things, but this is yet to be finalized, since Austin is out of the office this week.

Bad Scenery Data

I receive bug reports periodically relating to how X-Plane and the scenery tools handle badly formed scenery files. Here's the rules:

• It is a bug in the scenery tools if they create illegal scenery data.  They should at least flag the condition that is leading to an illegal file and refuse to proceed.
• It is a bug in the scenery tools if they crash when trying to import illegal scenery data. Crashing can mean data loss, which is bad.
• X-Plane's behavior with regards to illegal scenery data is undefined!  This means it is not a bug for X-Plane to show a certain behavior with bad input data.
• There is no guarantee that X-Plane's response to illegal scenery data will remain constant over multiple patches, or even multiple executions of the sim.

This third point has some dangerous consequences:

• X-Plane might handle illegal data in a way that an author views as useful; this "useful" side effect might go away in a future version.
• X-Plane might crash in response to illegal data...sometimes.
• There is no guarantee that X-Plane will provide useful diagnostics.

The reason for this scheme is that X-Plane is under pressure to get scenery loaded quickly, so at some point, there is a limit to how much validation it can do.

With that in mind, I do try to validate scenery when a problem is very common and the validation is not very expensive, or when there are serious data quality problems.  But as we move to having the tools do more validation, we can have validation where we need it: immediately, for the authors working on the scenery.

Grand Canyon

To answer the most basic questions:

• This is a base mesh orthophoto scenery I made with MeshTool, as a test.
• The source DEM is 10m NED, the source imagery is 1mpp DOQQ, down-scaled to 3mpp. I gave MeshTool a point budget of 500,000 mesh points per DSF tile, and it used them all.
• This version of MeshTool (2.0 beta 2) should be out in the next 3 days.
• That's X-Plane 930RC4. The framerate really is around 100 fps.
• There are no dynamic real-time shadows. Rather, the orthophotos have the shadows "baked" in because they're photos.
• There are artifacts at the joins of the orthophotos because I spent time fixing projection errors.
  

Clearly we need more than 25 nm visibility in some cases!

Invisible Hard Surfaces

I have received several requests for a transparent runway with a physical surface type. That request is just strange enough that we need to look back and ask, "how did we get here?"

High Level and Low Level Modeling

The "new" airport system, implemented in X-Plane 850 (with a new apt.dat spec to go with it) is based on a set of lower level drawing primitives, all of which are available via DSF. In other words, if Sergio and I can create an effect to implement the apt.dat spec, you can make this effect directly with your own art assets using a DSF overlay. This relieves pressure on the apt.dat spec to become a kitchen sink of tiny details.

The goal of apt.dat is to make a visually pleasing general rendering of airport data. DSF overlays provide a modeling facility.

Little Tricks

It turns out there are two things the apt.dat file "does" with the rendering engine that you can't do in an overlay DSF:

1. The apt.dat file registers runways in the airport dialog box (for starting flights, positioning the airplane, etc.).

2. When the apt.dat reader places OBJs to form approach lights, it can offset their "timing base", which is why the rabbit flashes in sequence.

(If you were to place a sequence of approach lights with rabbits in an overlay, every single light would flash at the same time because the DSF overlay format does not have a way to adjust the object's internal timing parameter.)

The solution: the transparent runway. The idea of the transparent runway is to create with the apt.dat file the two aspects of a runway that you can't build with a DSF overlay: the approach lights and the entry in the global airport dialog box. Transparent runways leave the drawing and surface up to you.

My thinking at the time was that the actual runway visuals and physics would be implemented together via either draped polygons or a hard OBJ.

Orthophotos and Bumps

So why do authors want a transparent but hard runway? The answer is orthophotos. With paged orthophotos, it is now possible to simply put down orthophotos for the entire airport surface area (whether as overlays or a base mesh) at some high resolution (our runways are 10 cm per pixel - I'm not sure if the whole airport area can be done at that resolution) and not have any special overlays for the runways. The transparent + hard runway would change the surface type.

I'm not sure if this is a good idea, but I'm pretty sure that this feature belongs in overlay DSFs and not the apt.dat file.

• Such a technique (varying hard surfaces independent of a larger image) is useful for more than just airports (and certainly more than just runways).
• The technique is unnecessary unless a DSF overlay is in use.
• Unlike nearly all of the rest of the apt.dat file, such an abstraction (invisible but bumpy) is much more a modeling technique and less a description of a real world runway.

I'm not sure we would even want the runway outline to be the source of hard data. If there are significant paved areas outside the runway then a few larger hard surface polygons might be more useful.

Where Do I Find the 930 Datarefs

The dataref documentation on the X-Plane SDK website is updated for each release of X-Plane 9.

X-Plane 930 has not yet been released. It is a "release candidate" but since we haven't signed off on it yet, 922r1 is still the most current real release of X-Plane, and it's what users get when they update without asking for a beta. So the website has 922 datarefs.

Since version 9, every release of X-Plane (including betas and RCs) has a copy of datarefs.txt in the plugins folder that is correct for that release. In other words, the docs that ship with X-Plane and the sim itself are always in sync.

So for now use datarefs.txt in the 930 RC 2 plugins folder! When 930 goes final, the website will be updated.

ASTER For Custom Scenery

A few days ago, the ASTER GDEM was released. Basically ASTER GDEM is a new elevation set with even greater coverage than the SRTM. Basically both SRTM and ASTER (I'll drop the GDEM - in fact ASTER prodcues more than just elevation data, but the elevation data is what gets flight simmers excited right now) are space-based automated measurement of the earth's height. But since ASTER is on a satellite (as opposed to an orbiting space shuttle) it can reach latitudes closer to the poles.

So what does this mean for scenery? What does it mean for the global scenery? A few thoughts:

• ASTER data is not yet very easy to get. You can sign up with the USGS distribution website but you're limited to 100 tiles at a time, with some latency between when you ask and when you get an FTP site. Compare this to SRTM, which can be downloaded automatically in its entirety, or ordered on DVD. ASTER may reach this level of availability, but it's not there yet.

• ASTER is, well, lumpy. (Nasa says "research grade", but you and I can say "lumpy".) Jonathan de Ferranti describes ASTER and its limitations in quite some detail. Of particular note is that while the file resolution is 30m, the effective resolution of useful data will be less.

  SRTM has its defects, too, but ASTER is very new, so the GIS community hasn't had a chance to produce "cleaned up" ASTER. And clean-up matters; it only takes one really nice big spike in a flat flood plane to make a "bug" in global scenery. I grabbed the ASTER DEMs for the Grand Canyon. Coverage was quite good, despite the steep terrain angle (steep terrain is problematic by design for SRTM) but there were still drop-out areas that were filled with SRTM3 DEMs, and the filled-in area was noticeable.

• By the numbers, ASTER is not as good as NED; I imagine that other country-specific national elevation datasets are also both more accurate and more precise than ASTER.

• The licensing terms are, well, unclear. The agreements I've seen imply a limited set of research uses for the data. The copyright terms are not well specified.
  

So at this point I think ASTER is a great new resource for custom scenery, where an author can grab an ASTER DEM in a reasonable amount of time, check it carefully, and thus have access to high quality data for remote parts of the Earth, particularly areas where locally grown data is not available or not high quality.

In the long term, ASTER is a huge addition to the set of data available because of its wide-scale coverage of remote areas, and because it can fill holes in SRTM. (ASTER and SRTM suffer from different causes for drop-outs, so it is imaginable that there won't be a 1:1 correlation in drop-outs.)

But in the short term, I don't think ASTER is a SRTM replacement for global scenery; void-filled SRTM is a mature product, reasonably free of weirdness (and sometimes useful data). ASTER is very new, and exciting, but not ready for use in global scenery.

The Will to Rewrite

FSBreak interviewed Austin last week....it's an interesting listen and they cover a lot of ground. A few comments on Laminar's approach to developing software:

That Code Stinks!

Austin is absolutely correct that we (LR) write better software because neither of us are shy about telling the other when a piece of code stinks. But I think Austin deserves the credit for creating this environment. An "ego-free" zone where people can criticize each other honestly and freely is a rare and valuable thing, in many domains, not just music.

When I first came to LR, Austin created this environment by responding positively to feedback, no matter how, um, honest. When I first came to LR 100% of the code was written by him and 0% by me. Thus if I was going to say "this piece of code really needs to be different", it was going to be Austin to either run with it or try to defend his previous work.

To his credit, Austin ran with it, 100% of the time. I can't think of a single time that he didn't come down on the side of "let's make X-Plane better". That set the tone for the environment we have now: one that is data driven, regardless of who the original author is.

I would say this to any programmer who faces a harsh critique of code: good programmers write bad code! I have rewritten the culling code (the code that decides whether an OBJ really needs to be drawn*) perhaps four times now in the last five years. Each time I rewrote the code, it was a big improvement. But that doesn't make the original code a mistake - the previous iterations were still improvements in their day. Programming is an iterative process. It is possible to write code that is both good and valuable to the company and going to need to be torn out a year later.

A Rewrite Is Not A Compatibility Break

Austin also points to the constant rewriting of X-Plane as a source of performance. This is true too - Austin has a zero tolerance policy toward old crufty code. If we know the code has gotten ugly and we know what we would do to make the code clean, we do that, immediately, without delay. Why would you ever put off fixing old code?

Having worked like this for a while, I am now amazed at the extent to which other organizations (including ones I have worked in) are willing to put off cleaning up code organization problems.

Simply put, software companies make money by changing code, and the cost is how long the changes take. If code is organized to make changing it slower, this fundamentally affects the financial viability of the company! (And the longer the code is left messy, the more difficult it will be to clean up later.)

But I must also point out one critical detail: rewriting the code doesn't mean breaking compatibility! Consider the OBJ engine, which has been rewritten more times than I care to remember. It still loads OBJ2 files from X-Plane 620.

When we rework a section of the sim, we make sure that the structure of the code exactly matches what we are working on now (rather than what we were working on two years ago) so that new development fits into the existing code well. But it is not necessary to drop pieces of the code to achieve that. I would describe this "refactoring" as straightening a curvy highway so you can drive faster. If the highway went from LA to San Francisco, it still will - just in less time.

In fact, I think the issue of compatibility in X-Plane's flight model has a lot more to do with whether the goal is to emulate reality or past results. This debate is orthoganal to refactoring code on a regular basis.

* Since OBJs are expensive to draw and there are a huge number of OBJs in a scenery tile, the decision about whether to draw an OBJ is really important to performance. Make bad decisions, you hurt fps. Spend too long debating what to draw, you also hurt fps!

Do Not Work Around Our Bugs!

For most of its beta run, X-Plane 930 beta 14 didn't handle engine power limiting very well*. Here's the short version of the saga.

• Real planes sometimes have systems to limit total power output, because the power output of the engine (whether torque or internal temperature) can exceed safe operating limits at sea level).
  
• With X-Plane 9.00 you could set a critical altitude for an airplane - below this altitude, X-Plane would limit the power output of the jet. The idea is (roughly) to simulate these limiters by derating the engine's power output below this "critical altitude".
• This feature was really only meant for reciprocating engines - when Austin discovered in 9.20 that people were using this for turbines (understandable, given that there was no alternative) he simply disabled the feature for turbines. That wasn't so good.
• To resolve the situation a little bit more cleanly, X-Plane 9.30 has a setting per airplane called "FADEC - automatically keep engines from exceeding max allowable power or thrust" that, when checked, gives you version 9.00 style behavior.

Now this was mostly good except for one problem: the betas would default this setting to "off" when loading an old plane. Since version 9 always acted as if the "FADEC"** was on, this meant that old planes would need to be edited.

Finally with beta 14 we switched things: beta 14 and newer default old planes to have the FADEC checkbox on, so that planes match their old behavior - you can turn the check-box off if you don't want this behavior.

There is one final hitch: if you already went in and edited your airplanes for the earlier betas, you will find that they are now set wrong. You will have to reset the check-box. If you go back to the original, unedited, 920-compatible airplane you will find they "just work".

I mention all of this to make two points:

1. File formats for new features are subject to change during beta. In this case, the file format for the new FADEC check-box (introduced in 930) changed at beta 14. The OBJ syntax for dynamic lighting changed during beta too. Don't do "bulk" work (e.g. change a large number of planes in the same way ) on your fleet based on betas - you might have to redo that work again! Wait until the sim goes final. That's when the file formats are locked up.
2. Don't work around bugs in the sim. I have seen so many forum posts where there is a trivial bug in the sim (e.g. the sim is just screwed up in a simple way) and authors go in and update scenery to work around the bug. File a bug, then wait! If you work around the bug, we can't fix the bug, and if we don't fix the bug, then the bug just bites other users.

* Disclaimer: I don't do systems, I don't know anything about airplanes, so this whole discussion will be heavily simplified. The point of this post is not to get into a discussion of FADECS - in fact, don't even bother to post about FADECs, I'm not going to approve them. If you want to talk about FADECs and engine modeling, email Austin. The point of this post is one about file formats and compatibility.

** FADEC isn't a very good name for this feature - the feature generically limits power, without specifying a mechanism. My understanding is that some airplanes have mechanical limters, like a pressure valve on a turbo. Some planes have no limiters at all...ask a pilot "can you cook the engine by pushing the throttle too far" he will say "I'm not going to be the one to find out."

Optimization By Check-Boxes

In the next X-Plane 930 beta (it should post today I think) the rendering settings have two new check-boxes: one to enable the "dynamic" airplane shadow and one to enable per-pixel lighting.

In the last week a number of users emailed me performance numbers via the fps test, and from what I can tell, 99% of performance problems can be attributed to these two new features chewing up resources in a way that 922 did not. When the features are both disabled, from what I can tell, the sim should be as fast or faster than 922.

The new beta will also limits dynamic shadows to your aircraft - beta 13 will calculate a dynamic shadow for every aircraft, which is unacceptably slow when you have a lot of AI planes enabled.

I may still be able to improve the performance of the per-pixel-lighting shader, but fundamentally per-pixel lighting is going to be more expensive than per vertex. The average X-Plane scene might have 200,000 to 500,000 vertices. At absolute minimum resolution, no FSAA, you're going to have over 700,000 pixels even if there is no "over-draw" - you could easily have 10x that fill rate with only a modest increase in overdraw, full-screen anti-aliasing and window size. Simply put, per-pixel lighting is more work.

Please bear in mind: without per-pixel lighting X-Plane's pixel shader is extremely simple. If you have a "low-end" card this could give you the illusion of GPU power when there is really not much under the hood.

Examples of low-end cards: GeForce 7300, GeForce 8400, GeForce 9400, Radeon X300, Radeon X1300, Radeon HD2400. All of these cards are the younger brother of a fairly capable card, but with fewer pixel shader units/cores. If each unit is doing very little work, you don't need that much pixel-filling power...but when we go to a "real" shader, the difference between a GeForce 8400 and 8800 becomes very, very apparent. Simply put, even with optimization the GeForce 7300 (for example) will never run a huge monitor with per pixel lighting and high FSAA.

To Copy Or To Reference

In designing interfaces for building planes, writing plugins, etc. one of the main design questions that keeps coming up is: to copy or to reference? Should authors simply refer to an art asset, piece of data, or code in order to utilize it, or should the author copy a snapshot into the custom add-on. There isn't one right answer. Here are the main considerations.

Performance and Efficiency

One of the obvious considerations is efficiency: in some cases we might be able to provide better performance when an art asset is referred from a common source.

For example, in some cases X-Plane will consolidate VRAM use based on actual files, so a library object is loaded once no matter how many packages use it, but is loaded many times if a package copies it.

(In other cases X-Plane will actually merge multiple copies of a resource - referencing is only a win in some cases.)

An indirect consideration: if an art asset is provided by Laminar Research and is used by reference, then a new update can provide a new, better optimized art asset - see below.

Dependencies and Contracts

When someone uses an art asset, algorithm, etc. by reference, it creates an implicit contract by the provider of the asset by reference to not change the properties of the asset. By comparison, when the asset is copied, the contract is only to support the format that the asset is encoded in.

This is the main reason why I am often against providing new assets by reference, whether it is a new dataref, texture, etc. Often I will simply send a user a snippet of code, rather than making X-Plane's version available via a dataref. The idea is that copying does not create a new interface (and thus a new "contract") between X-Plane and the add-on.

Copyright and Legal Issues

For historical reasons, the US legal system describes the privileges of intellectual property owners by regulating the act of copying. (To say that this is a bit quaint in the digital age doesn't even scratch the surface, but that's a rant for another post.) The result of this particular regulation of copying (but not of referencing) is that the decision to provide an asset by copy vs. reference has legal implications. If the author does not want to go through licensing, referencing may be the only option.

The Constraints of Hardware

In a previous post (in which I tried to argue that threading is a "how" and not a "what" when it comes to feature requests) a user made this comment:

That is, that I feel you are a bit too concerned about the fact that XP has to be possible to run on a 2001 year machine. This really halts the development although you could add options to turn this and that off.

I'd like to side-step around the details of cost-benefit analysis (e.g. do the sales from low-end systems pay for the development of a renderer with lower system requirements) but take a second to focus on three general issues:

• Is there a cost to developing a scalable renderer?
• How does the trend of hardware development affect hardware?
• How do marketing forces affect both of the above?

Scalability

Is there a cost to writing a renderer that can run on a wide range of hardware? Absolutely. Obviously we have to write more code to do that.

But there is an additional cost: there are some rendering engine design decisions that have to be made system-wide. It's not practical to provide different scenery files for different hardware (since we are limited by distribution on DVD). In some cases we have to pick a non-ideal data layout (for the highest end hardware) to support everyone.

But: before you raise up arms against your fellow X-Plane user who is holding you down with his GeForce 2 MX and P-III 800 mhz machine, bear in mind that the problem of picking a data format is a bit unavoidable. Even if we targeted the highest-end machines and told everyone else to jump in a lake, those decisions would appear to target rather quaint machines only a year into the version run. At some point we have to pick a line in the sand.

There is some light at the end of the tunnel when it comes to scalability: as computers become (on average) bigger and faster, we can start to defer at least a little bit of the work of scenery generation to while the sim is running. When we first designed the new sceney system (for X-Plane 8) most users did not have dual-core machines, so the doing work on the scenery was very expensive. We preprocessed as much as possible. This isn't as necessary any more.

So are high-end users limited by having one renderer that fits all sizes? Perhaps a little bit, but any design choice is only going to fit one hardware profile perfectly, and hardware is a moving target; today's shiny new toy is tomorrow's junk.

Hardware Growth

Every two years (to be very loose about things) the number of transistors we can pack on a chip doubles. This "transistor dividend" can be turned into more cores for a CPU, or more shading units (which are now really just cores) for a GPU.

And this gets to the heart of why I don't think we can say "forge the low-end" any time soon. Imagine that we support 6 years of hardware with X-Plane, and the best hardware is 8 times as powerful as the low-end hardware. Fast-forward two years - we drop two-years of hardware and two-years of new ATI and NV graphics cards come out. What is the result?

Well, the newest hardware is still 8x as powerful as the old hardware, but the difference in the polygon budget between the two has now doubled! In other words, the gap in absolute performance is doubling every two years, driving the two ends of our hardware spectrum farther apart. (Absolute performance is what Sergio and I have to worry about when we design a new feature. How many triangles can we use is an absolute measurement.)

If we say "okay forget it, only 3 years of supported hardware" that gets us out of jail for a little while, but eventually even the difference between the newest and slightly off-the-run hardware will be very large.

A gap in hardware capability is inevitable and it will only get worse!

Market Divergence

You may have noticed that the above paragraph makes a really gross assumption: that the lowest end hardware we support is the very best card on the market from a certain number of years ago. Of course this isn't true at all. The lowest end hardware we support was probably pretty lame even when it was first made. The GeForce FX 5200 was never, even for a microsecond, a good graphics card. (It was, however, quite cheap even when first released.)

So the gap we really have is between the oldest low-end and newest high-end hardware, which is really quite wide. Consider that in May 2007 the GeForce 8800 Ultra was capable of 576 GFLOPs. Two months later (July 2007) the GeForce 8300 GS was released, packing a whopping 22 GFLOPs. In other words, in one video card generation the gap between the best and worst new card NVidia was putting out was 26x! (I realize GFLOPs isn't a great metric for graphics card performance - really no one metric is adequate, but this example is to illustrate a point.)

Let's go back in time a few years. In February 2002, NVidia released the GeForce 4 Ti (high-end) and MX (low-end. The slowest MX could fill 1000 MT/s, while the fastest Ti could fill 2400 MT/s. That's a difference in fil rate of "only" 2.4x.

What's going on here? Commodification! Simply put, graphics cards have reached the point where a lot of people just don't care. Very few users need the full power of a GeForce 8800, so a lot of lower-end machines are sold with low-end technology - more than adequate for checking email and watching web videos. This creates a market for low-end parts and creates a wider "gap" for X-Plane. Dedicated returning X-Plane users might do the research and buy the fastest video card, but plenty of new users already have the computer, and it might have something unfortunately (like a Radeon X300 or Intel GMA950) already on the motherboard.

As X-Plane's hardware needs diverge from the needs of mainstream computer users, we can expect some but not all of our users to have the latest and greatest. We can also expect plenty of new users to have underpowered machines.

Let me go out on a limb (I am not a technologist or even a hardware guy, so this opinion isn't worth the bits it is printed on) and suggest this: we're going to see a commodification fall-off in the number of cores everyone has too. Everyone is going to have two cores because it is cheap to put a second core on the main CPU if it lets you get rid of a whole array of special-purpose hardware. Give me multi-core and maybe I can get away with software-driven rendering (who needs hardware acceleration), software-driven sound (goodbye DSP chips), maybe I can even find cheaper ways to build my I/O. But 16 cores? The average user doesn't need 16 cores to check email and run Windows 7.

So as transistors continue to shrink and it becomes possible to pack 8 or 16 cores on a die, I expect some people to have this and others not to. We'll end up in the same situation as the graphics chips.

Summing It Up

To sum it up, sure there may be some drag on X-Plane in supporting a wider range of hardware. But it's an inevitable requirement, because hardware shifts in capability even during a single version run, and as hardware becomes faster, the gap between -end and cheap systems gets wider.

Glass vs. Glass (Translucent)

In Plane-Maker you will see that there are two "glass" lighting modes for instruments - one called "glass" and the other called "glass (translucent)".

What's the difference?  The difference is how they respond to their lighting rheostat being turned down.

• Glass becomes dim by mixing the RGB colors of the overlays toward black.
• Glass (tranlsucent) becomes dim by mixing the alpha channel of the overlays toward transparent.

Which one do you want?  It depends on what you are doing.  The rules I suggest are:

• Use "glass" if you are using the layer as a "mask" to block elements behind it.
• Use "glass (translucent) if you are using the layer as an "overlay" to draw on top of other elements.

A Few More Manipulators

I'm not sure if these will make it into X-Plane 9.30 (we're trying to close down features, but it doesn't do much good to hold off features that help people make airplanes) but...while I was in Italy I created a few more manipulator types.

The set of manipulators let you change the value of a dataref directly with a mouse-click - the various flavors control how the dataref is changed.

These manipulators are the natural corollary to the command manipulator, which runs a command on a click.

Why have both? Commands are good, but they don't cover 100% of sim functionality (just like datarefs don't cover 100% of sim functionality).  By having both, it will be possible to control switches and buttons that are best accessed by a dataref change.

For the basics on commands vs. datarefs, see here.

The generic instruments already write to both commands (via the trigger instrument) and datarefs (via the rotary instrument) - these new manipulators provide the same functionality for 3-d cockpits.

Multi-Threading Is a Weird Feature Request

Over and over, whether it is a feature request list for X-Plane or another simulator, I see the same thing: "multi-core support" or "multi-threading" as a feature request.

Now before I continue, I must remind everyone: X-Plane is already multi-threaded and will take advantage of multi-core hardware. How much we use those cores depends on the type of scenery loaded.

The problem is that multi-threading (as a way to use multi-core hardware) is a solution technique, not a problem statement.  What is threading going to be used for?  If I simply program the other 7 cores of your computer to calculate PI to 223,924 digits have I met the feature request?  This probably isn't what anyone wants.

Implicit in the request for multi-core is (I speculate) a request for better frame-rate.  (I did see one user who wanted multi-core to be used for a more accurate flight model.  This strikes me as a poor trade-off for hardware based on my understanding of the flightmodel - we would use a lot of hardware for only a marginal accuracy improvement - but I commend the user for stating the problem and not just a possible solution.) But is multi-threading the best way to get framerate?

If I had two patches to X-Plane, one that doubled fps by using two cores and one that doubled fps by using more efficient code, which would be better?  To me the obvious answer is: the code that is more efficient.  It will run on any hardware (not just multi-core) and if you have multi-core hardware, we still have that second core free for some other functionality.

So to me the feature request should be something like: "higher framerate - and yes I have multi-core hardware".  Or perhaps "more visual detail at the same framerate - and yes I have multi-core hardware".

All feature requests need to be in terms of problem statements, not possible solutions.  This lets us find the set of problems that can be solved together in a coherent manner, and it lets us pick a solution that meets our engineering goals.

Masks for Glass Instruments

X-Plane's panel system does not have true "masking" based on a bitmap.  You can clip an instrument to its rectangular region, but most masks are made by overlaying another layer or instrument on top of the moving parts.  Examples include the circular mask for the moving map and the outside of the artificial horizon dial.

If you are using ATTR_cockpit then what you see in the OBJ is just like what you see in the 2-d panel, and the masking problem is simple: pick a mask that matches your background.  In particular, if the back of the panel is black, your mask must be black; if the back of your panel has a gradient, the mask must contain a copy of a slice of the gradient.

But there are two cases where this rule does not work the way you might expect.

Masks for 2-d Spotlights

The 2-d spotlight textures (panel-2, panel-3, etc.) have a strange property: they light the background of the panel (the "burned in layer") per-pixel but the overlays are lit per vertex. This is a cheat to keep the frame-rate high.

Normally this is not a problem - the moving parts are small and look different enough from the background that the lighting mismatch is not visible.  But if you have a mask in the 2-d panel and spot lights, it will not match!

Unfortunately there is not much you can do about this.  The only thing you can do is to keep the spotlight color uniform over the entire mask region.

Masks for Cockpit Regions

When you use ATTR_cockpit_region, the lighting model for your 3-d cockpit changes: instead of drawing the panel (as you saw it in 2-d), X-Plane calculates the albedo (day-time) and emissive ("_LIT") components of the panel separately and then combines them with real 3-d lighting.

The good news is that the spot light problem is no longer a problem.  Since the spot lights are 3-d and are applied to these final "panel textures", a mask that matches the background will blend perfectly.

But in order to mask, you need to know which part of the panel texture you are masking (albedo or emissive!).  If you are masking the albedo texture (e.g. a mechanical artificial horizon), create a mask that looks just like the panel background.

But for a glass instrument, the moving parts go into the emissive layer.  Your mask must be pure black!  Where did I get that from?  The emissive layer adds light to the object.  Black is an absence of adding light.  So pure black 'erases' any light-only elements (which include all glass EFIS instruments, etc.).

One nice thing about this strategy: you can build a custom glass instrument (with a black mask) and put it over any background. This means you can reuse your art assets no matter how they are positioned on the panel.

I'm Back

After almost three weeks in Europe, I am now back home!

First, I would like to thank the entire team that put together the French X-Plane Congress - it was a wonderful event - you guys did an amazing job!  It was great to see so many X-Plane people in one place (including the elusive Marginal!). The French X-Plane community is a strong group and it shows.

I would also like to thank Cris for setting up an informal Italian X-Plane get-together (complete with the Zurich delegation :-) for our last night.  We didn't get much sleep, but it was great to see so many people again before we flew back home.

At this point my in-box looks like someone dropped a bomb on it...it'll take a while to dig everything out.  The first priority of business is X-Plane 930 - we'll do a series of betas over the next week or two that will hopefully put the release to bed. Once 930 is done, I can probably beta WED 1.1 and get back to work on scenery.