Cockpit Panel Regions, the Untold Story

A third party developer recently asked me what the purpose of panel regions was, and how they were meant to be used.

Now I blogged about this before, and if you’ve read the post you are probably thinking: “Ben, were you high when you came up with panel regions?”

Sadly, the answer is no, but that doesn’t make panel regions any less weird.  This post explains what happens.  (Sound nerds: see the end for the moral of the story.)

One thing to note: the panel texture is expensive.  Because the sim re-draws it every frame, it has to sit in VRAM all of the time – thus it puts more pressure on VRAM than regular OBJ textures (which can be paged out when not used).  No matter how you do your panels (the old way, the byzantine way, or the new way), make your panel texture as small as you can – it’s worth it!

The Short Version

The short version is this:

• Always use the 3-d panel.
• Keep your 3-d panel as small as possible – pack it tight!
• Make your 3-d panel a power of 2 in each dimension, e.g. 2048 x 1024.
• Use one cockpit region in your object, that matches the size of the 3-d panel.

The long version explains how we got here.

You Might Ask Yourself, “How Did I Get Here?”

In order to understand how we ended up in this situation, remember that panel regions were invented before the 3-d panel existed, and they were invented for X-Plane 9, which runs on some fairly old video cards.

Going into X-Plane 9, we wanted to simultaneously fix a bunch of problems with using panels as textures for 3-d cockpits.

1. The 2-d panel supports alpha; the technology to do this was at the time expensive and hurt performance of the 3-d cockpit as a whole.
2. The 2-d panel contains a lot of wasted space.  The texture space dedicated to the cockpit windows is not useful in a 3-d model.
3. The 2-d cockpit might be huge; version 9 introduced 2048 x 2048 panels.  Authors have a motivation to make the 2-d panel huge to cover a large monitor.
4. The 2-d cockpit includes 2-d spot light and shadow effects, which are expensive to prepare for the 3-d panel texture.
5. The 2-d cockpit might not be a power of 2 – at the time, this meant wasted VRAM.
6. The panel texture was drawn in 3-d by simply drawing the 2-d panel.  Thus the panel textured area of 3-d cockpits didn’t respond to real-world directional lighting.

The panel region system fixed all of these things:

• A panel region is a sub-area of the panel, and it must be a power of 2.  This fixes items 2, 3, and 5.
• A panel region ignores alpha and ignore spot lights.  This fixes items 1 and 4.
• A panel region is drawn with correct additive lighting, fixing item 6.

In other words, ATTR_cockpit_region fixed everything wrong with ATTR_cockpit.

3-D Panels Make For Chaos

It’s about at this point in our story that things start to go south design-wise.  At the time (near version 9 beta) the panel system was in sort of a never-never land, not really my code, not really Austin’s code, being driven by one-off requests.  There was no road map.

Shortly after we got the panel region system working, we added the “3-d panel”.  The 3-d panel is an entirely separate parallel panel whose only role was to be “the panel texture” for 3-d cockpits.  We realized we needed this because often the 2-d cockpit is useless for 3-d texturing.

Consider the overhead panel.  If you have an overhead panel in 2-d, it’s going to be drawn at a crazy perspective, to make it look sane in a forward view.  But to texture a real 3-d overhead panel, you need an orthographic texture, taken straight on.

Once we had a 3-d panel, a lot of the reasons for panel regions were gone.  The 3-d panel could be tightly packed, with no windows, no alpha, and it didn’t need to be enormous.  In other words, the 3-d panel solved most of these problems better than panel regions did.

Had I used my brain, at this point I would have simply merged the two features together and gone home and life would have been really simple.  But instead, I let the two features co-exist.  This makes for four combinations – we can have the 3-d panel without panel regions (generally a poor idea) and we can have the 2-d panel with panel regions (which is arguably unnecessary).  And I let the 3-d panel be as unrestricted on the 2-d panel, which was just silly.

It should also be noted that having no alpha in the panel and a power of 2 panel size aren’t as important as they used to be, and can be overcome with modern hardware.  They were important for version nine though.

So the bottom line is: you still have to use a panel region to tell X-Plane to use real additive lighting, and to guarantee that you’re going to use a power of 2, no-alpha texture.  But the “region”-ness (the ability to pick out parts of the panel) isn’t useful since you can now create a separate packed panel for 3-d cockpits.

Thus the recommended practice: use the 3-d panel, pack it tight, and use one region to get additive lighting.

Clean-Up?

Can anything be done to simplify and clean up the panel creation process?  I’m not sure.

For the authoring environment, there are three things we can do to make life easier for panel authors:

1. Introduce new commands that are simpler.  For example, we could set up a single OBJ command that uses the entire 3-d panel with additive lighting – this command would provide the interface that always should have been there.  Of course, this would be yet another command, making the “full” system (including backward compatibility) even more confusing.
2. Simply change the behavior of existing commands.  I am always hesitant to do this, because it has the potential to break older airplanes.  But the current system does provide a number of feature combinations that make very little sense.  There might be some things that we could do that could simplify the system for authors. (For example, we could use new modern correct additive lighting even for ATTR_cockpit if the 3-d panel is used, since it’s almost always the right thing to do.)
3. We can provide Plane-Maker “hints” to encourage people not to use the strange un-recommended paths.  This would hopefully start to shape the set of airplanes to use the features we want without breaking any airplanes.

None of these options is great, but my gut feeling is that if we start with 3, we might be able to go to 2 – that is, we can start encouraging people to use the 3-d panel with one full-size cockpit region, the preferred way to use the system.

Epilogue: What Have We Learned?

If there’s a moral of the story it’s this: when it comes to features that affect how third party content is created, think twice, cut once.  Once you design a bizarre interface and everyone starts using it, it’s nearly impossible to fix, and the “cost” of maintaining backward compatibility in the sim goes up for years.

This is why I have said no to any and all incremental proposals for sound features in X-Plane.  There is no question we need better sound support.  But I believe that the future format of sound is (1) not particularly obvious in terms of today’s sound system and (2) not likely to look anything like what we have now.

If we put in incremental sound features one at a time, every one of them will have to be heavily modified to work with future sound features.  There’s no easy way to add just a little bit here, just a little bit there.  In other words, it’s the panel system all over again.

When there is a mature, modern design, it is possible to add incremental features quickly and cheaply.  This is the case with OBJs – we’ve been able to add new features (mostly in the form of new attributes) one at a time and it more or less just works, because the basic OBJ design is solid, and adding new attributes doesn’t radically change the system.  The same thing is true for adding new properties to generic instruments.

But when a feature fundamentally changes the structure of authoring, there’s a big penalty for not getting it right the first time.  The panel system continues to be a pain in the ass to maintain and confusing to use because some major features were thrown together ad hoc without a good plan.  I don’t want the sound system to be like that.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

View all posts by Ben Supnik →