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.
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.
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 2048×2048 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.
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.)
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.
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:
- sim/cockpit2/ which provides a new set of datarefs for cockpit modeling via OBJ animation and generic instruments.
- 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!
There’s a bug in X-Plane 900 RC2 that will be fixed in RC3. Basically when you’re flying in the Cirrus with a friend (also using the Cirrus via multiplayer) you’ll see your own control deflections on his or her plane.
Understanding this bug gets into the way datarefs and object animation work. In simple terms, a dataref is an access point to data provided by some other part of the sim…the flight model, or another plugin. An object references a dataref as its source for animation values. So if you want to animate the wings, you use sim/flightmodel/controls/lail1def or sim/flightmodel2/wing/aileron1_deg.
Now the question is: when you access this dataref in a multiplayer context, which aircraft’s ailerons are you talking about? It turns out the answer depends.
- For all datarefs except sim/flightmodel2/ and sim/cockpit2/, if the dataref needs to access a plane, the access is to the user’s plane (flight 0), always.
- For sim/flightmodel2/ and sim/cockpit2/, the access is usually to flight 0. But if we are drawing an aircraft, these datarefs refer to the aircraft being drawn!
(Note: this second feature only works correctly in RC3.)
So when you want to animate the wings of your plane in X-Plane 9, by using the sim/flightmodel2/ datarefs in your object, you’ll get the behavior you want: animation with the first plane’s flightmodel when your plane is loaded as plane one, animation with the second plane’s flightmodel when your plane is loaded as plane two, etc.
Of course the rule of thumb is simple: if working on v9, always prefer sim/flightmodel2/ and sim/cockpit2/ when possible for animation work.
Could we have simply made the sim/flightmodel/ and sim/cockpit/ datarefs have this “pick the right airplane” behavior? Possibly, but I took the more conservative opt-in approach. Basically any time we want to change the behavior of the sim we can do one of three things:
- Change it globally – all third party content is affected; don’t like it, too bad. This is how pixel shaders work; if shaders are on you can’t disable the different fogging they provide for your airplane or object.
- Opt-in – you have to change your content to get the new behavior; old content defaults to unchanged. This is how the new datarefs work. You have to edit your content to use the new datarefs to get the new behavior.
- Opt-out – you have to change your content to avoid the new behavior. For a while cockpit lighting was like this, but I received so many reports of version 8 airplanes looking totally strange that I changed the cockpit lighting choices to opt-in.
Generally opt-in is the safest thing we can do to leave previous content working; if we make a change globally then we break any content that doesn’t work well with our changes. Datarefs are used so heavily that a fundamental change in how they work would probably not be safe.
Given a choice between opt-in and opt-out I’ve come to prefer opt-in; both require the same amount of work for LR (we have to write code to support the old and new behavior) so why not do the thing that provides better compatibility?
Finally a general historical note: sim/cockpit2/ and sim/flightmodel2 are not just there to provide new behavior with objects; they are designed to give us a clean start in providing only authoring-related datarefs in an easier-to-understand format. The original datarefs were meant only for programmers, so we didn’t worry too much about usability. Since then, datarefs have become the communications medium for panels and a lot of 3-d animation.
So not only do sim/cockpit2 and sim/flightmodel2/ provide correct animation behavior, but they’re also easier to read.
An important distinction between sim/cockpit2 and sim/flightmodel2 is that they partition the datarefs based on perception vs. reality:
- Generally sim/cockpit2 shows datarefs as the pilot sees them in the cockpit, and actions as the pilot commands them.
- Generally sim/flightmodel2 shows the plane’s behavior as it’s really simulated, and actions as they actually happen.
In other words, when the pitot tube ices up, sim/flightmodel2 shows the real airspeed and sim/cockpit2 shows the incorrect airspeed. When the hydraulic system fails, sim/cockpit2 shows that the pilot wants to bank, and sim/flightmodel2 shows that the ailerons aren’t really moving much.
What this means is that you should use sim/cockpit2 for cockpit objects and generic instruments and sim/flightmodel2 for objects attached to the airplane exterior. This will assure that failure simulation works correctly (e.g. failures are perceived correctly by the pilot) and the external control surfaces match the plane’s physical behavior.
If you’ve studied sim/cockpit2 a lot, you know it’s pretty incomplete. We’ll be adding the rest of the cockpit systems in 910. I would have liked to get the entire set of airplane changes into 9.0 but there’s a lot more to do – not just more datarefs, but also manipulators for 3-d objects and a new lighting model for aircraft interiors. I think 910 will finish what 900 has started in terms of new airplane features.
Final random note: RC3 will allow you to pick any dataref for a generic instrument, not just sim/cockpit2 and sim/flightmodel2. This is mainly so people writing plugins can easily hook their datarefs up to the panel by editing datarefs.txt instead of typing them by hand.
I’ve blogged about this before, but…let me be totally clear:
Don’t use ATTR_cockpit in objects that are not one of the two cockpit objects for your airplane.
Don’t use ATTR_cockpit in the attached misc. objects for your plane – move the parts of the mesh that require ATTR_cockpit into the cockpit object.
Don’t use ATTR_cockpit in scenery objects.
The
OBJ spec basically says as much when it says “don’t use cockpit features” outside of cockpits.
Now what goes wrong if you violate this varies with the betas vs. X-Plane 8, but I can tell you this: no version of X-Plane has ever shipped that will correctly handle ATTR_cockpit in attached objects for all cases. There’s always been bugs in this not-such-a-good-idea code path; it’s just the severity has varied over time.
Here’s a summary of the new airplane features in 9.0 (and some coming). Hopefully this will give you an idea of what new capabilities are available for modeling planes in X-Plane 9. This list will sound like a broken record – virtually all of these features are optional; you don’t have to recut your finished airplanes to use them in version 9.
2-d vs. 3-d Panel
You may have noticed the new “3-d panel” option in PlaneMaker 9. This allows you to build a separate panel for the purpose of providing the texture to ATTR_cockpit (or ATTR_cockpit_region). You can then:
- Provide alternate instrument artwork in a cockpit_3d folder. (This lets you have perspective artwork for the 2-d cockpit and orthogonal artwork for the 3-d cockpit.)
- Pack your instruments together tightly to save space. (There is a real cost to large panels, so using a 1024×1024 panel for the cockpit object is a lot better.)
The 3-d panel is strictly optional, fully replaces the 2-d panel only for cockpit objects, and is activated by providing a custom panel background in a cockpit_3d folder. (See the “Example Plane-Widescreen+objects” plane in beta 19.)
ATTR_cockpit_region
Cockpit regions are an alternative to using the entire 2-d panel to texture your objects. They provide a few advantages:
- Performance. By requiring a power of 2 and allowing you to use a sub-area of the panel, cockpit regions avoid a lot of wasted computing that ATTR_cockpit can cause.
- Next-gen lighting. Unlike ATTR_cockpit, real 3-d lighting is applied to the panel when you use this attribute. This means that you will get a gradual decrease in light on your geometry (correct based on the angle of the sun) that matches the rest of the object.
Please note that you can mix and match which way you get your cockpit texture and whether you use the 2-d or 3-d panel feature (above) independently. However, you can only use ATTR_cockit or ATTR_cockpit_region in your airplane, not boht. ATTR_cockpit is still supported.
Generic Instruments
Generic instruments let you build instruments that follow some basic shapes (needles, tapes, etc.) that can be tied to any dataref. This both lets you customize particular instruments very precisely or create an instrument driven by a plugin dataref. These instruments are optional in version 9 – the old “premade” instruments are still supported.
New Datarefs
X-Plane 9 provides new datarefs targeted at airplane authors. The datarefs are better organized and have clearer names. But the old datarefs still exist, so legacy planes do not have to be updated.
Generally the entire cockpit should use only sim/cockpit2/ datarefs, and the plane exterior should use only sim/flightmodel2/ datarefs.
One special feature of these two sections: if your plane is used as an AI plane, these datarefs will animate the plane with the AI plane’s control deflections, not the user’s control deflections. So using these datarefs fixes the “AI animation” problem.
Plugins in Aircraft Folder
Version 9 airplanes may have a plugins folder (inside the ACF package) with fat plugins inside them. If you develop a plugin for your airplane, consider packaging it this way — this will allow your users to install the airplane with a single unzip for all platforms and no extra “drag-this-file-here”.
Plugins in the airplane folder is optional – you don’t have to provide a plugin, and plugins that are installed in the main Resources/plugins folder will still work. Still, I encourage you to use this feature because it makes the install process a lot simpler. The X-Plane SDK website will have documentation on fat plugins.
Liveries Folder
X-Plane 9 features a new “liveries” folder. Liveries (replacement exterior paint for airplanes and their attached objects) can be placed in packages in the liveries folder to greatly simplify the process of repainting an aircraft. See the “Example Plane-Widescreen+Objects” for an example.
While the liveries feature is optional, I strongly encourage anyone doing repaints to adopt it. Liveries can be switched by the user in the sim without any file manipulation; there is thus no risk of accidentally deleting or breaking an aircraft.
Large 2-d Panels
In X-Plane 9, a panel can be up to 2048×2048 in size. You pick the dimensions. The panel will scroll horizontally if necessary.
Note that if you use the new 3-d panel feature, the 2-d and 3-d panel do not have to be the same size. I would recommend a large 2-d panel (to fill large monitors) and a smaller 1024×1024 3-d panel (for performance).
Hiding Parts
X-Plane 9 will allow you to hide aircraft parts. Many v8 planes use OBJs to model the plane geometry, and use a transparent ACF texture to hide the ACF. Setting the parts to “not drawn” saves the CPU time that X-Plane would spend drawing the airplane, and is thus more efficient.
Keyframes
X-Plane 9 supports key-framed animation; this is useful for the scenery system, but for airplanes it allows for much more complex and realistic animation. OBJs that don’t have key frames still work.
Manipulators
This is a feature coming in the future: the ability to control how the user clicks and interacts with the cockpit object in detail. In X-Plane 9.0 we only support clicking on cockpit-textured geometry; manipulators will make features like draggable handles a lot more workable.
Global Illumination
X-Plane 9 does not yet offer a lot of control of the in-cockpit lighting environment; we’ll be working on this in future versions. These features will be opt-in…that is, you’ll have to change your model to get the new features, and old planes will work the way they always used to. It is likely that you’ll have to use “modern” airplane-building techniques to use these new features (meaning OBJs, named or custom lights, lego brick instruments ,etc.).
