Category: Aircraft & Modeling

Kill Your Objects

X-Plane 10.25r1 will go final soon (this week I think) and will be almost the same as 10.25b3.  There is one new feature that I am ‘squeezing’ into the RC at the last minute. Squeezing features into an RC at the last minute is not very good project management discipline, but in this case the feature is simple in its implementation and will allow custom airplane authors to improve framerate a bit.

The feature is “object-kill” – that is, the ability to completely disable (via a dataref) attached objects from being drawn.  Even when objects are hidden, they have CPU overhead; this features lets authors determine (in their plugins) which parts of the plane are not needed and completely remove them.  That big link explains how to use it and what it does.

How the Killers Kill Objects

X-Plane is, for the most part, not like a first-person shooter or racing game; those games have incredibly detail-rich environments, but they also have players that (mostly) stay on the ground, and environments with a lot of near objects blocking far views.  By comparison, with X-Plane, once you take off and climb to about 300 feet AGL, you can see nearly everything around you.

For this reason, X-Plane takes a fairly different strategy than shooters when it comes to figuring out which objects to draw, and which not to draw.

• X-Plane only eliminates objects that are off-screen (behind you, off to the side), too far away, or too small due to distance.
• First person shooting games try to eliminate objects that are occluded by nearby scenery.  (They also eliminate the off-screen and too-small objects.)  Here are two Wikipedia articles on the basic techniques.*

We don’t try to eliminate occluded objects because the cost of searching for them would hurt fps at all times; since a lot of the time almost no objects will be occluded, we skip the step, saving overhead.

First person shooters often pre-compute “hint” information to determine which objects can be hidden.  This is not possible for X-Plane because the loaded scenery may be a mix of several scenery packs; while we could pre-compute occlusion information for the global scenery, custom scenery might eliminate the occluders (using exclusion zones), rendering our pre-computed information wrong.

But there is one environment where X-Plane looks a lot more like a first person shooter: inside the virtual cockpit.  The VC is an environment where there is a ton of detail at high density and a lot of occlusion.

Here’s the problem: first person shooters often set up culling data ahead of time in their modeling environments; the engine only evaluates the precomputed hints.  But airplane scan be modeled in any number of programs: Blender 2.49, Blender 2.6, 3DS, ac3d, or any program that can create 3-d.

Therefore the intention of object-kill is to let authors do their own culling and simply tell X-Plane (via datarefs) the result.  These techniques could be portal-style occlusion techniques, computed automatically, or simple rules coded in a script.

Inside/Outside Views

The X-Plane 3-d cockpit camera is a completely free camera – you can walk out of the cockpit, through the cabin, out the door, and go look under your wings.  I think that this kind of ‘freedom to roam’ adds a nice element of ‘playability’ to X-Plane, but it also comes at a performance cost.  We do not provide separate “interior/exterior” objects – every object is drawn in both the interior and exterior views, because the views are fluid.  You can always look in the window from an exterior view, and you can always walk outside from an interior view.

If you need distinct inside/outside views to improve performance, you can use object-kill to implement this feature.  Simply write datarefs to determine when the view is ‘inside’ or ‘outside’ and wire up each object with a dataref to kill it.  Kill your interior views in exterior views and vice versa.

(See below for more subtle ways to optimize objects.)

How Would I Use This Feature?

I am not an aircraft author, so that’s a highly theoretical question, but here is how I would use this feature:

1. I would wire each object up to its own custom dataref and turn each one off in DataRefEditor.  For each object, I would note the change in CPU and GPU usage.  From this I can determine which objects are actually expensive.
2. For each object that is expensive, I would look at my model, and develop simple rules for when I can avoid drawing them.
3. I would code some ‘predicates’ – that is, functions that tell me about the state of my objects.  The idea of predicates is to summarize a set of conditions in question form.
4. I would then code these rules into simple plugin-based datarefs to hide the objects at the right times.

Here are some of the predicates I would look at:

• Is the camera in the cockpit?  (This requires looking at the XYZ of the pilot’s head position and comparing it to a box I determine from my model, as well as the current view mode.)
• Can the pilot see backward?  (This requires looking at the pilot’s head horizontal rotation.)
• Is the cabin of the airplane visible?  (E.g. for planes with a cockpit door, is that door closed?)

Then I can easily write rules like:

• “if the camera is in cockpit and (the pilot cannot see backward or the cabin is not visible) kill interior cabin.”
• “if the pilot is in the cockpit and the pilot cannot see backward, kill the entire external model.”
• “if the pilot is in the cockpit, kill any details underneath the aircraft (gear, gear door, baggage doors, etc.).”

Two last thoughts on performance tuning by removing objects:

1. It make sense to spend more time tuning performance on the views that matter most.  Note that the above rules are all for the virtual cockpit.  The virtual cockpit is where users will spend most of their time in the plane, including hand-flying it, so performance matters.
2. You need the most fps gains on the views that are slowest.  So if the virtual cockpit is slower than external views (which it almost always is) it makes sense to do more work to optimize the virtual cockpit.

* I wrote some very simple anti-portal culling code for X-Plane in an attempt to measure what kind of performance gains we might get.  The conclusion: not much.

The problem is that X-Plane heavily groups objects into large clusters so that it can submit them via hardware instancing.  When a lot of objects are visible, this optimization makes a big difference in performance – it can be a 10x improvement in speed.  But the large groups also mean that, at any given time, at least some part of a cluster is on screen, even when portals are used.

When I turned off the grouping, portal culling cut the object load in half (after some hacking the engine).  That’s a big win, but the grouping gives us 10x the object budget, so we hurt object performance by 10x, and then improved it by 2x – not a win in the end.

Using the Correct Wing Datarefs

This topic is confusing, so I’m going to try to summarize “how to do it the correct way” without going into “under the hood”, first.

DataRefs of the form:

sim/flightmodel2/wing/dataref_name[N]

give you information about the wings – in particular, they tell you the degrees of deflection of the flaps, elevators, etc. etc.

But what number do you use for N?

The answer is: you pick “N” depending on which airfoil you are animating!

In X-Plane, the horizontal and vertical stabilizers are “wings” too – we call anything that has an airfoil a wing.  So you use this table to pick an N that matches what you are doing.

Good:

sim/flightmodel2/wing/aileron1_deg[0] # left aileron
sim/flightmodel2/wing/aileron1_deg[1] # right aileron
sim/flightmodel2/wing/elevator1_deg[8] # left elevator
sim/flightmodel2/wing/elevator1_deg[9] # right elevator
sim/flightmodel2/wing/rudder1_deg[10] # rudder

Usually not good:

sim/flightmodel2/wing/aileron1_deg[8] # aileron on an hstab??
sim/flightmodel2/wing/aileron1_deg[10] # aileron on a rudder?!
sim/flightmodel2/wing/elevator1_deg[0] # elevator on a wing?
sim/flightmodel2/wing/elevator1_deg[10] # elevator on a rudder?
sim/flightmodel2/wing/rudder1_deg[0] # rudder on a wing??

The moral of the story is: pick an array index that matches the part of the plane you are trying to animate!

Unusual Airplanes

I said “usually not good” above because there are airplanes with rudders on the wings (think of a flying wing) or V-tails where the tail is half-rudder, half-elevator.  The rule still applies: use the index that you are animating!  So if you have a rudder on your wing, then use index 0 (left wing 1) for the left wing, etc.  The important thing is to pick an array index that matches the Plane-Maker part.

Why Is It Like This?

If you understand what was written above, you should probably stop reading now. And if you didn’t understand it, you should probably stop reading now.

Okay then.  Why are the datarefs like this?  The answer is that X-Plane is a completely flexible simulator: it lets you put any control surface on any flying surface.  If you want to make an experimental design with elevators on the wings, X-Plane is not going to tell you that your idea is stupid.  (I might tell you that the idea is stupid, but you can ignore me, because the only airplane I ever designed from scratch in Plane-Maker couldn’t take off without JATOs.)

In particular, because any flying surface can have any control surface, the datarefs are set up with array indices for all flying surfaces for all control surfaces.

But if your airplane does not have rudders on the wings, the value of those daterfs won’t be useful – they might be ‘correct’, they might be zero, they might be wrong.  Don’t trust them!  Use the correct array index for the correct wing and your plane will work correctly.