The Dangers of Wandering in the Desert

I have been trying to put documentation on the X-Plane Wiki, and use this blog for announcements and "the inside story", rather than letting the blog turn into a poor-man's users manual. An aircraft developer asked me via email whether there was a blog entry on some of the pitfalls of the v9 panel lighting system. There is not, and the lighting system is under-documented. I will be working on improving the documents over the next few weeks, but the point of this blog entry is: "how did we get here?"

I am a huge fan of incremental software improvement. That's the subject of another blog post (perhaps on another blog), but for now I'll say this: all changes to the rendering engine since version 8.0 have been incremental ones, and yet if you were to look at the code, you wouldn't see a series of band-aids taped on top of each other. Each incremental change leaves the rendering code "fully updated", as if it had been written yesterday. I start each new scenery feature by first reshaping the existing code into the most useful form for what we want to have in the future, and then coding the new feature is relatively simple.

But this strategy has an Achilles heal; if the code being refactored has a public interface (whether it is a file format or programming API), then all of the intermediate steps in the journey become requirements for future products in order to maintain backward compatibility.

This is not a problem as long as the programmer knows where he is going. The danger comes when one of the intermediate steps is actually a step in the wrong direction, and becomes dead weight around a future design.

A Reasonable Progression: OBJ

The OBJ 800 file format has had a reasonable progression* since its birth in version 8. It has gained a number of new features, but each one has generalized and made more powerful previous ideas, such that "legacy behaviors" are not so painful. Some examples:

• Hard surfaces may now be decks (e.g. you can fly under them) or not, and you can specify what kind of hard surface you have. The original hard surface command was simply "it's hard" or "it's not". But viewed under the lense of the new scenery system, that old hard surface command implicitly implied "the surface is smooth" and "the hard surface is not a deck". So the new hard surface command is a more general version of the old one, which continues to work under the new system.
• Animations in version 9 can be key framed; in version 8 you simply specify start and end values. But start and end values are just like having two key frames. So viewed under the lense of the new scenery system, all animations are key framed; older objects always just have two key frames. The new key framed commands are a more powerful, more general version of the old ones.

I can't say that the relatively pain-free evolution of OBJ files over the last 4 years comes from good design or genius on my part - in truth it's probably just good luck. But I think one thing has helped me keep the new OBJ extensions relatively sane: most of them are conceived several months before they make it into X-Plane.

I have a scenery system to-do list that will last me at least another four years; most of it is filled with things that Sergio has asked for. This to-do list acts as sort of a road map for future scenery system extensions; for any possible OBJ change, I can look at it relative to the other todo items and ask: "is this extension going to play nicely with things to come?"

(As a side note, this is one of the reasons why there are not light maps in any of the X-Plane modeling formats. Light maps don't play well with a number of other scenery system extensions. I want to resolve the conflict between these future additions before they go into the sim.)

Wandering In the Desert

By comparison, the evolution of the panel system in version 9 has been more like wandering in the desert than a straight line toward a goal. Repeatedly, I put features into the panel system without a clear roadmap of where we would end up or how they would work together. The result is what you see now when looking over the panel documents: complexity and chaos.

Basically there are several major changes to the panel system that affect each other in strange ways:

1. A more complex lighting model on the 2-d panel in version 920. (That is, the 3 2-d spot lights, and generic instruments with back-lit, mechanical, or glass lighting.)
2. A more complex lighting model in the 3-d cockpit in version 930. (That is, 3-d spot lights, ATTR_cocpkit_region and generic instruments with back-lit, mechanical, or glass lighting.)
3. A separate panel used only to provide texture to the 3-d cockpit. (That is, the 3-d panel.)
   

The problem is the order that they were invented: first ATTR_cockpit_region, then the 3-d cockpit, then back-lit generic instruments, then 2-d spot lights, and then 3-d spot lights.

The result is two sources of confusion:

• Some combinations of features simply don't work together. Since all of the features appear to be independent, I sometimes get bug reports on these. For example, you can't use the 2-d spot lights on the 3-d panel. This is not a bug, it is by design! I will explain why some of these limits exist in future blog posts.
• Among the remaining combinations that do work together, there are a lot of choices about how to structure a plane - too many choices!

This second point is a tricky one: X-Plane has to continue to support whatever set of features was available for any given release (864, 900, 920, 930) so that older planes continue to work. But some of those combinations (e.g. the ones that exist in version 900) don't make a lot of sense for new planes made in 930.

I am open to ideas on how to solve this. I intend to document a "correct formula" for a modern plane, perhaps with tutorials, on the Wiki. I am also considering programming Plane-Maker to flag unusual combinations of features as a warning when saving 930 planes.

Either way, I fear I've learned my lesson from the panel system: incremental improvement of code is only a good idea if the programmer knows where he is going! Next time I will use Google Maps. :-)

* I suppose that whether you think the OBJ 800's evolution has been reasonable depends on your standards for file formats. OBJ 800 absolutely does show growing pains. I would only say: consider the number of revisions and the change in the hardware platform OBJ 800 feeds when you consider its stretch marks.

Scripting: A Line In the Sand

I thought I had already blogged about this, but I can't find the old posts, so here goes. The big question: why can't we have "X" in the OBJ file format or as part of generic instruments?

I get a lot of requests for "more power" in the OBJ or generic instrument system - the ability to play sounds, to do simple math operations on datarefs, more show-hide filters, the ability for a generic instrument to change a dataref in response to another dataref instead of a mouse click.

And invariably I say "No! Go write a plugin!", which I realize is a fairly rude thing to say to a non-programmer. First, let me explain why I say no, and then what we can do about this.

Keeping Systems Separate

These feature requests fall into two broad categories: "systems programming", which is really anything that has a side effect (play a sound, change a dataref, apply some logic), and "visualization" (e.g. a user needs more flexibility to better visualize the sim's state.

I definitely do not want any kind of "systems modeling" code inside OBJs or generic instruments. To give a trivial example: imagine that you could make a generic instrument that would set the generators to on when the landing gear is raised.

What then happens if this generic instrument is off the bottom of the screen when the landing gear is raised? Does the generic instrument get to perform its logic? Both OBJs and generic instruments are fundamentally "visualization" systems - both will short-circuit for performance when they are not visible. If we put systems modeling code into them, then the sim has to evaluate a potentially large number of otherwise unimportant (non-visible) objects and instruments to do system behaviors.

In computer programming, there is the notion of a "model-view-controller" design. The basic idea is to keep the code that changes the model, the model itself, and the code that lets the user see the data model, all separate. Keeping them separate keeps operation consistent - the model does not change its behavior depending on how you look at it, which is very important for consistent simulation.

So for all systems modeling, my answer is always the same: not in viewing code!

Expressions and Visualization

Some requests are simply requests for more visualization complexity - there is only so much you can do with key frames, animation, and a few filters.

I do have to admit that on some level, it is perfectly reasonable to ask for infinite power to visualize data in OBJs and generic instruments.

On the other hand, there would be a real cost to having programming-language complexity in what are otherwise relatively simple-to-use parts of X-Plane (e.g. the simplest model is just an export from ac3d...). My solution for both problems (systems and visualization) is a scripting system, but in the case of visualization, it is about not reinventing the wheel and keeping complexity limited to one place (the scripting system).

Scripting

Plugins have the power to solve all of these problems - they can change almost any aspect of the sim. But they are also very difficult to create; you need to be a programmer who knows a language like C or Pascal, and you need to know how to use the development tool for each platform you want to support. That's a huge amount of specialized knowledge just to customize a few systems.

Basically we need to have a line in the sand. At some point, when the systems to visualize information (OBJ, generic instruments) are not powerful enough, we need to make programming easier, rather than make modeling and authoring more complex.

What we need is a scripting system. The scripting system would provide a relatively simple text-file syntax to do simple scripting of systems and instruments for airplanes.

Such a scripting system should be implemented as an open source plugin; it should not be built into X-Plane. The advantage of this would be:

• Anyone could improve or add features to such a scripting system, not just Austin and myself.
• People could freely customize the scripting system as needed for specific projects.
• By having the code be part of a plugin and not the sim, backward compatibility would be improved - even if the "official" version of the scripting plugin changed, you could always include an older version with your plane that worked exactly the way you want.

Who should work on this scripting system? I don't know. Probably not me -- I am not very good at making simple systems; see also what a complex disaster the panel and instrument system has become!

When a user requests that I add a feature to the generic instrument system, there is an implicit request - that Austin or I take programming time to do the feature. So for now I can only say that if/when I take time to do some of these feature requests, it will be in the form of a scripting system, not as extensions to the generic instrument and OBJ systems. This will give us better long-term compatibility and extensibility (via an open source plugin) and will keep systems modeling code separate from the visualization system.

X-Plane 930 Beta

X-Plane 930 has a lot in it - I will try to cover some of the details of the new features soon, but some immediate thoughts:

• X-Plane betas are open to anyone who wants to participate. You don't have to sign up, you don't have to be approved.
• If you would not be happy with a buggy, broken, weird, freaked out version of X-Plane, do not get the beta! Just wait and enjoy 922 - when 930 is debugged, it will be free for everyone.
• If you make a third party add-on for X-Plane and 930 breaks it...report it, don't fix it! Give us a simple report about how your add-on used to work in 922 and is hosed in 930, and show us where to get the add-on. None of the new features in 930 should break 922 content. Pretty much all of them do nothing until you choose to use them.
• If you make a third party add-on, get on the new betas early; the earlier you report it, the earlier we can fix it.
• Don't release third party add-ons for 930 until 930 goes final. Until 930 is final, all datarefs, SDK features, etc. are subject to change.
• Keep a copy of 922 around if you want to fly during early betas.
• Don't use early 930 betas on critical files - make backup copies!

The first few betas are usually pretty rough...the main reason is that Laminar Research is a small company, and therefore we have a small number of computers; even though I have five machines in my office now (and I think 12 operating systems) there are plenty of combinations of software, hardware and drivers that our users have that we don't have.

So if you try the beta and it just blows up...don't panic! Report a bug, and we'll try to get it working for your machine. The pixel shaders and low level video driver setup code have changed, which means working out the kinks on every hardware configuration out there. (Programmers sometimes call this "write once, debug everywhere".)

With that in mind, there's a lot of cool stuff in 930. Better 2-d panel filtering and per-pixel lighting should make the sim look better for just about everyone; other features like 3-d cockpit lighting will be of interest to airplane authors. I will be updating the X-Plane wiki to document how to use some of these new features over the next few days.

Catalyst Drivers - Get 9-1

A number of users have confirmed that the new ATI Catalyst 9-1 drivers fix the artifacts introduced with the 8-12 drivers!  No need to stay back on the 8-11  drivers any more.

It's nice to have this bug fixed - long time X-Plane users saw this as soon as they updated from 8-11 to 8-12 - they updated drivers and the sim got weird looking, so they just rolled their drivers back.

But a number of MSFS users have tried the X-Plane demo for the first time using 8-12 drivers and wondered how we could ship such a lousy product.  The key, of course, is that MSFS uses DirectX drivers, while X-Plane uses OpenGL drivers, so the 8-12 drivers affected X-Plane but not MSFS.

I've been poking at the FRAMEBUFFER_INCOMPLETE messages that some people get.  The best I have so far is: run with --no_fbos and --no_glsl (learn how here).  If you get this card and you have 2 GB of RAM, consider turning your rendering settings down a bit.

And 930?  I got my last beta stopper fixed today, so it's time for a scotch!  I'll post more on the beta tomorrow.

Stuff I'm Looking At

I'm always a little bit nervous about posting grand new initiatives ... if we don't actually do the initiative, invariably someone comes out of the walls later to say that we "promised" a feature that we didn't do. But road maps are important. So, bearing in mind that this is not an official announcement, and that nothing has been decided yet, here are some areas of active investigation:

• An airport art asset library. Sergio already started this process by making some aircraft OBJs and other elements (like custom pavement types) available in the libraries that ship with X-Plane. We are looking at extending this over time to include more useful elements for building airports.
• Sharing airport building placements the way we do airport layouts. Right now, airport layouts are shared in a communal database under the GPL license. An airport building database would work the same way - it would be a collection of placements of airport buildings, GPLed and redistributed with X-Plane. The idea would be to make it easy for people to add simple buildings to their local airport and share the results with everyone.
• Using OpenStreetMap (OSM) for roads. We've been looking at OSM for a while, but it's too soon to announce a plan.
• Sharing obstacle data with FlightGear. We already share airport layout data with flight-gear; this would be a similar initiative. We looked at OSM for this, but FlightGear's data needs are a lot closer to ours. This is still in discussion; the FG guys are a sharp bunch, so I think we'll able to work something out.

One of the common threads for all of these ideas is that X-Plane community members have dug into them before we have. This is not surprising, and I think it is a good thing!

Another common thread is that these are all open data sharing initiatives. Collaborative data sharing has come a long way since we redesigned the scenery system, starting in version 8.0. My hope is that over the next several months we can make some of these ideas a reality.

But first I have to fix my 930 beta features. :-)

Who Am I?

This week we've seen an increase in questions from new users, potential customers (both in the consumer and professional spaces) and third party developers.  So before I start blogging about the guts of 930 and all of the new features and changes, here is some background.

I am the lead scenery developer for X-Plane; my main work area is the default scenery, the scenery tools and file formats, and the rendering engine.  I also work on modeling issues because the same rendering code draws airplane models and scenery models.  I don't work on the flight model or physics - that and about a billion other things are all Austin - heck, I don't even know what makes an airplane fly.*

My professional background is programming; I came very close to becoming an Air Traffic Controller - I went through a CTI program in California, but by the time the FAA called me for the next step of the process, over a year had gone by; I was deep in X-Plane already and the FAA was experiencing personnel turbulence.  I think I really would have really enjoyed being an ATC, but my personality is definitely better suited for a small company like Laminar Research than for a big government agency.

This blog is primarily targeted at authors who create scenery and airplanes for X-Plane, and also for users who want to know more about the "guts" of the sim.  It is not tech support; I will not answer tech support questions posted in the comments sectio -- sorry.  Please contact X-Plane tech support - they are there to help!

There are a few website resources for third parties that provide reference:

• The X-Plane scenery website - contains all the file format specs and LR's tools and code.
  
• The X-Plane Wiki - contains information on authoring planes, scenery and modeling.
  
• The X-Plane Plugin System has its own wiki.
  
• Robin manages our airport data - see his web page for downloads and file format specs.
  
• The X-Plane user's manual is available on the contact page, just in case the version you have from your DVDs is not as recent, or you are trying to use Plane-Maker in the demo.
  

There are also a number of mailing lists - the scenery and plugin pages list the appropriate mailing lists for those audiences.  I definitely recommend the mailing lists for developers and authors - traffic isn't too bad and there are a lot of knowledgeable users!

I can be reached by email via bsupnik at xsquawkbox dot net, but I must warn you: my in-box is on the verge of complete structural failure!  I try to answer everybody, but if your message gets lost, you may need to try again.

* This is actually not true - when I was in ground school, our instructor told us the real force that keeps an airplane in the air: money!

The News

By now everyone has heard the news: Microsoft is closing down ACES.

This is not a happy day; there is no joy in people losing their jobs in this economy. And having your product canceled really hurts. I have worked on programs that have been killed after I left the team, and I have worked on programs that have been killed while I was working on them, and either way, it really, really sucks.

What does this mean for X-Plane? That is something we are trying to figure out now. Halting development on MSFS is an earthquake within the flight simulation world; it was not a scenario we were planning for last week. In some ways, it changes everything, but in others it does not.

In particular, a lot of things have become high priority that were always important, but are now on a much shorter time table. Improving our documentation, simplifying the user experience, etc. Our current users have already learned the quirks of X-Plane, but we now have more people trying X-Plane for the first time and tripping over those stumbling blocks.

We are only a few days away from going beta with X-Plane 930. 930 was a huge patch for us already, with lots of new features "saved up" over several months, but now it is even more stuffed, since there are also last minute features to make the sim easier for new users, and to add in new capabilities that we are being asked about.

So to current X-Plane users, I ask two things:
* Please be patient with us, and with new users - this is a very busy time and a lot is changing very quickly.
* As always, don't panic. The first beta always has a few problems with certain video cards, and one or two really gross bugs. The quality of the betas will improve very quickly in the first week or so. Squeamish users should simply wait a few weeks, or skip beta entirely. Third party authors: please test your add-ons as soon as you can! The sooner you report the bug, the sooner we can fix it!

Our mission with X-Plane has not changed: it always was, and still is, to make the best flight simulator we possibly can!

Glass Objects

930 will have some new options for attached objects.  One is to declare a "glass" object.  When an object is declared to be glass, it is moved to the very end of the drawing order - even after the cockpit object.

The idea of glass objects is to let you make translucency that works from any view angle.  To make multiple layers of glass, the trick is to use pairs of one-sided triangles.  The glass (visible from the inside only) goes first, then the glass (visible only from the outside) goes second.  All of this goes into the object with the "glass" property in Plane-Maker.

One side benefit of the two-triangle approach is that the inside and outside of the windows can be tinted differently.

Having glass objects does three things for us architecturally:

1. It takes pressure off the interior cockpit object.  The interior cockpit is the only object that can have manipulators, so texture space in the interior cockpit object is quite valuable.  By allowing translucency in an attached object, you can put your window textures somewhere else and save texture space for the cockpit object.
2. It gets around the current weirdness where the interior cockpit object is drawn last but the exterior cockpit object is drawn first.  The glass object is always drawn last.  Period.
3. It sets us up someday for some kind of shadowing scheme in the cockpit.  This is a bit pie in the sky, but most pixel-based shadowing algorithms go a bit bonkers on translucent geometry; by flagging the whole object as "glass" we can simply omit it from shadow calculations.

The 921 draw order has the exterior cockpit object drawn first (if drawn) and the interior cockpit object drawn last (if drawn).  This made sense at the time - the exterior cockpit object was being used primarily for a pilot figure, with windows in the ACF paint - so it had to be drawn before the ACF fuselage.  The interior cockpit object has to be drawn last because the coordinate system is changed to a super-close-to-the-user coordinate system that has to be drawn last.

Now that there are attached objects, people are modeling a lot more of the airplane, the usual approach is to have all 3-d present all the time, so that a roaming camera won't reveal missing parts of the airplane.

Broken Panels

I have found the cause of a rather serious bug in Plane-Maker: sometimes instruments disappear from the hierarchy (but are still visible in the main window).

The problem is that the cut-paste facility, when used with multiple-instrument selections, was corrupting the hierarchy information.  Because of the way instrument hierarchies are managed, this corruption persists - even if it isn't visible.  So if you manage to ungroup everything, it looks okay until you work more, then the instruments disappear again!

This is a really bad bug of mine, particularly since a panel is such a time investment.  Here is what we'll be able to do in 930 to get around this:

1. A new "flatten panel" command simply ungroups everything and completely cleans the hierarchy.  All corruption of hierarchy is fixed with this command, finally exposing every instrument.  From that point on, you can then re-group and things should be okay.
2. I am fixing the cut-paste commands to not trash the hierarchy, and I am looking for any more hierarchy-corruption problems.
3. 930 has export/import of instrument groups to text files.  So another way around instrument corruption problems would be to export the panel to a text file, fix the grouping problems (which is a matter of moving the GROUP/END_GROUP lines) and then re-importing.  If you do not have a selection, the entire panel is exported, including any hidden items in the hierarchy.

I believe that text-based panel import/export will also be useful for sharing individual instruments (or clusters of grouped generic instruments), archiving work, and making large-scale changes using search-and-replace.

Two Squashed Bugs for 930

These two issues have been discussed a lot in the forums, so I thought I'd mention them:

First, I finally found and nuked that star-burst pattern in the rain.  It turns out that for some textures, compression was destroying the lower res mip-maps, causing the geometry that the rain drops are drawn on to show up as that starburst pattern.  It should be fixed for 930 beta 1.

Second, it turns out that the code that converts the 900-format generic instruments to 920-format generic instruments* was being run on the user's airplane whenever a multiplayer airplane older than version 920 was being run.  That could cause generic instruments to disappear, appear incorrectly, or just crash the sim, because the aircraft data in the user's plane (once the user is flying) is already in 920 format...if you interpret it as 900 format again, you get non-sense.  

I am fixing this for 930 beta 1; there may be other bugs relating to multiplayer and generics, so we'll see if this fixes most of the problems, or others crop up.  The panel system is essentially "global" (that is, there is one panel for the user in all of x-plane) but the instrument data is per-plane...so there is always a risk of code mistakes where the multiplayer planes affect the user's panel.

When will 930 beta 1 be out?  I don't know.  Hopefully pretty soon - when bug fixes make it into the blog, we're usually in the push to get to beta.  But I'm working on features on a few fronts, so it's hard to say which ones will be done first.

* X-Plane 920 revised the ACF format from version 900.  The file format for generic instruments was pretty much completely changed to accommodate new features like key frames.  920 has code that converts the 900 generic instruments into 920.  For example, simple key frame tables are built out of the older offset-scale parameters per instrument.

Unfinished Business

I have recently started leaving pieces of email and notes on the Wiki.  To see this mess, just view Category:Unfinished.

The problem is that often I don't know what people don't know but want to know.  So when I get an email question whose answer is not already posted somewhere, I make a wiki page and dump the info.

This stub is in response to some work I did this morning.  In particular, lights in X-Plane often have visibility much larger than the objects they come with.  This used to be true for the cars, but I broke the code in 921 and didn't notice.  In 921 headlights do persist beyond the car object's visibility distance, but not by much.  930 will fix this, restoring the "string of lights" look on the roads at night.  

I've also tuned the headlights to be visible from a wider viewing angle, to try to make them more noticeable from above.  (In real life, the lights illuminate an area of the pavement, which is visible, but we don't do this.)

If there is a scenery subject that is poorly or not-at-all documented, shoot me an email and I'll stub out a Wiki page - it's a first step to getting comprehensive documentation.

(Note that I have not added pages for tutorial steps like "how do I add a manipulator to my object" because I am doing the tools work for ac3d now ... better to write a tutorial for manipulators the easy way with ac3d than to write one on the hard way - editing the OBJ - and changing it later.  That is to say, I am trying to documetn tools, not temporary work-arounds!)

Panel Texture and Panel Clicking

As of X-Plane 9, life was simple: ATTR_cockpit and ATTR_cockpit_region caused your triangles to be textured by the panel, and they could be clicked. ATTR_no_cockpit went back to regular texture and no clicking.

Well, it turns out that secretly ATTR_cockpit was two attributes jammed into one:

• Panel texture - that is, changing the texture from the object texture to the panel texture.
• Panel clickability - that is, mouse clicks are sent to the 2-d panel and act on those instruments.

With X-Plane 920 and the manipulator commands, this "clickability" aspect is revealed as a separate attribute, e.g. ATTR_manip_none sets no clickability, and ATTR_manip_command makes a command be run when the triangle is clicked. These attributes can be applied to any kind of texture - panel texture or object texture.

So how does ATTR_cockpit work in this context? Basically you can think of ATTR_cockpit as two "hidden" attributes:

ATTR_texture_panel
ATTR_manip_panel
and similarly, ATTR_no_cockpit is likeATTR_texture_object
ATTR_manip_none
With this you can actually get any number of combinations of attributes, but the code is sometimes unexpected. In particular: if you want a manipulator other than the panel or none, you have to specify it again. Example:# set command manip
ATTR_manip_command hand sim/operation/pause Pause
TRIS 0 3
ATTR_cockpit
# we now have to reset the cmd manipulator!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 3 3
ATTR_no_cockpit
# we have to reset the cmd manipulator again!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 6 3
Similarly, if you want the panel manipulator, you may have to reset the cockpit!ATTR_cockpit
TRIS 0 3
# now make the mesh not clickable
ATTR_manip_none
TRIS 3 3
# Mesh clickable again
ATTR_cockpit
TRIS 6 3
The good news is: this isn't nearly as wasteful as it seems. X-Plane's object attribute optimizer is smart enough that it will remove the unnecessary attributes in both cases. In the first one, what you end up with is one manipulator change (to the command manipulator), and the panel texture change is done without changing manipulator state at all. In the second case, you end up with the manipulator change, but the panel texture is kept loaded the whole time.

In other words, even though the double-attributes or duplicate attrbibutes might seem to be inefficient, the optimizer will fix them for you.

One reason you might care: the cost of panel texture is one-time - that is, you pay for the size of the panel texture once per frame. But the cost of manipulatable triangles is per-triangle! So having more is bad. With ATTR_manip_none, you can use the panel texture but not have it be clickable, which can be a big performance win.

930 will handle manipulatable triangles a lot faster than 920 -- but that's still not a good reason to have all of your triangles be clickable!

This article is still unfinished, but I am trying to put together some info on how to detect performance problems like too many clickable triangles.

What Happened to X-Plane 910

X-Plane 910 was an update to X-Plane 9 for our professional customers.  But all of the new features that they got in 910, everyone got in 920.  Here's how it happened:

X-Plane 9 had a very long beta, and the end of that beta was mostly spent with a finished sim and me trying to fix the pixel shaders for five thousand flavors of video card, driver, and operating system.  During this time, Austin started work on new systems modeling features for professional level sims.  We branched the code, with my work going into 900 and his going into 910.

When he finished his systems code and I got the pixel shaders fixed and both were fixed, the two were combined into what became 920.

So that's how we "lost" the 910 version number - some professional customers have the version number, but everyone got the features.

Which is Faster: Panel Texture or 3-d Instruments

There are two ways to make 3-d instruments in your 3-d cockpit:

• Create 2-d instruments on a panel and use the "panel texture" (ATTR_cockpit or ATTR_cockpit_region in your OBJ) to show those 2-d instruments in the 3-d cockpit.
  
• Model the instruments in 3-d using animation.

So...which gives better framerate?  Well, it turns out that they are actually almost the same...a few details:

• If your card can't directly render-to-texture, there is an extra step for the panel texture. But that would be a weird case - all modern cards can render directly to textures unless you have hosed drivers.
• For very small amounts of geometry, there's pretty much no difference between rotating a needle using the CPU and telling the GPU to do it by changing the coordinate system.
• The panel texture does put pressure on VRAM - if you've had to go to a 2048x2048 panel texture to have enough space, it's going to hurt you.

Both approaches are actually quite inefficient - you get best vertex throughput on the card when you have at least 100 vertices per batch.  But if a panel has 800 batches, you don't necessarily want to do this - you'd pick up 80,000 vertices just trying to "utilize" the graphics card.  That's not a huge number, but it's big enough to consider.  Panels have enough moving parts that they're going to push the CPU more than the GPU.

A number of authors like the 3-d approach because they are more comfortable with 3-d tools, and because it can look sharper (since there is no intermediate limiting texture resolution). 

There is only one case where I would advise against the 3-d approach: if it takes a huge number of animation commands to accomplish what can be done in one generic, use the panel texture; the generic instruments are all coded cleanly and none of them take that much CPU power.  But some of them produce effects that would be relatively difficult to reproduce with animation.

Fixing Panel Editing in AC3D

The X-Plane export plugin for AC3D doesn't handle panel textures very well.  The current plugin tries to identify cases where you have used your panel background as a texture - this queues it to generate ATTR_cockpit.  This scheme has a number of problems:

1. The search paths for the panel background are not up-to-date.  The plugin doesn't know about the new naming conventions or the cockpit_3d folder.
2. The scheme doesn't address panel regions at all - there is some support for them but it doesn't work well.
3. Most important: panel editing is not WYSIWYG.  Since you are using the panel background as your texture, you can't actually see where all the moving parts are!  Doh!

That last point is perhaps the most important one, and it is why, for the next version of the plugin, I am introducing panel previews.

Basically a panel preview is a screenshot of your panel with the instruments on it, sitting in your cockpit_3d/-PANELS- folder.  AC3D will recognize and use the panel preview when possible.  This will solve problems (1) and (3) - there will be only one naming convention for previews, and they will be screenshots of the panel in action, so you can texture with a preview of the instruments.

Plane-Maker 930 will contain a facility to generate panel previews; if you are using X-Plane 920, you can generate the preview manually by taking a screenshot in X-Plane.

For panel regions, we will have one preview file for each region (e.g. Panel_preview0.png, panel_preview1.png).  This addresses issue 2 - usage of the region previews will invoke ATTR_cockpit_region.

Finally,  I am moving the panel sub-region information from the preferences to the .ac file (hopefully) so that it will be saved with your plane.

Hopefully this will make a work-flow which is much simpler.  To make a 3-d cockpit you will simply pick "generate previews" in Plane-Maker, and then start using the previews as textures.

Robin Redoes the Airport Data Page

I really like what he's done with the new page - see it for yourself here!

Accidental Contracts

In a previous post I ranted about the hidden cost of adding new third-party-accessible features to X-Plane - that cost being the cost of supporting the APIs way into the future so that third party content doesn't break.

Even trickier are accidental contracts - that is, unintentional behaviors that the sim exposes that third parties take advantage of.  This can be particularly tricky for us because we might not even realize that the behaviors are happening.

In 921 we allowed the HUD to be visible in the 3-d cockpit for planes that use our "default" 3-d cockpit, like the 777.  Ignoring that this was a truly silly feature to do, one of the side effects of the code change was that EFIS glass instruments now render correctly over transparent parts of the panel texture on some hardware.  Javier immediately jumpedon this to build a 3-d HUD.

These EFIS glass instruments appearing in that region was totally unintentional, and this is about the last way I wanted to implement 3-d HUDs, but now that it's in there, I have to ask: do I want to break Javier's airplane, which a lot of users will like?  Probably not!

Another accidental contract is the draw order of the cockpit objects.  Basically due to a coincidence of how the code is structured, the external cockpit object is drawn before attached objects, but the internal cockpit object is drawn after.  There is no good reason for this, but now that authors build airplanes based on this, we have to preserve it because changing draw order can break translucent geometry.

X-Plane is full of this kind of thing - and all of these hidden conventions make it tricky to restructure subsections of the code.

Al Bedo Makes an Omlette

Sometimes you have to break a few eggs to make an omlette.  Or at least, you have to consider whether breaking them is acceptable.  Often I hit cases where the cost of supporting a legacy feature is somewhat painful.

One way to decide what to do is to change the feature early in beta, see who squawks, and then change it back if necessary.  There are two I am looking at for 930.

Glass Instruments

It turns out that glass instruments fade to black, not to transparency.  This is a little bit weird, because that means they will leave black footprints if they are on top of a non-black background.  My guess is that most people use them on black screens and thus did not notice.

If people really need fade-to-black glass instruments, I'll just create a new lighting type (glass-transparent), but if everyone can live with fading to transparent, it's certainly the more useful case and probably what most people always wanted.

Separate Specular Hilights

For as long as I've been involved, X-Plane's specular hilights are modulated by the object or airplane texture color.  In other words, if you paint your airplane red, you get red hilights, and if you paint it black, you get no hilights at all.

This is not a very good way to do things for a few reasons:

• Under this scheme, you can't make a shiny black object.
• Someday we will add gloss maps - but the glossy part of the gloss map will be defeated by the black texture.

So for 930, I am looking at not modulating specular hilights by texture.  (This is called "separate specular hilights" in OpenGL lingo.)  My guess is that they will look enough better in almost every case that people would rather have it this way.

Should specular hilights be white for a black object?  Yes!  A specular hilight is a simulated intense reflection from a very far away, very bright object (the sun).  So it should take its color from the sun, not the object itself.  To this end, I have also (finally) set the specular hilights to take on the daylight sun color, so that they get fainter and yellowish at dusk.  This makes dusk and dawn look a little bit less strange.

(Nerd note: Technically, for the day texture to be an albedo texture, it shouldn't affect specular hilights.)

File Name Replacement Vs. the Library

When you make an airplane, you customize some of the images and sounds by simply putting a wav or png file in your aircraft package, with the same name as X-Plane's default. This is "file name" substitution.

What is good about file name substitution is that it is very, very simple.

But file name substitution has some limitations:

• If you need to provide multiple versions of a file, there is no way to do this. You can at most replace one file with one other file.
• There is a risk of "file name collision" - so file name substitution is only appropriate when we can be sure that a folder is only used for one simple purpose.
• The file name cannot easily encode a lot of information about how the file is to be used. We use _LIT to indicate an emissive texture, but imagine trying to encode every aspect of a .ter file in a file name (all of the projection parameters, physics parameters, texture clamping and alpha managemnent, paged texture loading). You'd end up with a file name like my_tex_na_42.23E_72.32W_conc_pd_5000_4000_nw_LIT.png. You can't tell me that that's an easy file to work with!

The scenery system hits all three of these limitations, and it deals with them in two ways:

1. Texture files are almost always referenced from a text file. The text file provides a place to put all of the important parameters about the texture.
2. The library system maps art assets to virtual file paths, avoiding collisions and allowing multiple files to be mapped to one virtual path.

Cristianno wrote this awesome tutorial, which shows how the library system works.

Who Is This Al Bedo Guy Anyway?

That's Mr. Bedo to you!

Sometimes I end up learning the name for a computer graphics idea or technique long after I use it. So I was amused the other day to find out that the fancy computer-graphics name for the "daytime" textures in X-Plane (you know, the normal ones for OBJs and airplanes) are called albedo textures in technical terms - or rather they define the albedo component of the lighting equation.

This is handy because I had a nice big fancy word for _LIT textures: emissive. So now, armed with both technical terms, we can accurately describe the two parts of lighting that X-Plane usually specifies by texture: albedo and emissive.

Basically the albedo texture tells what color you see when light shines on it (or rather, how much of that light is reflected back to the viewer diffusely) - it represents color information that does not generate its own light. The emissive texture describes light created by the object, and thus visible under any circumstances.

X-Plane's lighting equation is thus typically:

albedo * brightness at that point + emissive

Where "brightness at that point" is the sum of all of the lighting effects from any number of lights, the sun, ambient light, etc.

Now there is something interesting about this lighting equation: the emissive component is added to the "modulated" albedo component. So what happens if:

• Albedo is 100% (that is, white)
• The brightness of the sun is 100% bright (really bright day) and
• Emissive is non-zero?

Answer: the total lighting is more than 100%!

100% of what? These lighting values are described in terms of the range of color your monitor can output, from black (0%) to white (100%). So if we have a lighting value of 120%, basically it shows up as white (100%) and the "extra" white is lost. The result is a loss of color accuracy and detail.

For 930 I have a to-do item to scale down all emissive light by a constant factor when the day time overall brightness is high.

The idea is this: in the real world, your eyes have non-linear, adjustable sensitivity to light (and the sun is really, really bright). So when the sun is out, the amount of light added by a neon sign is trivial compared to the light already on the sign from the sun. At night the sign's light is much more significant because it is relatively dark (thus the sign is in a more sensitive part of your vision and your eyes are adjusted).

In X-Plane, scaling down the emissive texture during the day will simulate its lesser effect during the day.

One more note on emissive vs. albedo texturing: ATTR_emission_rgb basically sends a certain portion of the day time (albedo) texture to the emissive part of X-Plane's lighting. But the emissive (LIT) texture is still used. So if you use ATTR_emission_rgb, don't set the emission level to full (1.0 1.0 1.0) and use a very bright _LIT texture; the result will be more than 100% brightness.

Failed Ideas and Two-Core Rendering

I'm pretty gun-shy about posting new features to this blog before they are released.  One reason is that a fair number of the things I code never make it into the final X-Plane because they just don't perform as expected.  But the converse of that is: there should be no problem posting about what failed.

One idea that I believe now will not make it into the sim is dual-core pipelined rendering.  Let me clarify what I mean by that.

As I have blogged before, object throughput is one of the hardest things to improve in X-Plane. That code has been tuned over and over, and it's getting to be like squeezing water from a rock. That's where dual-core pipelined rendering comes in.  The idea is pretty simple.  Normally, the way X-Plane draws the frame is this:

for each object
is it on screen?
if it is tell the video driver, hey go draw this OBJ

Now the decision about whether objects are on screen (culling) is actually heavily optimized with a quadtree, so it's not that expensive.  But still when we look at the loop, one core is spending all of its time both (1) deciding what is visible and (2) telling the video driver go draw the object.

So the idea of the pipelined render is to have one core decide what's on screen and then send that to another core that talks to the video driver.  Sort of a bucket-brigade for visible objects. The idea would be that instead of each frame taking the sum of the time to cull and draw, each frame should take whichever one is longer, and that's it.

The problem is: the idea doesn't actually work very well.  First, the math above is wrong: the time it takes to run is the time of the longer process plus the waiting time.  If you are at the end of a bucket brigade putting out the fire, you waste time waiting until that first bucket goes down the line.  In practice the real problem though is that on the kinds of machines that are powerful enough to be limited only by object count, the culling phase is really fast.  If it takes 1 ms to cull and 19 ms to draw, and we wait for 0.5 ms, the savings of this scheme is only 2.5%.

Now 2.5% is better than nothing, but there's another problem: this scheme assumes that we have two cores with nothing to do but draw.  This is true sometimes, but if you have a dual-core machine and you just flew over a DSF boundary, or there are heavy forests, or a lot of complex airports, or you have paged-texture orthophoto scenery, then that second core really isn't free some of the time, and at least some frames will pick up an extra delay: the delay waiting for the second core to finish the last thing it was doing (e.g. building one taxiway, or one forest stand) and be ready to help render.

And we lose do to one more problem: the actual cost of rendering goes up due to the overhead of having to make it work on two cores.  Nothing quite gloms up tight fast inlined code like making it thread-safe.

So in the end I suspect that this idea won't ever make it into the sim...the combination of little benefit, interference by normal multi-core processing, and slow-down to the code in all cases means it just doesn't quite perform the way we hoped.

I am still trying to use multiple cores as much as possible.  But I believe that the extra cores are better spent preparing scenery than trying to help with that main render.  (For example, having more cores to recompute the forest meshes more frequently lowers the total forest load on the first CPU, indirectly improving fps.)

This Is Where SRTM Comes From

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

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

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

Contractual Ranting

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

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

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

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

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

The Cost of Changing the Contract

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

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

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

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

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

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

I'm Not Signing That

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

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

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

What You Want, Not Where You Want It

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

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

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

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

To Wiki

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

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

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

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

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

Testing on Old Hardware

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

Those cards include:

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

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

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

To Wiki or Not To Wiki

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

Consider two approaches to documentation:

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

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

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

The New iPhone Apps Are Here

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

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

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

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

More Aircraft RFCs - Landing Lights

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

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

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

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

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

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

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

Shader Optimization Fallout

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

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

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

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

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

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

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

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

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

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

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

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

Liveries vs. Configurations

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

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

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

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

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

Files used by an aircraft fall into three broad categories:

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

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

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

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

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

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

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

The impenetrable Object Barrier

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

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

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

In practice it won't be that simple:

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

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

Moving Features to the GPU

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

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

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

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

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

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

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

Auto-Variation and Repetition

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

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

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

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

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

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

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


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

And this is the final result.

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

Dealing With Repetition

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

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

We use a number of techniques to minimize this problem.

Lots of Land Uses

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

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

Variation

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

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

More VRAM

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

In summary, we have three techniques:

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

The "Airplane Modeling" Datarefs

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

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

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

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

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

Clean Naming

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

Array Sizes

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

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

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

Failure Support

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

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

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

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

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

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

Correct Multiplayer Behavior

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

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

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

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

What Dataref Do I Use?

Here's the rule of thumb:

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

That's all there is to it!

Bug Fixes in the Pipeline

A few things are in the works:

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

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

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

Two Video Cards, Two Vendors

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

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

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

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

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

Fun With Menubars

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

So here's where things get fun:

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

What's going on?  Two things:

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

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

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

Fps test 2, 8800: 46,49,51

Fps test 2, 3870: 70,75,80

Fps test 3, 8800: 24,25,25

Fps test 3, 3870: 40,41,43

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

Hardware Guidance: Four Cores and DX10

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

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

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

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

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

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

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