Plugin Performance

This blog post is for amateur plugin developers. By amateur I mean: some plugin developers are professional programmers by day, and are already familiar with all aspects of the software development progress. For those developers, the SDK is unsurprising and performance is simply a matter of applying standard practice: locate the worst performance problem, fix it, wash-rinse-repeat.

But we also have a dedicated set of amateur plugin developers - whether they had programming experience before as hobbyists, or learned C to take their add-ons to the next level, this group is very dedicated, but doesn't have the years of professional experience to draw on.

If you're in that second group, this post is for you. Explaining how to performance tune code is well beyond the scope of a blog post, but I do want to address some fundamental ideas.

I receive a number of questions about plugin performance (to which the answer is always "that's not going to cause a performance problem"). It is understandable that programmers would be concerned about performance; X-Plane is a high performance environment, and a plugin that wrecks that will be rejected by users. But how do you go from worrying about performance to fixing it?

Measure, Measure, Measure, Measure.

If I had to go crazy and recite a sweaty and embarrassing mantra about performance tuning so that I could be humiliated on YouTube it would go: measure, measure, measure, measure.

If you want your plugin to be fast, the single most important thing to know is: you have to find performance problems by measurement, not by speculation, guessing or logic.

If you are unfamiliar with a problem domain (which means you are writing new code or a new algorithm - that is, doing something interesting), there is no way you are going to make a good guess as to where a performance problem is.

If you have a ton of experience in a domain, you still shouldn't be guessing! After 5 years of working on X-Plane, I can make some good guesses as to where performance problems should be. But I only use those guesses to search in the likely places first! Even with good guesses, I rely on measurement and observation to make sure my guess wasn't stupid. And even after 5 years of working on the rendering engine, my guesses are wrong more often than they are right. That's just how performance tuning is: it's really hard for us to guess where a performance problem might be.*

Fortunately, the most important thing to do, measuring real performance problems, is also the easiest, and requires no special tools. The number one way to check performance: remove the code in question! Simply remove your plugin and compare frame-rate. If removing the plugin does not improve fps, your plugin is not hurting fps.

It is very, very important to make frame-rate comparison measurements under equal conditions. If you measure with your plugin in the ocean and without your plugin at LOWI, the results are meaningless. Here's a trick I use in X-Plane all the time: I set my new code to run only if the mouse is on the right half of the screen. That way I can be sitting at a fixed location, with the camera not moving, and by mousing around, I can very rapidly compare "with code", "without code". The camera doesn't move, the flight model is doing the same thing - I have isolated just the routine in question. You can do the same thing in your plugin.

Understand Setup Vs. Execution

This is just a rule of thumb, and you cannot use this rule instead of measuring. But generally: libraries are organized so that "execution" code (doing stuff) is fast, while setup and cleanup code may not be. The SDK is definitely in this category. To give a few examples:

• Drawing with a texture in OpenGL is very fast. Loading up a texture is not fast.
• Reading a dataref is fast. Finding a dataref is not as fast.
• Opening a file is usually slower than reading a file.
  
• You can run a flight loop per frame without performance problems. But you should only register it once.

If you want to pick a general design pattern, separate setup from execution, and performance-tune them separately. You want things that happen all the time to be very fast, and you can be quite intolerant of performance problems in execution code. But if you have setup code in your execution code (e.g. you load your textures from disk during a draw callback) you are fighting the grain; the library you are using probably hasn't tuned those setup calls to be as fast as the execution code.

Math And Logic Is Fast

Modern computers are astoundingly fast. If you are worried that doing a slightly more complex calculation will hurt frame-rate, don't be. One of the most common questions about performance I get is: will my systems code slow down X-Plane. It probably won't - the things you calculate in systems logic are trivial in computer-terms. (But - always measure, don't just read my blog post!)

In order to have slow code you basically need one of two things:

1. A loop. Once you start doing some math multiple times, it can add up. Adding numbers is fast. Adding numbers 4,000,000,000 times is not fast. It only takes one for-loop to make fast code slow.
2. A sub-routine. The subroutine could be doing anything, including a loop. Once you start calling other people's code, your code might get slow.

This is where the professionals have a certain edge: they know how much a set of standard computer operations "cost" in terms of performance. What really happens when you allocate a block of memory? Open a file? If you understand everything going on to make those things happen, you can have a good idea of how expensive they are.

Fortunately, you don't need to know. You need to measure!

SDK Callbacks Are Fast (Enough)

The SDK's XPLM library serves as a mediator between plugins and X-Plane. Fortunately, the mediation infrastructure is reasonably fast. Mediation includes things like requesting a dataref from another plugin, or firing off a draw callback. This "callback" overhead contains no loops internally, and thus it is fast enough that you won't have performance problems doing it correctly. One draw callback that runs every frame? Not a performance problem. Read a dataref? Not a performance problem. (Read a dataref 4,000,000 times inside a for-loop...well, that can be slow, as can anything!)

However you should be aware that some plugin routines "do work". For example, XPLMDrawObject doesn't just do mediation (into X-Plane), it actually draws the object. Calls that do "real work" do have the potential to be slower.

Be ware of one exception: a dataref read looks to you like a request for data. But really it happens in two parts. First the SDK makes a call into the other plugin that provides the data (often but not always X-Plane itself) and then that other plugin comes up with the data. So whenI say "dataref reads are fast" what I really mean is: the part of a dataref read that the SDK takes care of is fast. If the dataref read goes into a badly written plugin, the read could be very, very slow. All of the datarefs inside X-Plane vary from fast to very fast, but if you are reading data from another plugin, all bets are off.

Of course, all bets are off anyway. Did I mention you have to measure?

* Why can't we guess? The answer is: abstraction. Basically well structured code uses libraries, functions, etc. to hide implementation and make the computer seem easier to work with. But because many challenging problems are hidden from view (which is a good thing) it's hard to know how much real work is being done inside the black box. Build a black box out of black boxes, then do it again a few time, and the information about how fast a function is has been obscured several times over!

Stutters Fixed (I Hope)

X-Plane 950 beta 1 should fix the stuttering present in 940. The bug was: the more you flew in one area, the worse the stutters would get - they'd clear out if you kept flying forward enough to scroll DSF tiles normally. Anyway, the bug was a book-keeping error based on the new "paged" airports from 940.* Fixed now - thanks to the users who got me a really clean test case to see this.

(Hint for users: if you can duplicate a scenery-related bug by saving a replay, or even if the bug can be reproduced in replay, that's really, really useful to know! It makes the bug much more repeatable, since what scenery is loaded varies a lot with flight path.)

* Before 940 we would load the entire apt.dat file into memory on startup. With Robin receiving new highly detailed airport layouts every day, this was starting to use more and more memory. 940 and 950 will load a litttle bit of information about every airport and take note of the file that contains the layout - then when the sim needs a layout, it goes back to disk to pull up just the one airport in question, saving memory. We "page" the airports into memory only as needed.

Updater Design Decisions

My blog postings have been a little thin - but not because nothing is going on. Rather it's a combination of working on next-gen stuff that is still in heavy development, travel, and (perhaps due to the travel, perhaps due to lack of sleep, or perhaps due to certain forms of Brandy brought on site by a certain British developer who won't be named, but whose handle on the org starts with a P and rhymes with "Cropsman", cough, cough) a minor fever that I've just about recovered from.

A user asked me about the design of the X-Plane updater - so this post is only going to be of interest to the few authors out there who are creating installers for their add-ons and need to update. We try to keep the file formats for X-Plane simple, e.g. "this one folder is your airplane", so that if you don't make an installer, the user won't be overwhelmed with a complex unpack-and-install routine. But if you do need to install or update, well, here's what we were thinking when we developed our installer.

We had a few needs for our installer:

• It had to be cross-platform to Mac, Windows and Linux.
• It had to update existing products as well as install new ones.
• The updates had to be minimal deltas, e.g. a demo can be 600 MB but an update should only be the 30 MB of files that really changed.
• We wanted the updater to do delta updates from any old version. (Some update systems require installing a number of patches in sequence. We have users who buy the DVD and then update a year later; we wanted to let them update in one shot.)
• Building the patches had to be really, really fast. We use our updater to publish our betas. So while X-Plane probably has 2-3 major patches in a single year and maybe 5 or 6 bug fix patches, we will (due to betas) cut perhaps 100 or more actual "updates".
• On that last point, cutting separate updates by platform was a deal breaker, as it would triple the number of updates we had to cut. Having a demo install and an update be the same on the server was a big win.

Some of those needs are pretty specific to Laminar Research, but some might apply to a third party. There are commercial installers that will let you generate patches. If you don't generate a lot of patches, you can probably use existing tools - basically you'll spend a lot less time up front (since the tool set exists) but you might spend more time in the long run cutting separate patches by OS.

One of the first things we decided was to not use server-side technology or special protocol. That is, we don't need any kind of smart servers to run the updater - the updates are just files hosted over HTTP on standard rented or owned apache servers. All of the work is done in the client. We did this for a few reasons:

• It lets us throw up the install anywhere - we don't have complex needs for what's on the server. Virtually any server will do. (As the company has grown, our server needs have grown too, so this is less of a concern now, but back then we had fewer servers in service, and were buying less overall server capacity.) If a server goes down, we can press another one into service about as quickly as we can move the file set to the server.
• We're not server programmers. Coding the installer/updater on the client side let us leverage existing company technology, etc.

Here's what we came up with. The basic idea of the installer is very simple. Note that since the installer uses HTTP files, you can "watch" the installer simply by downloading the files that it downloads.

1. First the installer goes to a master server and gets a "version list", which tells it what it's going to actually get and what (multiple) mirrors are available. This one master file is the only file that must be hosted at X-Plane.com, and it allows us to change a very small file to press mirrors into service.
2. Installs and updates are actually the same to us - it's a set of files that the user should have once the install or update finishes. This starts with a file directory that lists every file (by path) that needs to be downloaded, as well as its MD5 signature.
3. The directory also contains the MD5 of every old version of any file in the version, and lists files that have to be deleted to update the version (e.g. the file panel.png used to have MD5 signature 2934b..23abc2 but is now removed).
   
4. The client, once armed with the file directory, can now download all files in the directory (install) or compare the existing files on disk to the directory by MD5 and only download changes.
5. Individual files are on the server in zip form for download and decompression.

That's pretty much it - you could write an installer in a scripting language using a tool like CURL or WGET - it wouldn't be very complex because the installer is really just a clever, painted download+unzip tool.

Dealing With Modified Files

There is a bit of complexity in this design that you might not need for a third party installer: handling modified files. Note that the directory contains the MD5 not only of the current version of the file (to detect when no update is needed and save bandwidth) but also to see when the user has modified a file that is "managed" by X-Plane.

Before the installer overwrites/deletes a file that you own, it compares the file's MD5 to the entire known list of MD5s for the entire version. If this file doesn't match a known old version, it puts up the warning dialog box that you have modified a file that is about to be overwritten.

While we recommend that add-ons use scenery packs and other "safe" ways to customize the sim, this helps detect when a user has gone in and edited the cloud textures in Photoshop, and prevents us from overwriting them without warning.

Life Would Be Easier

Life would be easier if the Earth was a big cube.* I was reminded of this yesterday when I discovered (thanks to a bug report from an author) that X-Plane has been drawing objects with slightly incorrect heading for the last who-knows-how-long amount of time.

The bug (present in 945 and going back who-knows-how-long) is that the object's heading can be off by up to 1 full degree clockwise or counter-clockwise. (This maximum error occurs at the north pole - average error for real use cases is more likely to be about 0.35 degrees.) The amount of rotation depends on how the scenery system is shifted.

The case the author sent me was a converted scenery pack, where a pair of parallel runways were modeled partly out of draped polygons (which don't exhibit the bug), but with markings modeled as an OBJ. Depending on the scenery system's "centering" the markings would be a little bit to the left or right of the draped polygon.

A brief aside: do not model your scenery this way! A bug is a bug, and X-Plane 950 beta 1 fixes this problem, but there are a number of reasons not to use a giant OBJ to model your runways.

• OBJs do not "hug" the terrain, and the Earth is round. You will never really get clean, artifact-free flat surfaces unless they can follow the terrain contour. Even if you "flatten" the terrain, it's not flat - it's constant MSL.
• The case where I see this more often is with buildings, where authors build every single terminal building in one OBJ. X-Plane only "connects" the OBJ to the ground at one point (0,0,0 in the object). So to get a good ground connection, you need your objects to be smaller, so they can all "sit" on the ground. (Technically they need to be rotated slightly to wrap around the Earth, but for the scale of an airport this error is only about 1/30th of a degree or so - hard to see.)
• Finally, X-Plane chooses to draw or not draw an object on a whole-OBJ basis. So if you have a huge object, it's always in view (because at any one time some part of it is in view). In fact, even if the object is not in view, the larger the object, the more the "sloppiness" of the visibility check causes false positives. (The visibility check is optimized for speed, so it really answers "this object is probably in view", erring on the side of drawing too much by doing less analysis.) So the bigger your objects, the more they are drawn.

Enough ranting - in this case the scenery was the output of FS2XPlane, and the author hadn't gotten to cleaning the results. Fortunately the interim product showed the rotation bug.

X-Plane 950b1 (in beta now) fixes this problem - rotational alignment of a very large OBJ with a draped polygon should match between X-Plane (with all frames of scenery system reference) vs. WED 1.1 preview 2 pretty much exactly.

*This post is in the long and distinguished tradition of "life would be easier if" musings relating to scenery, e.g. global scenery would be easier if the entire planet was paved in asphalt, cities would be easier if their road grids only ran perfectly north-south and east-west, clouds would be easier if they weren't translucent, and rendering would be easier if nothing on the planet ever was translucent or cast a shadow. So apparently a programmer's paradise is somewhere between "Mad Max" and a Dali painting...

Airport PerformanceTip

There's a slight performance win to be had by grouping taxiways by their surface type.

Now clearly if you have to have an "interlocked" pattern of asphalt on top of concrete, on top of asphalt, this isn't an option.

But where you do have the flexibility to reorder, if you can group your work by surface type, X-Plane can sometimes cut down on the number of texture changes, which is good for framerate.

X-Plane will try to do this optimization for you, but X-Plane's determination of "independent" taxiways (taxiways whose draw order can be swapped without a visual artifact) is a bit limited and can only catch simple cases.

For what it's worth, interlocked patterns of surfaces were much more a problem with old X-Plane 6/7 type airport layouts, where the taxiways were sorted by size, and there could be hundreds of small pieces of pavement.

Why Do You Have to Tell X-Plane How Wide a Texture Is?

Some of the newer text file formats for art assets (.lin files, roads, etc.) require you to specify how wide the texture is.

Huh? Why does X-Plane need me to tell it how wide a texture is? Doesn't it know?

Well, first, the answer is: no! When X-Plane builds the roads and draped lines, the texture that is needed may not actually be loaded. It may only be on the todo list of textures that need loading, and if you have orthophoto scenery, that list could be very, very long. There is no guarantee that the texture is loaded before the geometry gets built. If you have a multicore machine, both might happen at the same time!

So the first reason why the road and .lin files require you to declare the size of your texture is: to allow X-Plane to build the mesh on a separate core from the one that loads the texture, for faster loading. Isn't multi-core fun?

There's another reason, and it's a little bit more subtle: you can change the size of your X-Plane textures. Imagine that you get a new graphics card and you decide to "upgrade" your scenery pack. So you double the size of all of your textures, and then go in to photoshop and add more detail.

But if X-Plane were to look at the size of the texture, then all of your .lin files will be wrong! For example, let's say you have a .lin file with a line from pixels 0 to 16 across the texture. When you double the size of your texture, you'd have to go in and change this to be 0 to 32 pixels across the texture.

But here's the trick: since X-Plane gets the size of the texture from you and not from the actual texture, you can just leave your .lin file the way it was - with the old texture size and the old coordinates. X-Plane will do the math out and generate correct texture mappings even though the texture size is double.

In other words, the important thing about texture coordinates is that they are self-consistent, not that they reflect the actual texture size. This is because internally all texture mapping is done in ratios.

(So why not just use ratios in the file format? Try entering the size of 10 or 12 lines as ratios and tell me whether you like it. The ability to enter the line coordinates in pixels is to make it easier to set up the line files from the image file.)

A Few More Lights

X-Plane 9 has a number of recent features to let you customize the exterior lighting of your aircraft; see the wiki for notes and a sample plane.

X-Plane 940 introduced the concept of parameterized lights to support these features. Here's the basic idea:

Named lights (available for quite a while now) let you add a light billboard to your model that we define. The idea is that since the lights are specified against a real world model (this light billboard should look roughly like a landing light) it lets us upgrade art assets and back the light with the fastest path on the graphics card.

The problem with landing lights is that they are one-size-fits all, and this is particularly problematic for airplanes, where the lights can look quite different in size and angle based on the size of the airplane. Parameterized lights fix this by letting you specify a limited number of parameters in your OBJ. By limiting the parameters that you can set, it means that we can still optimize the light when possible.

I took a few minutes today to round out the list of parameterized lights, and I think there will be 9.46 patch in which we can release them*. When we put 9.46 in beta I'll update the example plane; the new set of lights will give you parameterized control over the navigation and taxi lights, as well as the generics, beacons, strobes and landing lights.

* We have a few small bug fixes we'll roll out in 9.46.

Systems Modeling and Physics Modeling

In past blog posts I have tried to contrast two very different different approaches to simulation, which I would loosely call:

• "Predictive" (or reality-based). Input data comes from real world measurements, and the simulator predicts the expected behavior based on those inputs.
• "Prescriptive" (or specification based). The input data describes the desired output directly through preset formula.

In particular, when it comes to the flight model, X-Plane is predictive, via blade theory (X-Plane adds up all forces) while FS X is prescriptive (a table describes aircraft behavior).

But - not all of X-Plane is predictive. In particular, the "systems model", which is a loose term for the modeling of electrical systems, hydraulic systems, and a number of other parts of the plane, is actually prescriptive in X-Plane, while the aerodynamics of the plane are predictive.

To illustrate: when your plane takes off, it leaves the ground because X-Plane has calculated and summed all forces and torques on the plane and has found that it has positive lift. You don't program this in - you simply provide a number of parts that, under some conditions, influence the lift calculations. (Wings are good for this, btw! :-)

But when you turn off the avionics master switch, X-Plane does not calculate the electron flow through the wiring harness to the glass PFD. Rather, the PFD is tagged with input data saying it requires the avionics master to be on. The PFD's behavior with respect to the avionics switch is prescribed, not derived. (If we had a true "wiring editor" in Plane-Maker, it would be different - X-Plane would trace electrical routes and see if enough current makes it to the PFD.

In truth the distinction is a little bit fuzzier. For example, the gyroscopes actually do model the spin of the internal gyro (fail the vacuum system and watch them slowly pick up error like in a real plane) and the electrical system does internal current calculations. But in general the systems modeling is a bit of a mix, mostly prescriptive. This is in contrast to the physics of flight, which are completely predictive.

Why Does the Global Scenery Take 6 DVDs?

Periodically I see the question asked: why does the global scenery take up so many DVDs? Or more typically the question is: if it is so big, why is X missing, where X is the detail the user expected to see but did not find.

The size of X-Plane's global scenery is due to two factors:

1. Some aspects of the scenery are very detailed, and this takes up disk space.
2. Some aspects of the scenery are computed ahead of time, not by X-Plane, and this takes up disk space.

Big Data

A few data sources make the scenery pretty big:

• The scenery is generated from 90m SRTM data for the entire world.
• US scenery includes the entire US road grid.
• Coastline data is fairly detailed in the US and for most oceanic coasts.

In other words, part of the size of the scenery comes from having reasonably accurate topography and coastlines everywhere.

Precomputation

The other source of file size is that X-Plane precomputes aspects of the scenery to reduce load on X-Plane while you fly. (We do this to improve frame rate.) In particular, the scenery uses a class of algorithms that are expensive to compute, and thus we compute them ahead of time and save the result (using up file space).

• Land class changes not on a regular grid, but along iregular polygonal boundaries following the shape of the terrain. This produces much more natural terrain transitions in the mountain, but requires more storage.
• "Auto-Gen" forests and buildings don't follow a grid - rather, they fit into the irregular spaces made by vector roads and water. This fitting process is too slow to run inside X-Plane, so every auto-gen building and forest area must be pre-computed and saved.

Room To Grow

One interesting side effect of saving the end results of building locations ("pre-placement", what X-Plane does) rather than the formula for how to place them ("auto-gen", what FS X does) is that we can make the placement algorithm for buildings significantly smarter without any increase in file size or decrease in frame-rate. Having already eaten the cost of putting every building into the DSFs, we can make those locations better without hurting performance.

That algorithm to pre-place buildings also can have access to source data that isn't available in the final DSF, allowing for effects that might not be possible in an auto-gen system.

X-Plane Is An All You Can Eat Buffet

I have blogged in the past regarding the rendering settings in X-Plane, but this seems to come up periodically, so here we go again. Invariably someone asks the question: "what computer do I have to buy to run X-Plane with all of the sliders set to maximum?"

I now have an answer, in the form of a question: "How hungry do you have to be to clean your plate at an all-you-can-eat buffet?"

There is no amount of hungry that will ever be enough to eat all of the food at an all you can eat buffet - you can always ask for more. And when it comes to rendering settings and global scenery, X-Plane is (whenever possible) the same way. You can always set more traffic, more birds, more objects, more FSAA.

Now the all-you-can-eat buffet doesn't have infinite amounts of food in the building - just enough that they know that they won't run out. And X-Plane is the same way. There is a maximum if you set everything all the way up, but we try to make sure that no one is going to hit a point where they want more eye candy but they've maxed out the settings. Eat all you want, we've got more.

Why on earth would we set up X-Plane like this? The answer is choice.

If you go to an all you can eat buffet, you can fill up on nothing but potatos, or you can have five pieces of chicken. It's up to you. X-Plane is the same way - you decide if you want objects to be visible farther away or more densely. Would you rather have roads or trees? Birds or high frame-rate? You decide!

Not everyone's appetite is the same, and not everyone's taste is the same. This is very true when it comes to flight simulation. There are huge variations in hardware capability, target framerate (some users don't mind 20 fps, some demand 80 fps) and in what part of the visual experience people care about most (objects vs. FSAA vs. visibility distance, etc).

Given such a heterogeneous environment, the only way to meet the needs of a wide group of users is to present choice, and make sure that we have enough of everything.

So when you go to set the rendering settings, don't think that setting objects to anything less than maximum is like only eating half the steak you bought at a steak-house. Rather, the rendering settings are like picking which food from the buffet makes it to your plate. You choose how much you want based on what you can consume, and you pick and choose what is most desirable to you. And like an all you can eat buffet, don't eat too much - the results won't be pleasant!

945 Is Here

A few days ago Austin made the recently cut X-Plane 9.45 "final" - that is, it is now the version you get when you update or grab a demo. This (hopefully) ends a sequence of 940 patches that represented a mix of fixing last-minute bugs and breaking and then fixing the throttles for a few add-on airplanes.

As always, if your add-on worked in an older version 9 but is broken in 945, please let us know. I believe the compatibility situation with 9.45 is pretty good though.

Will there be a 9.46? I don't know, but I think the answer is: "probably". I found a driver bug (occurs only on OS X) we can work around a few days after 9.45 was cut. We maintain a list of fixes, and when it starts to add up, we'll cut a new patch to address them. Normally a driver bug would get a patch immediately, but from what we can tell, this one is very rare, so we're not going to fire-drill and cut a new patch 1 day after 9.45 went final.

What kinds of bug fixes make it into these "bug fix patches"? To give an example, I received a report that the "clipping" checkbox on instruments is not preserved when you export an instrument as a text file. That's the kind of thing we'll fix in a patch, but we won't cut a new patch immediately for.

DSF and WED Precision

I just finished fixing some bugs with WorldEditor and DSF precision. A WED user was seeing draped polygon tiles exporting with alignment error, and the culprit turned out to be DSF precision. This begs the question, how precise are the lat/lon coordinates in a DSF?

DSFs are based on 16-bit coordinates, for a precision of one part in 65536. Now before you go screaming that 16-bit is dreadful, here's the key: those 16-bit coordinates are interpreted within an arbitrary sub-rectangle of your tile, called a "pool". If we only had one pool covering the DSF we'd have 1.5 meter precision. But by having many smaller pools, we can have high resolution within a pool.

All of the current DSF writing tools from Laminar Research are based on DSFLib, and DSFLib will create a number of pools along a pair of offset grids. In practice what this means is that you specify a number of pools across the DSF.

In WorldEditor 1.1dp2 the DSF exporter uses 8 pools. Since a DSF is about 100 km across, each pool is 12,500 meters in size, and the internal resolution of each pool is 19 cm. This is pretty good but there are cases where you can see the limits of precision. The new code (which will be in preview 3 or beta 1) uses 32 pools, for 5 cm precision.

If you use DSF2Text, you can simply use the DIVISIONS command to specify how many pools you want.

WorldEditor's internal representation is 64-bit floating point, which gives precision better than 1 mm.

To Tune Framerate, You Have To Hit Rock Bottom

I have blogged about this before, but I keep seeing this issue come up in the forums, so I want to go over it again. If you want to effectively tune X-Plane to trade off maximum visual quality with desired framerate, you must first reduce your rendering settings all the way to the bottom, then work your way up. Let me explain with an analogy.

I have fallen off my motorcycle and hit my head, skinned my knee, and broken my arm; the bone is sticking right out of my skin! Ouch! So I go to the hospital and the Doctor examines me. Here is how the conversation goes:

Dr: How does your arm feel?
Me: My arm hurts so much! OUCH!
Dr: And how does your leg feel?
Me: My arm is burning and stinging! Please make it stop!
Dr: Do you feel dizzy or light headed?
Me: Please fix my arm!!!!!!!!

Clearly with a bone sticking through my skin, there is no point in doing a physical examination. My arm hurts so much that I can't tell the Doctor whether I have any other aches or pain. I feel one thing: the arm.

What does this have to do with framerate? Well, framerate is just like pain. The low framerate you see is caused by only the one worst problem with your setup. If your graphics card is a little bit overloaded, you are a hair short on VRAM, and your CPU is absolutely being killed, then the low framerate you see is totally because of the CPU. The weakest link decides your framerate. And like the Doctor, if we go trying to deal with the VRAM problem, we will see no change because it's the CPU that hurts the most.

This is what I see over and over: a user is running X-Plane, his framerate is bad, and he has turned some but not all of the settings down. At this point the user is usually pretty grumpy - his visuals now look bad and his framerate is poor.

The problem is that the user hasn't turned down the setting that really matters. This is why the first thing you need to do in order to tune framerate is to turn everything down, so that you are running with framerate at least as high as what you want for your target value. Then you can turn settings up one at a time and watch which one lowers framerate.

(Don't worry, you're not going to stay at the lowest settings. The key is just to always be turning settings up, not down.)

Here are some of the settings I see that need to be turned down but often are not.

• Full screen anti-aliasing. (FSAA) Always turn FSAA down to none. FSAA will kill fps on any graphics card that is fill rate limited.
• Pixel shader effects - every one of these should be turned off to start. And when you do start them, try them one at a time and have the water reflections off - work your way up in small steps. The gap from shaders without volumetric fog, shadows, reflections and per pixel lighting to shaders with all of these effects is huge!
• Turn objects all the way down to default, or even off. If your CPU is the problem, objects could be a factor.
• Leave texture compression on in your "rock bottom" settings. Texture compression improves fps and lowers visual quality, so having the check box be on is the minimal setting.
• Don't run at a huge screen res or FOV. Run 1024x768 and 50 degrees FOV.

What happens if you turn everything down and you still see 19 fps? Now it's time to investigate your video drivers and control panel settings. If your setup is even remotely better than minimum hardware, it should scream when all of those settings are turned down. If you still see low fps, check drivers, check control panel settings. There are a lot of control panel settings, for example, that will completely kill framerate.

Too Much Water Can Be a Bad Thing

In MeshTool 2.0, you can specify how wet orthophotos are handled. There are three possibilities:

1. The orthophoto has no alpha-based water. The alpha channel will be ignored.
2. The orthophoto has alpha-based water. Draw water under the alpha, but for physics, make the triangles act "solid".
3. The orthophoto has alpha-based water. Draw water under teh alpha, and for physics make the triangles act "wet".

The reason for 2 and 3 is that the X-Plane physics engine doesn't look at your alpha channel - wet/dry polygons are decided on a per triangle basis. (The typical work-around is to use the "mask" feature in MeshTool to make some parts of the orthophoto be physics-wet and some physics-solid. This is described in the MeshTool README.)

Whenever possible: don't use alpha-based water at all. It is certainly easy to set all of your orthophotos to alpha-water + physics-solid, but there are three costs to this:

1. You eat a lot of fill rate. X-Plane manages alpha=water by drawing the water underneath the entire orthophoto, then painting over it with the orthophoto. This is fill-rate expensive. If you know there is no alpha, tell MeshTool, so it can avoid creating that "under-layer" of water.
2. If the terrain is very mountainous, you may get Z-buffer artifacts from the layering, particularly for thin, spikey mountains (which probably aren't wet anyway).
3. The reflection engine tries to figure out the "surface level" of the water, but it doesn't understand the alpha channel on top of the water. So all of that water "under" your mountain or hill is going to throw the reflection engine into hysterics.

Limiting the use of water under your orthophotos fixes all three problems.

1,2,3,4,5...6,7,8,9,10,11,12

Surely I'm not the only one with that song embedded in some deep part of my psyche, right? One thing we seem to have down with 940 is counting upward...945 is in testing now.

There are two things driving the perpetual 940 bug fix releases:

1. Third parties are using the sim heavily, so the bug fix releases have been vehicles for fixing a number of small bugs that are only reproducible with custom add-ons. (The fix for night lighting and orthophotos is an example of this.)
2. We've played a real game of whac-a-mole with the throttles. (The bug is that X-Plane will lock the two throttles together. I believe that the new 945 release candidate finally fixes this.) Having done a bit of a 3 stooges routine on this bug, we've tightened up our internal procedures a bit.

As always, if your third party add-on broke with 940, please file a bug report! The only case of this I know of is the throttles bug - 945 should fix the BK-117, the Mu, and any other plane suffering from throttle-glue.

Will there be a 946? There very well might be, and I sincerely hope it will not be because 945 missed its target. But if, two months from now, we've collected another half-dozen fixes for third party authoring, I don't see why we wouldn't release them.

Could The Name Beta Be Any More Confusing?

The version number gets bumped when we have a release and it still needs patching. Of course, some bugs get reported after we ship, and some address issues not even under consideration during release. Had we not had any fire drills, we would probably still be on 942 or 943 right now, because we've had third party reports with very specialized authoring cases after we finalized the build.

Here's what makes things even more confusing: that check box "Check for new betas as well as updates" in the installer. At any one time we may have two versions of X-Plane availalbe for download:

1. The official version (currently 944) for everyone.
2. Whatever the latest in-test build is (currently 945).

(You can even see which versions are current here.) What's confusing is that while this check box says "get betas", in truth it gets any build that is "in staging". At this instant that I blog, X-Plane 9.45 final is in staging. That is, we believe 9.45 fixes our two known bugs, we think it's done, it's a release candidate, we think it is the next American Idol^H^H^H^H^H^H^H^HX-Plane. But until we certify it, you still have to check "get betas" to download it.

What we probably need to do is re-label the check-box in some way; the "staged" approach where every build is available for test first is, I think, a valuable tool to let third party authors confirm that we fixed their bugs before the entire world gets the app.

Yet Another Tools Update

A few quick notes on the various betas floating around:

• X-Plane: with the 9.4x series we are trying to fix small one-off bugs and improve stability. The BK-117's throttles will be fixed in the next beta, and we fixed a crash with a third party orthophoto scenery pack.

  This goes for any beta, but: if you have an add-on that used to work on an older build (especially 940) and it does not work, please report this immediately! There are no intentional add-on compatibility breaks in this patch.

• WorldEditor: apparently developer preview 2 doesn't contain the latest texture coordinate editor (TCE) code, so I will try to cut a preview 3 soon. The texture coordinate editor is a new small editor that lets you specify the texture placement on draped polygons. This facility lets you create custom markings. (The current TCE in preview 2 apparently doesn't have snap to grid and a few other useful features.)

  What's holding us back from a real beta? The problem is that the DSF export of draped polygons cannot split bezier curved polygons (especially with texture coordinates) across the boundaries of DSF tiles. Since I don't have an algorithm implementation for this yet, I'm not sure how soon I will be able to fix it. For now, don't try to export a DSF polygon that spans DSF tiles.

• MeshTool 2: beta 4 seems to be a keeper. I hope to cut an RC some time in the next week. (You can see the results of MeshTool 2.0 in these FranceVFR preview pics.)

500th Post

This is my 500th post. I put off posting it all week because I wanted to post something lofty and clever. But in the end, the great is the enemy of the good - if I wait until I have a really good post, it could be weeks before I have time to write a 6000 word treatise on the relationship between quantum physics, shaders, and the price of crude oil.

The decision to publish less now or more later always comes up in software release planning - once the resource budget for a project is fixed* the only choice is ship sooner with less features or later with more features.

With both X-Plane and WorldEditor we often choose "ship now with less" for a simple reason: we are going to ship with more later, but if we ship now with less as well, people get some benefit in the meantime. WED is a perfect example: the first version could only edit airports, and shipped almost 18 months ago. Had we waited until we had overlay editing and airports, we would have had a more impressive release, but authors would have had no editing at all for 18 months. Why force the people who want to edit airports to wait 18 months for overlay features?

(An assumption in this is that the cost of actually doing a release is fairly low. Obviously we don't want to do a new release every single week!)

There is a contrary force that might argue against frequent releases: once we change a feature to make it better, users are surprised if we don't make it perfect. Users assume that if we fix some bugs in a feature but not all bugs, that it's because we didn't know about the bugs we didn't fix. (The truth is usually that we had limited resources.) This produces a very strange situation where users are sometimes happier with a product that is less featureful/more deficient/more buggy because a small improvement in real functionality introduces an expectation of a large improvement.

A second behavioral phenomenon amplifies this: in my experience users consider new bugs to be significantly "buggier" (for lack of a term) than bugs that have been around for a while. This is perfectly understandable: humans are very adaptable and we get used to a bug over time to the point where we may not consider it as "bad" as when we first saw it. Trade the old bug for a new one, and we have to become re-acclimated.

These two behaviors argue (particularly when bugs and limited functionality are involved) to make a small number of large changes that move an aspect of the program from one 'stable' configuration to the next.

* If you think that more resources can break this trade-off between features and a quick release date, I strongly recommend "The Mythical Man Month". The short version: 9 women can't have a baby in 1 month - if you want a quicker release you have to do less.

Please Report Spam

I've been very busy with X-Plane feature development...when the blog is quiet, usually something interesting is getting coded. (Actually this weekend, I've just been sick in bed, so...hrm...when the blog gets quiet, perhaps I am infected.)

Just a quick note: if you see any kind of spam or vandalism on the wikis, please let me know immediately. The wiki engine we use (mediaWiki) has some fairly advanced anti-attack capabilities, but they need to be brought in when a problem occurs. Over the last two weeks I've cleaned out repeated attacks on the SDK site and one attack on the main site, and it appears that the software installed now is working.

But if more attacks come in, the next step is filting, e.g. programming the wiki to automatically reject posts based on typical off-topic keywords like certain ED drugs, etc. So if you see a post like this, please let me know - I'll kill the post and set up the anti-spam filter.

Developer Hardware

So...just how awesome is my main development machine? Not that awesome.

Periodically users ask me what my setup is. Usually the user wants to set up a really nice machine to run X-Plane at its best and figures "let's find out what the guys who write X-Plane have."

But ... my main development machine is definitely not selected to be the best possible X-Plane machine. I put together a system to:

• Debug X-Plane productively.
• Test all aspects of X-Plane.
• Create the global scenery as fast as possible.

In practice this means a Mac Pro with 8 cores, 12 GB of RAM, a lot of hard drive, and not particularly fast CPUs. It's a machine that can churn out 8 DSFs at once. There's no need for me to keep upgrading the CPU type itself - it's the 8 way parallelism that makes DSF creation fast. (To Apple's credit, the IO in the machine is fast enough to keep all 8 cores busy!)

Being an Intel Mac, the machine is triple-bootable into Vista (someone in the company has to have it) and Ubuntu Linux.

Right now I have a Radeon 4870 in the machine and an 8800 on my shelf. I do recommend the 4870 to Mac users - it's a very nice card. But for my purposes it has one annoying problem: it takes up the space for the second graphics card slot and both power connectors...I may go back to a lower powered card so I can have one NV and one ATI card in the machine at the same time - a great configuration for debugging. (I do not recommend that any user ever mix graphics card brands..."don't try this at home", etc.)

Maxing out X-Plane isn't on the priority list. In particular, past these goals, the faster the machine, the less likely I am to notice a problem.

An example: during 930 development, for some period of time, we had accidentally set the code to allocate an extra 1 GB of RAM at startup. Oops! The embarrassing part: neither Austin and I noticed for weeks. Both of our machines have plenty of RAM, and OS X has a decent VM system, so we just ran, using a lot of memory.

Then one day I try to start X-Plane on my laptop and the whole machine nearly catches on fire. Sure enough...an extra 1 GB of RAM is being grabbed.

The moral of the story: I'd rather not have a machine that hides things from me, if it doesn't affect productivity.

X-Plane on the Pre

Palm announced 3-d gaming for the Palm Pre! Some big names there...Need for Speed, Monopoly, the Sims 3, X-Plane -- hey!! Laminar Research?!?! Who let those hacks in!??

I have the original Palm Pre (not the newly announced Palm Pre Plus) and flight is quite smooth! Thanks to the Palm team for letting us in on the roll-out.

My Wife's Technology Predictions

With a new year and CES upon us, it's go time for pundits to predict the future of the technology industry. Lori considered the question of how technology might affect X-Plane and pronounced:

Pixel shaders will get shadier.

I think she is right. It is only a question of how long until they are so shady that they are basically pitch black. (At that point, I expect a significant boost in framerates!)

The 3-d Panel Is Not Always Necessary

There is no need to use the 3-d panel if you only want 3-d cockpit.

That might be the most counter-intuitive statement in the entire universe. Let's break it down and see what's going on. Originally we had the 2-D panel. The 2-D panel was where you put your instruments for interior views. When 3-d cockpit support was added, the 2-D panel was used to create the panel texture - that is, the instruments texture for the 3-D cockpit.

Thiat worked for a while, but as handles became more complex, screens became larger, and as 3-D cockpits became a more complex, authors started to run into the system's limitations. If the author wanted to create a huge panel, then the panel texture for the 3-D cockpit was huge. Furthermore, texture space for the instruments in the 3-D cockpit was wasted because the 2-D panel had to have windows on it.

With X-Plane and 9 we added the 3-D panel to fix these problems. The 3-D panel is a second panel whose sole purpose is to provide instruments as a texture for the 3-D cockpit. When you have a 2-D panel and a 3-D panel, the 2-D panel is used to draw the panel in 2-D viewing modes and 3-D panel is used only to create the panel texture for the 3-D cockpit. With this setup the 2-D panel can be huge, and the 3-D panel can be small and compact with no windows.

The 3-D panel solves a second problem as well. Often the overhead panel is drawn in perspective on the 2-D panel this perspective view is useless for texturing a true 3-D cockpit. With a 2-D panel and a 3-D panel, the author can draw the overhead in perspective for the 2-D panel, and orthographically for the 3-D panel.

Now here's where things get complicated: if an airplane has no 3-D panel the 2-D panel is used for both the 2-D view and the 3-D cockpit. But some airplanes have only a 3-D cockpit. In this case, there is no reason to use the 3-D panel at all. You can simply use the 2-D panel for texturing the 3-D cockpit and not worry about the user seeing it; in a 3-D only plane the user will only see the panel as a texture for the 3-D cockpit.

This setup is confusing in name: how can you have a 2-D panel used for a 3-D cockpits? But it is an allowed configuration. In fact, it was the only configuration allowed in X-Plane 8.

In summary: a 3-D cockpit can use the 2-D panel or 3-D panel as its panel texture. If an airplane has no 2-D panel, then the 2-D panel can be used for the 3-D cockpits without problems. In this situation and there is no need for a 3-D panel.

(It might be better to think of the 2-D panel and three panels simply add his two panels so that you can have two different versions of the panel. The names to the panel and 3-D panel are really just labels.)

Virtuosity

Happy New Year! This entire post is going to be off topic, but hopefully worth it; I will resume the usual ranting about how video cards are slowly turning our brain into string cheese later.

I think my favorite part of working for Laminar Research and being part of the X-Plane community is the friends I have made in the X-Plane community - X-Plane really does bring a great group of people together. While I lived in California, I met Jay Oliver, and actually lived not too far from him while I was in ATC school.

Here's the thing about Jay: he is a fabulous musician. In an age where music is "produced" and so much of what we hear is digitally manipulated, there's a lot to be said for listening to a human being who is simply astoundingly good with his or her instrument. It's an experience that can't be synthesized. It was always enjoyable to get a few drinks into Jay and put him down in front of the Piano and then just listen.

I've been listening to Jay's new album for a few days now, but Austin beat me to the punch, putting it on the X-Plane announce list. Jay set up his new website here, and his album is available for sale in CD or DRM-free mp3 format. You can also listen online right on the site.

Austin's usual diet is highly electronic, usually runs at about 180 beats per minute, and is the musical equivalent of shooting Jolt cola directly into your brain. What Jay does is completely different, and it's really something special.

NVidia Isn't Making Faster Humans

It's been a tough year for X-Plane authors. Key framing, manipulators, global lighting, baked lighting control, generic instruments, normal maps...version 9 has extended the possibilities for airplanes in a huge way. This is great for X-Plane users, and great for any author who wants to push the envelope, but there is a flip side: the time investment to make a "cutting edge" X-Plane aircraft has gone way, way up.

Here's the problem: as hardware has been getting faster, the amount of data (in the form of detailed airplane models) needed to keep the hardware running at max has gone up. But the process of modeling an airplane hasn't gotten any more efficient; all of that 3-d detail simply needs to be drawn, UV mapped and textured. Simply put, NVidia and ATI are making faster GPUs but not faster humans.

That's why I was so excited about order independent transparency. This is a case where new graphics hardware and nicer looking hardware means less authoring work, not more. (The misery of trying to carefully manage ordered one sided geometry will simply be replaced by enabling the effect.)

My Daddy Can Beat Up Your Daddy

Cameron was on FSBreak last week last week discussing the new CRJ...the discussion touched on a question that gets kicked around the forums a lot these days: which allows authors to more realistically simulate a particular airplane...X-Plane 9 or FSX.

This debate is, to be blunt, completely moot. Both FS X and X-Plane contain powerful enough add-on systems that an author can do pretty much anything desired, including replacing the entire host simulation engine. At that point, the question is not "which can do more" because both can do more than any group of humans will ever produce. As Cameron observed, we've reached a point where the simulator doesn't hold the author back, at least when it comes to systems modeling.

(It might be reasonable to ask: which simulator makes it easier to simulate a given aircraft, but given the tendency to replace the simulator's built-in systems on both platforms, it appears the state of the art has gone significantly past built-in sim capabilities.)

Graphic Leverage

When it comes to systems modeling, the ability to put custom code into X-Plane or FS X allows authors to go significantly beyond the scope of the original sim. When it comes to graphics, however, authors on both platforms are constrained to what the sim's native rendering engine can actually draw.

So if there's a challenge to flight simulation next year, I think it is this: for next-generation flight simulators to act as amplifiers for the art content that humans build, rather than as engines that consume it as fuel. The simulator features that get our attention next year can't just be the ability for an author to create something very nice (we're already there), rather it needs to be the ability to make what authors make look even better.

(This doesn't mean that I think that the platforms for building third party "stuff" are complete. Rather, I think it means that we have to carefully consider the amount of input labor it takes to get an output effect.)

Documentation Is Not Like Code

I find it very difficult to write good documentation for the X-Plane scenery system and tools. Not only am I not a technical writer by training and not particularly good at explaining what I am thinking in non-technical terms, but since I have been working on the scenery system for over five years, I don't really have good perspective as to what is complex and what is straightforward.

For this reason, I try to keep my ears open any time an author cannot understand the documentation, cannot find the documentation, or in another way has a problem with the scenery website. These "first experiences" give an idea of the real utility of the docs. Writing a reference for people who know things is not very hard - writing an explanation for new authors is much harder.

One author who was converting from MSFS to X-Plane pointed out a problem with the documentation that I hadn't realized before - but I think he's on to something. He pointed out that the information you need to complete a single project is often spread out all over the place. You probably need to look at an overview document, a file format, and a tool manual, each of which describes about 1/3 of the problem. To make it worse, each document assumes you know what the other ones say!

Who would write such poor documentation? A programmer, that's who. (In other words, em.) In computer programming, the following techniques are all considered good design and essential:

• Breaking a problem into smaller, sections.
• Limited cross-references between these sections as much as possible.
• Keeping the sections independent.
• Not duplicating information (code).

In other words, the docs I have written for the scenery tools are a mess because they are "well factored", a good thing for a C++ and a really useless thing for humans.

This is definitely not the only problem with the documentation, which also suffers from a lack of clarity, is often incomplete, and could use a lot more pictures. I am a programmer, and I am paid to make X-Plane faster, better, etc. It can be very hard to find the time to work on documentation when the next feature needs to be done. And yet...without documentation, who can use these features?

Now that I've at least figured out that factorization is bad, for the short term I am going to try to write "non-factored" documentation. The first test of this will be MeshTool. I am doing a complete rewrite of the MeshTool readme. Like the ac3d readme, MeshTool needs a full large-scale manual of perhaps 10-20 pages, and the task needs to be approached recognizing that the manual is going to contain a huge amount of information.

When I work on the MeshTool manual I will try to approach it from a task perspective, with explanations of the underlying scenery system, rather than a reference perspective that assumes authors might know why the given techniques work. We'll see if this creates a more usable manual.

Merry Xmas

First, Merry Christmas and seasons greetings to, well, pretty much everyone - it's been great to hear from everyone over the last week. I had a chance to poke at the scenery tools and have posted two new beta builds:

• MeshTool 2 beta 4.
• WED 1.1 developer preview 2.

You can download them both here.

MeshTool 2 beta 4 should be the last MeshTool beta short of bug fixes - that is, I've taken feature requests during the MeshTool beta, but I think we have what we need. Future feature enhancement will go in a later version.

Besides some useful bug fixes, there are two new features in this beta:

• You can specify a specific land class terrain with a shapefile.
• You can control the physical properties of orthophotos (are they wet or dry) with a shapefile without cropping out the water. This is useful for authors who want to use translucent orthophotos to create tinted water effects like coral or shallow sandy bottoms.

The WED developer preview simply puts up more bug fixes. WED isn't quite beta because of one nasty limitation: the code that exports UV-mapped bezier curves doesn't handle polygons that cross DSF boundaries. This code is going to be very difficult to get right - the combination of bezier curves, polygon cutting, and UV maps is a bit of a witches brew. Since WED isn't really complete without this, I'm not calling the build a beta.

Also a docs update: I have posted the WED and Ac3d manuals in PDF form directly on the website. The AC3D manual (and motivation to do this) are thanks to Peter, who converted the manual from readme-text to PDF. I was shocked to realize the ac3d README is almost 20 pages. Hopefully having the manual in PDF form will help people realize just how much documentation is crammed in there.

Popup Panels?

X-Plane doesn't natively and directly support popup panels, but that doesn't mean you can't pop them up. Generic instruments have a dataref-driven set of show-hide fields. (The "filters".)

Now what you might not have realized is: groups have filters too! So you can hide an entire group with one filter, and you can put premade instruments in the group.

So...even though the FMS is a premade instrument with no filter fields, by grouping it you can show and hide it.

Important: the backgrounds of instruments are not shown or hidden. So if you want to do this, customize the FMS to have a transparent background, and use a generic rotary to put a real background behind it. The rotary goes in the group, and thus it can show and hide.

One more tip: clicking in 2-d goes through one instrument to another, for historical reasons. So if you pop up an instrument, you might want to hide the instruments it popped up over so clicks don't affect them.

Custom Plugin Instruments

A quick tip to anyone using OpenGL and a plugin to make custom instruments. (The most common case of this I can imagine is customized glass displays, where it may not be practical to use 10,000 generic instruments, and the display being emulated is basically a computer display.)

OpenGL is not pixel exact, its per-primitive anti-aliasing (e.g. draw me a smooth line) is inconsistent and weird, and you probably won't have full-screen anti-aliasing on your panel. (FSAA is out of your control, as X-Plane sets up the panel render.

For this reason, I recommend "texture anti-aliasing". Basically in this technique you draw everything as rectangles, - for your lines, you use textures that have alpha at the edge. The linear intepollation of the texture forms the anti-aliased edge.*

For a detailed examination of the problem, I recommend this page. (arekkusu is a freaking genius and his treatment of the problem is very thorough!) I have also tried to explain how the hell OpenGL decides what it's going to draw here. There are a few important cases where you can be pretty sure about what OpenGL will draw, and a lot of cases where you're playing pixel roulette.

The "texture" technique also has the advantage that it leads nicely into the use of texture artwork. For example, if you need a line with an arrow-head, well, you're already drawing a line as a textured rectangle with pixels in the center and alpha on the sides. Just ask your artist to draw an arrow-head in photoshop!

* Texture FSAA actually produces better results than FSAA (with non-AA pixels). The reason is that FSAA produces a finite number of intermediate alpha levels. The number of finite levels depends on the FSAA scheme, but it is always discrete levels, hence 16x FSAA looking better than 2x. By comparison, when we use textures, we get a smooth linear blend between our transparent and opaque pixels, giving us the smoothest possible anti-aliasing.

I have two fundamental "rants" about flight simulator scenery, and the way people discuss it, market it, compare it, and evaluate it. The rants basically go like this:

• Mesh resolution (that is, the spacing between elevation points in a mesh) is a crude way to measure the quality of a mesh. It is horribly inefficient to use 5m triangles to cover a flat plateau just because you need them for some cliffs.
• At some point, the data in a very high mesh becomes misleading. You have a 5m mesh. Great! Are you measuring a 5m change in elevation, or is that a parked car that has been included in the surface?

X-Plane uses an irregular mesh to efficiently use small triangles only where they are needed. I have some pictures on this here.

But it brings up the question: how good is a mesh? If you make a base mesh with MeshTool using a 10m input DEM (the largest DEM you can use right now), the smallest triangles might be 10m. But the quality of the mesh is really determined by the mesh's "point budget" - that is, the number of points MeshTool was allowed to add to minimize error.

MeshTool beta 4 will finally provide authors with some tools to understand this: it will print out the "mesh statistics" - that is, a measure of the error between the original input DEM and the triangulation. Often the error* from using only 1/6th of the triangles from the original DEM might be as little as 1 meter.

I spent yesterday looking at the error metrics of the meshes MeshTool creates. I figured if I'm going to show everyone how much error their mesh has with a stats printout, I'd better make sure the stats aren't terrible! After some debugging, I found a few things:

• Vector features induce a lot of "error" from a metrics standpoint. Basically when you induce vector features, you limit MeshTool's ability to put vertices where the need to be to reduce meshing error. The mesh is still quite good even with vectors, but if you could see where the error is coming from, the vast majority will be at vector edges.

  For example, in San Diego the vector water is sometimes not quite in the flat part of the DEM, and the result is an artificial flattening of a water triangle that overlaps a few posts of land. If that land is fairly steep (e.g. it gains 10+ meters of elevation right off the coast) we'll pick up a case where our "worst" mesh error is 10+ meters. The standard deviation will be <>

• The whole question of how we measure error must be examined. My normal metric is "vertical" error - for a given point, how much is the elevation different. But we can also look at "distance" error: for a given point, how close is the nearest mesh point from the ideal DEM?

  "Distance" mesh point gives us lower error statistics. The reason is because when we have a steep cliff, a very slight lateral offset of a triangle results in a huge vertical error, since moving 1m to the right might drop us 20 meters down. But...do we care about this error? If the effective result is the same cliff, offset laterally by 1m, it's probably more reasonable to say we have "1m lateral error" than to say we have "20m vertical error". In other words, small lateral errors become huge vertical errors around cliffs.

  Absolute distance metrics take care of that by simply measuring the two cliff surfaces against each other at the actual orientation of the cliff. That is, cliff walls are measured laterally and the cliff floor is measured vertically. I think it's a more reasonable way to measure error. One possible exception: for a landing area, we really want to know the vertical error, because we want the plane to touch pavement at just the right time. But since airplane landing areas tend to be flat, distance measurement becomes a vertical measurement anyway.

Unnatural Terrain

So there I am working with a void-filled SRTM DEM for KSBD. I have cranked the mesh to 500,000 points to measure the error (which is very low, btw...worst error 3m and standard deviation less than 15 cm.

But what are those horziontal lines of high density mesh?

I wasn't sure what those were, but they looked way too flat and regular. So I look at the original DEM and I saw this:

Ah - there are ridges in the actual DEM. Well that's weird. What the heck could that be?

This is a view with vector data - and there you go. Those are power lines.

The problem in particular is that SRTM data is "first return" - that is, it is a measurement of the first thing the radar bounces off of from space. Thus SRTM includes trees, some large buildings, sky scrapers, and all sorts of other gunk we might not want. A mesh in a flight simulator usually represents "the ground", but using first return data means that our ground is going to have a bump any time there is something fairly large on that ground. The higher the mesh res, and the lower the mesh error, the more of this real world 3-d coverage gets burned into the mesh.

So Do We Really Care About 5m DEMs?

The answer is actually yes, yes we do, but maybe not for the most obvious reasons.

The problem with raster DEMs (that is, an elevation as a 2-d grid of heights) is that it doesn't handle cliffs very well. A raster DEM cannot, by its very format, handle a truly vertical cliff. In fact, the maximum slope it can create is based on

arctan(cliff height / DEM spacing)

Which is math to say: the tighter your DEM spacing, the higher the maximum slope we can represent for a given cliff at a certain height. Note that the total cliff height matters too, so even a crude 90m DEM like SRTM can represent a canyon if it's really huge**, but we need a very high res DEM to get shorter vertical surfaces.

So the moderated version of my rant goes something like this:

• High res DEMs input DEMs are necessary to represent small terrain features that are steep if we are using raster DEMs.
• High res meshes are not necessary - we only need res for part of the mesh where it counts.
• Let's not use mesh res to represent 3-d on the ground, only the ground itself.
  

There is another way to deal with elevation besides DEMs, and in fact it is used for LIDAR data (where the resolution is so high that a raster DEM would be unusable): you can represent a as a series of vector contour lines in 3-d. The beauty of contour lines is that they represent cliffs no matter how steep (up to vertical), and you don't need a lot of storage if the ground is not very intricate.

The meshing data format inside MeshTool could probably be made to work with contours, but I haven't seen anyone with high quality contour data yet. We'll probably support such a feature some day.

* Really this should be "the additional error", because when you get a DEM, it already has error - that is, the technique for creating the DEM will have some error vs. the real world. For example, if I remember right (and I probably do not) 90% of SRTM data points fall within 8m vertically of the real world values. So add MeshTool and you might be increasing the error from 8m to 9-10m, that is, a 12-25% increase in error.

** For the SRTM this might be a moot point - the SRTM has a maximum cliff slope in certain directions defined by the relationship between the shuttle's orbit and the latitude of the area being scanned. The maximum cliff at any point in the SRTM is 70 degrees, which can be represented by a 247 m cliff using a pair of 90m posts.

NVidia: 3 Ben: 0

This is getting embarrassing - I'm at risk of getting shut out. I was able to fix the "Null texture, how" error users were seeing on NVidia hardware.

It turns out it was an uninitialized variable in code that was never used until NV changed their drivers. As far as I can tell, NV dropped support for FSAA in 16-bit mode a few months ago, at least on some of their newer GPUs. (It is also possible that the incantation necessary to get FSAA has changed a lot and I simply don't know what it is.)

So the dialog between X-Plane and the video card ran something like the Monty Python cheese shop sketch:

X-Plane: So ... can you do full screen anti-aliasing?
GeForce 8: Oh yes, of course! (Please, I'm a GeForce 8 card.)
X-Plane: Splendid! So...how about 16x FSAA?
GeForce 8: Sorry, can't I can't do that.
X-Plane: Ah. How about 8x FSAA?
GeForce 8: Sorry, can't do that either.
X-Plane: I see. Well then, how about 4x FSAA?
GeForce 8: Nope.
X-Plane: 2x FSAA?
GeForce 8: No way.
X-Plane: Ah. I see.

At this point in the dialog X-Plane would promptly lose track of what it had been doing in the setup process, throw out its notes on the GPU setup, and then freakout a bit later when it realized its note taking left something to be desired.

This is the first case I've hit where a video card advertises FSAA and can't actually do it.

Anyway, if you have hit this bug:

1. Update to 941 final - it should fix it.

2. Stop trying to run with FSAA and 16-bit color. This is a somewhat crazy combination. FSAA attempts to clean up rendering artifacts at the cost of fill rate. 16-bit color creates artifacts to save fill rate. If your GPU needs 16-bit color to run at high framerate, it's time to turn FSAA off.

(I realize that 16-bit color and aliasing are different kinds of artifacts, and some users might prefer harsh color transitions to harsh polygon transitions. But I still say, go for 32-bit color, no FSAA. When the sim is running in 16-bit mode, a good chunk of the sim still runs in 32-bit mode because 16-bit RGB surfaces only have 1 bit of alpha.* So you're not quite getting universal savings but you get 16-bit output colors, so the results look universally bad.)

*This assumes 5551, or 565 pixels. There is a 4-bit alpha 16-bit color format, cleverly called 4444, but if you thought 16-bit looks bad...

Why Do Custom Lights Use the Object Texture?

I am trying to be disciplined and put documentation on the X-Plane wiki, and limit the blog to announcements, rants, and explanations of what's going on inside X-Plane.

You can read about custom lights here. The short of it is that a custom light is a billboard on an object where you (the author) texture the billboard (with part of the object texture), pick the texture coordinates and color, and optionally run all of these parameters through a dataref* that can modify them.

For named lights, the light texture comes from a texture atlas that Sergio made a few years ago - it's a nice grid 8x8 pretty lights.

So...why can't you use it with custom lights? Why do custom lights use the object texture?

The answer is: future compatibility. Sergio and I are actually already working on a new texture atlas for the sim's built-in lights. (This has been a back-burner project for a while ... I have no idea when we'll actually productize this currently experimental work.) What happens when we create a new texture atlas with all of the lights moved around and scrambled? If your object referenced that texture, the texture coordinates would be incorrect.

Thus, for the lights where you specify texture coordinates (custom lights) you use your own texture. For named lights (where the texture coordinate is generated by X-Plane) it's safe to use ours.

A Dangerous Bug

I found a bug in 940 that's been in the sim for a while now: given the right strange combination of named and custom lights in a row, the sim would accidentally use Sergio's texture atlas rather than the object's texture for custom lights.

This is a mistake, a bug, and it will be fixed in the next 941 release candidate. I certainly hope there aren't any objects out there relying on this erroneous behavior, which violates the OBJ spec and is pretty dangerous from a future compatibility standpoint.

* Dataresfs are normally thought of as data we read, so the idea of using them to "process" data is a bit of a bastardization of the original abstraction. You can read about the dataref scheme in detail here.

Is Your Video Card "Two Steps Down"

Identifying an underpowered video card is difficult. Video cards have simple, non-confusing names like the CryoTek GeForce FX 9999 XYZ. What the heck does all that stuff mean?

(The lists below will contain a number of "specs". Do not panic! At the end I will show you where to look this stuff up on Wikipedia.)

A modern graphics card is basically a computer on a board, and such, it has the following components that you might care about for performance:

• VRAM. This is one of the simplest ones to understand. VRAM is the RAM on the graphics card itself. VRAM affects performance in a fairly binary way - either you have enough or your framerate goes way down. You can always get by with less by turning texture resolution down, but of course then X-Plane looks a lot worse.

  How much VRAM do you need? It depends on how many add-ons you use. I'd get at least 256 MB - VRAM has become fairly cheap. You might want a lot more if you use a lot of add-ons with detailed textures. But don't expect adding more VRAM to improve framerate - you're just avoiding a shortage-induced fog-fest here.

• Graphics Bus. The GPU is connected to your computer by the graphics bus, and if that connection isn't fast enough, it slows everything down. But this isn't really a huge factor in picking a GPU, because your graphics bus is part of your motherboard . You need to buy a GPU that matches your motherboard, and the GPU will slow down if it has to.

• Memory Bus. This is one that gets overlooked - a GPU is connected to its own internal memory (VRAM) by a memory bus, and that memory bus controls how fast the GPU can really go. If the GPU can't suck data from VRAM fast enough, you'll have a slow-down.

  Evaluating the quality of the internal memory bus of a graphics card is beyond what I can provide as "buying advice". Fortunately, the speed of the bus is usually paired with the speed of the GPU itself. That is, you don't usually need to worry that the GPU was really fast but its bus was too slow. So what we need to do is pick a GPU, and the bus that comes with it should be decent.

• Of course the GPU sits on the graphics card. The GPU is the "CPU" of the graphics card, and is a complex enough subject to start a new bullet list. (As if I wouldn't start a new bullet list just because I can.)

So to summarize, you want to look at how much VRAM your card has and make sure the bus interface matches your motherboard. What about the GPU? There are three things to pay attention to on a GPU:

• Generation. Each generation of GPUs is superior to the previous generation. Usually the GPUs can create new effects, and often they can create old effects more cheaply.

  The generation is usually specified in the leading number, E.g. a GeForce 7xxx is from the GeForce 7 series, and the GeForce 8xxx is from the GeForce 8 series. You almost never want to buy a last-generation GPU if you can get a current generation GPU for similar price.

• Clock Speed. A GPU has an internal clock, and faster is better. The benefit of clock speed is linear - that is, if you have the same GPU at 450 mhz and 600 mhz, the 600 mhz one will provide about 33% more throughput , usually.

  Most of the time, the clock speed differences are represented by that ridiculous alphabet soup of letters at the end of the card. So for example, the difference between A GeForce 7900 GT and a GeForce 7900 GTO is clock speed - the GT runs at 450 mhz and the GTO at 650 mhz.*

• Core Configuration. This is where things get tricky. For any given generation, the different card models will have some of their pixel shaders removed. This is called "core configuration". Basically GPUs are fast because they have more than one of all of the parts they need to draw (pixel shaders, etc.) and in computer graphics, many hands make light work. The core configuration is a measure of just how many hands your graphics card has.

  Core configuration usually varies with the model number, e.g. an 8800 has 96-128 shaders, whereas an 8600 has 32 shaders, and an 8500 has 16 shaders. In some cases the suffix matters too.

How would you ever know your core configuration, clock speed, etc.? Fortunately Wikipedia is the source of all knowledge. Here are the tables for NVidia and ATI.

Important: You cannot compare clock speed or core configuration between different generations of GPU or different vendors! A 16-shader 400 mhz GeForce 6 series is not the same as a 16-shader 400 mhz GeForce 7 series card. The GPU designers make serious changes to the card capabilities between generations, so the stats don't apply.

You can see this in the core configuration column - the number of different parts they measure changes! For example, starting with the GeForce 8, NVidia gave up on vertex shaders entirely and started building "unified shaders". Apples to oranges...

Don't Be Two Steps Down

This is my rule of thumb for buying a graphics card: don't be two steps down. Here's what I mean:

The most expensive, fanciest cards for a given generation will have the most shaders in their core config, and represent the fastest that generation of GPU will ever be. The lower models then have significantly less shaders.

Behind the scenes, what happens (more or less) is: NVidia and ATI test all of their chips. If all 128 shaders on a GeForce 8 GPU work, the GPU is labeled "GeForce 8800" and you pay top dollar. But what if there are defects and only some of the shaders work? No problem. NV disables the broken shaders - in fact, they disable so many shaders that you only have 32 and a "GeForce 8600" is born.

Believe me: this is a good thing. This is a huge improvement over the old days when low-end GPUs were totally separate designs and couldn't even run the same effects. (Anyone remember the GeForce 4 Ti and Mx?) Having "partial yield" on a chip set is a normal part of microchip design; being able to recycle partially effective chips means NV and ATI can sell more of the chips they create, and thus it brings the cost of goods down. We wouldn't be able to get a low end card so cheaply if they couldn't reuse the high-end parts.

But here's the rub: some of these low end cards are not meant for X-Plane users, and if you end up with one, your framerate will suffer. Many hands make light work when rendering a frame. I you have too few shaders, it's not enough hands, drawing takes forever, your framerate suffers.

For a long time the X-Plane community was insulated from this, because X-Plane didn't push a lot of work to the GPU. But this has changed over the version 9 run - some of those options, like reflective water, per-pixel lighting, etc. start to finally put some work on the GPU, hitting framerate. If you have a GeForce 8300 GS, you do not have a good graphics card. But you might not have realized it until you had the rendering options to really test it out.

So, "two steps down". My buying advice is: do not buy a card where the core configuration has been cut down more than once. In the GeForce 8 series, you'll see the 8800 with 96-128 shaders, then the first "cut" is the 8600 with 32 shaders, and then the 8500 brings us down to 16.

A GeForce 8800 was a good card. The 8600 was decent for the money. But the 8500 is simply underpowered.

When you look at prices, I think you'll find the cost savings to be "two steps down" is not a lot of money. But the performance hit can be quite significant. Remember, the lowest end cards are being targeted at users who will check their email, watch some web videos, and that's about it. The cards are powerful enough to run the operating sytem's window manager effects, but they're not meant to run a flight simulator with all of the options turned on.

If you do have a "two step" card, the following things can help reduce GPU load:

• Turn down or off full screen anti-aliasing.
• Turn off per pixel lighting, or even turn off shaders entirely.
• Reduce screen size.
  

* GT = Good Times, GTO = Good Times Overclocked? Only NVidia knows for sure...

Why Isn't SLI/CrossFire A No-Brainer?

To get this out: I have no idea if/whether/how much SLI or Crossfire improve or hinder X-Plane's framerate. None of my development systems have such hardware, and I spend no time either optimizing for SLI/CrossFire or testing. If you have done tests with SLI enabled and disabled, I would like to know the results!

I have read the white papers on how to optimize an application for SLI/CrossFire, and while X-Plane isn't quite a laundry of SLI/CrossFire sins, we're definitely an application that has the potential for optimization.

Now normally more hardware = faster framerate. In particular, the limiting factor of filling in a big display with high shader options and full screen anti-aliasing can be the time it takes to fill in pixels, and more shaders mean more pixels filled in at once.* Why doesn't having an entire second GPU to fill in pixels allow us to go twice as fast?

The answer is: coordination. Normally the process of drawing an X-Plane frame goes a little bit like this:

1. Draw a little bit more of the cloud shadows into the cloud shadow texture. (This is a gradual process.)
   
2. Draw the panel into the panel texture.
3. Draw the world (as seen from below the water) into the water reflection texture.
4. Draw the airplane shadow into the airplane shadow texture.
5. Draw the entire world using the above four textures.

Notice a trend? Those four textures are dynamic textures, meaning they are created by the viedo card drawing into its own texture, once per frame. Dynamic textures are generally a good thing, because they let us create texture content much more rapidly than we could with the CPU. (There is no way we could prepare the panel texture once per frame if we had to do it on the CPU.)

In fact, the total dynamic textures can be more so - if you use panel regions, there are 2 panel textures per region, and if you use volumetric fog, there are two more textures with interim renderings of the world, used to create fog effects.

Okay, so we have a lot of textures we drew. What does that have to do with multiple video cards?

Well, one reason why dynamic textures are normally fast is because, when a dynamic texture is finished, it lives exactly where we want it to live: on the video card!

But...what if there are two video cards? Uh oh. Now maybe one video card drew the water, and another drew the clouds. We have to copy those textures to every video card that will help draw the final frame.

There is a sequence to draw the right textures on the right card at the right time to make X-Plane run faster with two video cards...but the video drivers that manage SLI or CrossFire may have no way to know what that sequence is. The driver has to make some guesses, and if it puts the wrong textures in the wrong places, framerate may be slower, due to the overhead of shuffling textures around.

So SLI and CrossFire are not simple, no-brainer ways to get more framerate, the way having a faster GPU might be.

* If you have a huge number of objects, your framerate is suffering due to the CPU being overloaded, and this is all entirely moot!

No Raster Land Use Data

The X-Plane version 8/9 default scenery uses raster land use data (that is, a low-res grid that categorizes the overall usage of a square area of land) as part of its input in generating the global scenery. When you use MeshTool, this raster data comes in the .xes file that you must download. So...why can't you change it?

The short answer is: you could change it, but the results would be so unsatisfying that it's probably not worth adding the feature.

The global scenery is using GLCC land use data - it's a 1 km data set with about 100 types of land class based on the OGE2 spec.

Now here's the thing: the data sucks.

That's a little harsh, and I am sure the researchers tried hard to create the data set. But using the data set directly in a flight simulator is immensely problematic:

1. With 1 km spatial resolution (and some alignment error) the data is not particularly precise in where it puts features.
2. The categorizations are inaccurate. The data is derived from thermal imagery, and it is easily fooled by mixed-use land. For example, mixing suburban houses into trees will result in a new forest categorization, because of the heat from the houses.
3. The data can produce crazy results: cities on top of mountains, water running up steep slopes, etc.

That's where Sergio and I come in. During the development of the v8 and v9 global scenery, Sergio created a rule set and I created processing algorithms - combined together, this system picks a terrain type from several factors: climate, land use, but also slope, elevation, etc.

To give a trivial example, the placement of rock cliffs is based on the steepness of terrain, and overrides land use. So if we have a city on an 80 degree incline, our rule set says "you can't have a city that slanted - put a rock face there instead."

Sergio made something on the order of 1800 rules. (No one said he isn't thorough!!) And when we were done, we realized that we barely use landuse.

In developing the rule set, Sergio looked for the parameters that would best predict the real look of the terrain. And what he found was that climate and slope are much better predictors of land use than the actual land use data. If you didn't realize that we were ignoring the input data, well, that speaks to the quality of his rule set.

No One Is Listening

Now back to MeshTool. MeshTool uses the rule set Sergio developed to pick terrain when you have an area tagged as terrain_Natural. If you were to change the land use data, 80% of your land would ignore your markings because the ruleset is based on many other factors besides landuse. Simply put, no one would be listening.

(We could try some experiments with customizing the land use data..there is a very small number of land uses that are keyed into the rule set. My guess is that this would be a very indirect and thus frustrating way to work, e.g. "I said city goes here, why is it not there?")

The Future

I am working with alpilotx - he is producing a next-gen land-use data set, and it's an entirely different world from the raw GLCC that Sergio and I had a few years ago. Alpilotx's data set is high res, extremely accurate, and carefully combined and processed from several modern, high quality sources.

This of course means the rules have to change, and that's the challenge we are looking at now - how much do we trust the new landuse vs. some of the other indicators that proved to be reliable.

Someday MeshTool may use this new landuse data and a new ruleset that follows it. At that point it could make sense to allow MeshTool to accept raster landuse data replacements. But for now I think it would be an exercise in frustration.

What Exactly Is a Generic Light?

X-Plane 940 has these generic light things...what the heck are they? Here's the story:

X-Plane has been growing a larger number of independently simulated landing lights with each patch. We started with one, then four, now we're up to sixteen. Basically each landing light is a set of datarefs that the systems code monitors.

• You use a generic instrument to hook a panel switch up to a landing light dataref.
• The sim takes care of matching the landing light brightness with the switch depending on the electrical system status.
  
• Named lights can be used to visualize the landing lights.

See here for more info.

But what else lights up on an airplane? Sergio sent me the exterior lighting diagram for an MD-82, and it would make a Christmas tree blush. There are lights for the staircases, for the inlets, on the wings, pointing at the wings, the logo lights, the list goes on.

We have sixteen landing lights, so we could probably "borrow" a few to make inlet lights, logo lights, etc. But if we do that, the landing light will light up the runway when we turn on any of those other random lights.

Thus, generic lights were born. A generic light is a light on the plane that can be used for any purpose you want. They aren't destined for a specific function like the strobes and nav lights. There are 64 of them, so divide them up and use them how you want. Just like landing lights, you use a generic light by:

• Using a generic instrument to control its "switch" from the panel.
• Using a named light to visualize it somewhere on the OBJs attached to your airplane.

Generic lights don't cast any light on any other part of the plane - sorry. You can use ATTR_lit_level to light up part of your mesh dynamically when the generic light comes on though - the effect can be convincing if carefully authored.

MeshTool, Water and Land Class

MeshTool 2.0 is still a very new tool, so it shouldn't be surprising that it has grown quite a few features during beta. I am putting three new features in for beta 4 that should help round out the kinds of things an author can put into a mesh.

Land Class Terrain

The next beta will allow authors to specify built-in land-class terrains by shapefile. Landclass isn't quite as easy to work with as you might think - I'm working on a Wiki page describing how land class works with the mesh.

You can't invent your own land classes directly in MeshTool, but there are two work-arounds:

1. Once you build your DSF, use DSF2Text to edit the header, changing one of our land classes to the one you want. We have 500 + land classes, so you can probably find one to cannibalize.
2. Or you can just use the library system to replace the art assets for the land class within the area covered by your mesh. (You can tweak as little as one full tile.)

Water Handling and Masking

Water handling and masking go together to allow you to create an accurate physical coastline. The problem is that X-Plane doesn't let you specify whether a tile is land or water using a texture/image file. Physics are always determined on a per-triangle basis.

MeshTool 2.0 beta 4 will let you specify whether the physics of an orthophoto that has water "under" its transparent areas will take on its own physics, or the physics of the underlying water. (It can act "solid" or "wet".) This lets you use orthophotos to model shallow areas and reefs.

The mask feature lets you do both. The mask feature lets you limit MeshTool to working on a single area vector area, defined by a ShapeFile. So to make a single orthophoto have wet and solid parts you:

1. Issue the orthophoto command in solid mode.
2. Establish a shapefile mask for areas of your DSF.
3. Re-issue the orthophoto in "wet" mode.

The second orthophoto command will replace the first only in the wet areas, giving you regions with both types of physics. The README for MeshTool will cover this in more detail.

No Z Yet

Some developers have requested that MeshTool use the Z coordinate in a Shapefile to define the elevation of water boundaries. That's a good idea, but I can't code it any time soon. The polygon processing in MeshTool is fundamentally 2-d and has no way to retain the Z information during processing. I will try to get to this feature some day, but for now it's going to have to wait.

The new beta should be available some time early next week, or now if you build from source.

I Accidentally Documented Something

Normally I try to make the X-Plane scenery and modeling system as opaque as possible -- I want to make sure that nobody ever actually uses the rendering features that I spend weeks and weeks developing.

But the other night I had a little bit too much to drink, got distracted, and posted these:

• http://wiki.x-plane.com/Custom_Prop_Discs
• http://wiki.x-plane.com/Exterior_Aircraft_Lighting

In all seriousness, I have been trying to find time to put more documentation up on the Wiki. For these features, you will find an explanation of how the planes work, as well as a link to the planes (with plugins) to download, and a link to the plugin source code (on the SDK site, with sample makefiles for 3 operating systems).

Plugins? Do not panic! While plugins are necessary for some of the features demonstrated here, others can be created without additional programming.

BTW, if the existing documentation uses a concept that is not explained anywhere, please email me. I sometimes leave holes in the documentation by accident.

Have You Hugged Your Driver Writer Lately?

In my contact with users, on X-Plane forums, in discussions of computer graphics, video drivers are an easy punching bad. When an app doesn't work, blame the video driver. The guys at NV and ATI don't have time to respond to every ridiculous allegation that is posted. Sometimes drivers are borked, but when it turns out to be X-Plane I try to set the record straight.

Driver writers have what might be the hardest combination of programming circumstances:

1. Their code cannot crash or barf. X-Plane crashes, you send me some hate email. Your video driver crashes, you can't see to send me that email.
2. The driver has to be fast . The whole point of buyng that new GeForce 600000 GTX TurboPower with HyperCache was faster framerates. If the driver isn't absolutely optimized for speed, that hardware can't do its thing.
3. The driver writers don't have a lot of time to be fast and correct - the GeForce 700000 GTX TurboPower II will HyperCache Pro will be out 18 months from now, and they'll have to start all over again.

That's not an easy set of goals to meet. Today's video cards are basically computers on a PCIe board, and they do amazing things, but they do it thanks to a fairly complex piece of software.

Applications writers like myself get to outsource the lower level aspects of our rendering engine to driver writers. When a driver doesn't work right, it's frustrating, but when a driver does work right, it's doing some amazing things.

Don't Lie To X-Plane

Well, I won't stop you from lying to X-Plane, but if you do, your add-on may have problems in the future.

Basically: some parts of X-Plane take measurements of real world information and attempt to simulate them. I have previously referred to this as "reality-based" simulation (e.g. the goal is to match real world quantities).

In those situations, if you intentionally fudge the values to get a particular behavior on this particular current version of X-Plane, it's quite possible that the fudge will make things worse, not better in the future.

This came up on the dev list with the discussion of inside vs. outside lighting. X-Plane 9 gives you 3 global lights for objects in the aircraft marked "interior", but none for the exterior.

Now there is a simple trick if you want global lights on the exterior: mark your exterior fuselage as "interior" and use the lights.

The problem is: you've misled X-Plane. The sim now thinks your fuselage is part of the inside of the plane.

This might seem okay now, but in the future X-Plane's way of drawing the interior and exterior of the plane might change. If it does, the mislabeled parts could create artifacts.

So as a developer you have a trade-off:

• Tweak the sim to maximize the quality of your add-on now, but risk having to update it later.
• Use only the official capabilities of the sim now, and have your add-on work without modification later.