Separate Specular Hilites and Per-Pixel Lighting

A number of users have commented that the X-Plane 930 betas looks "shinier" than before. There are actually two separate features going on :

• Separate specular hilights. Specular hilights are bright areas on the plane that simualte the refelction of the sun on a shiny surface. X-Plane has had specular hilights for a while (available by the "shiny" check-box in Plane-Maker or ATTR_shiny_rat for an OBJ). What's new is: while previously the hilights were modulated by a texture, they are now independent of the texture. This change means that even a black surface can look shiny now. Before the black surface would "tint" the hilight black, making it invisible. Now we can have a white hilight on a black surface for a glossy look.
• Per-pixel lighting (when shaders are on). Before the lighting calculations were performed on each vertex on a model, then the color from the lighting was interpolated. The problem with this is that if there is a very local lighting effect (like a specular hilight) that is smaller than one triangle, you can't see it (since we can only see the lighting at far apart vertices). With 930, the lighting calculations are done per pixel, making the lighting effects look smoother.

Here we have the default 747, as of 922. It's a little bit tricky to tell what's going on because the texture has been painted to look like there are lighting effects. But the white "specular hilights" on the engine nacelles are due to the sun position. Lighting is per-vertex and specular hilights are not separate.

Next we have the same plane in 930 without shaders:

Note the increased brightness on the nacelles and fuselage. What's happening is the hilights are no longer modulated by the texture, so they show up a bit more.

Finally, the plane in 930 with shaders. Now the hilights look smoother and much brighter. This is because the hilights are calculated on a per-pixel basis. Note how the hilights are small - smaller than the triangle size on the engines. We didn't get the full "glare" effect before because the brightest part of the hilight did not land on a vertex at all, and was thus never seen.

Note that the change in specular hilight handling (moving to separate specular hilights) is a bit of a compatibility break. Previously authors could count on not having specular hilights on dark parts of a plane, even if they set the plane to be shiny.

I am not sure how we will ship the final version of 930. I have received very few (none, to be exact) complaints about dark surfaces appearing "too shiny", and a lot of users like the new shiny look.

The alternative to the current scheme (specular hilights are separate by default) is to have this be a selectable feature. Older planes would look the same as they always did, but planes would have to be modified to make them look truly shiny.

Hard Object Weirdness (or Don't Count On Bugs)

ATTR_hard is the OBJ attribute that makes the geometry of an object mesh interact with X-Plane's physics engine.  ATTR_hard object has a long history of weird behavior, and its behavior in X-Plane 930 is no exception.

The History

• Before X-Plane 815, hard surfaces acted horizontal regardless of the actual OBJ geometry.
  
• From X-Plane 815-922, sloped hard surfaces work as expected, but vertical hard surfaces do not work.  Animation is ignored for hard surfaces.
  
• Starting with X-Plane 930, animation commands affect hard surfaces.  However, vertical surfaces still do not work, and an animated surface does not create friction under the plane.  

(In other words, if you put the plane on a platform and move the platform horizontally, the plane will be pulled with the platform due to friction between the platform and the wheels.)

In all of these cases, what we have is a limited implementation that doesn't correctly capture all expected behaviors.  Why don't we have a better implementation?  There are two factors.

1. In some cases a more correct implementation might take significantly more CPU power. It is important that we not raise the CPU requirements of X-Plane mid-version run.
2. In some cases, we simply don't have a better implementation coded yet.  Remember that X-Plane is primarily a flight simulator.  My pilot friends tell me that it is bad form to collide the airplane with anything during flight.  So the goal of OBJ collisions is more to detect poor flying than to correctly model the resulting aftermath.  X-Plane is not GTA4!

What Do You Do With a Buggy Feature?

Very simple: don't use it if you can avoid it!  I don't mean "don't use ATTR_hard" - it has legitimate uses.  Rather I mean: don't depend on the buggy behavior as a feature.

For example, before 930, animation would affect the drawn but not physical OBJ.  I would say that given that bug, the only safe thing to do is to not animate hard objects.  Animating hard objects to take advantage of the schism between drawing and physics would be assuming that the bug will stay buggy forever.

What Can You Do Now?

In X-Plane 930 hard object animation is a lot better than it used to be, but still not quite correct.  The remaining limitations are:

• There is no friction.  If you move a platform horizontally, the plane is not dragged along. So you can't really build horizontal elevators.  (You can build a platform that moves vertically and move the plane around that way.)
• There is still not support for vertical hard surfaces.  Like before, to make a solid "wall", make the wall thick and make the top of the wall hard.  But bear in mind that the collision detection in this case is catastrophic; your plane will be heavily damaged by even minor contact with the wall.  X-Plane doesn't support horizontal collisions right now.
• Hard surfaces are ignored for vehicles.  If you are replacing the car set, don't add hard surfaces - it might turn out that some future implementation does look at them - if that happened, how would you know what the CPU hit is?

Even given this limitation, you can now make a building with limited access controlled by animation; using a "deck" for the roof and a hard surface for the tops of the walls and the doors (which are animated) you can control access.

VOR Range

It is true that in X-Plane 922, some programmer dialed down the effective range of VORs.

That programmer was me.  (This is what happens when you let a non-pilot go poking at the nav code.)

The bug report was that a rather far away VOR could be received on the ground at KSFO; looking at the actual service volume, the notion that this could happen was crazy.  I ended up tuning the distance calculation and also the "fudge factor".  The fudge factor is the increase in the service volume of VORs in the sim from the listed usable service volume (which is really more like a guaranteed minimum) that lives in the nav.dat file.

Here's the real problem: VOR range has a lot to do with altitude, but X-Plane does not simulate shaped 3-d service volumes.  I think we will, but probably not for 930.  So for now we have to pick a fudge factor that is large enough to make IFR navigation work without allowing you to receive any VOR from any location.

Beta 3 is still a bit short for VOR range - beta 4 or 5 may improve things a bit.

Note that it is possible to change the service volume of navaids in the nav.dat file.  For example, KBOS and KLAX both have extended localizers; the fudge factor for a localizer doesn't have to be 5x to allow KLAX to have a 100 nm final; the nav.dat entry for KLAX includes this special case.

When To Cut a Beta

Cutting the next beta is a double-edged sword:

• Any beta that doesn't have known bugs fixed is just not as good as it could be, and is putting buggy code in the field, where those bugs take away from testing.
• Sometimes bugs are severe enough that they occlude other testing (particularly if there is a crash bug).

X-Plane 930 Beta 3 will be out fairly soon.  The biggest thing that is not fixed is the weird lighting on GeForce 6/7 hardware with pixel shaders on.  It's just my luck that we'd have a hardware-specific shader bug on the one chipset I don't have right now.  (I could pull my 9700 from the PC, but then I won't be able to reproduce the evil "framebuffer incomplete" bug.)

We did find an intermittent crash during scenery load while flying - that's the kind of thing we need to get into a new beta; we can't tell what else is a real crash until that one gets cleared out of the way.

There is a crash bug that we haven't fixed in beta 3: Austin and I have both seen a single, unreproducible crash during startup on Windows.  If you have a crash during startup on Windows, please send a crash_log.txt with your bug report!

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!