Category: Aircraft

More Aircraft RFCs – Landing Lights

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

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

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

One option (not really discussed in the RFC) is to do nothing at all.  Basically I hit upon this during some routine refactoring of the shaders.  The whole issue can be deferred indefinitely.
Why wait?  Well, I don’t believe that an incremental increase in the number of landing light halos is the future.  Our end goal must be some kind of truly global illumination, hopefully without a fixed lighting budget.  It may not make sense to add a bunch of complexity to the aircraft SDK only to have all of those limit become unnecessary cruft a short time later.
(I think I can hear the airport designers typing “why do the airplane designers get four lights and we get none?  Give us a light or two!”  My answer is: because of the fixed budget problem. We can allocate a fixed budget of lights to the user’s aircraft because it is first in line – we know we either have the lights or we don’t.  As soon as we start putting global lights in the scenery, we have to deal with the case where we run out of global lights.  For scenery I definitely want to wait on a scheme that isn’t insanely resource limited!)
Programmers: yes – Dx10 hardware can do a hell of a lot more than 4 global lights.  Heck – it can do a hell of a lot period!  For example, it can do deferred rendering, or light pre-rendering. A true global lighting solution might not have anything to do with “let’s add more global lights a few at a time.”
Posted in Aircraft, Development, File Formats by | 5 Comments

Liveries vs. Configurations

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

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

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

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

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

Files used by an aircraft fall into three broad categories:

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

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

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

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

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

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

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

Posted in Aircraft, Cockpits, File Formats by | 5 Comments

The “Airplane Modeling” Datarefs

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

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

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

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

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

Clean Naming

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

Array Sizes

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

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

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

Failure Support

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

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

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

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

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

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

Correct Multiplayer Behavior

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

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

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

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

What Dataref Do I Use?

Here’s the rule of thumb:

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

That’s all there is to it!

Posted in Aircraft, Aircraft & Modeling, Cockpits, Development, Modeling, Panels by | Comments Off on The “Airplane Modeling” Datarefs

ATTR_cockpit_region – Are We Confused Yet?

The choice of panels (2-d panel vs. 3-d panel) for your cockpit and the choice of OBJ commands (ATTR_cockpit vs. ATTR_cockpit_region) both affect how your 3-d cockpit looks.  Since these two techniques can both be varied, there are a lot of combinations, and 920RC2 does not have the right behavior.  (RC3 will fix this I think.)
2-d vs. 3-d Panel
The 3-d panel is a new flat panel whose purpose is to provide the image for ATTR_cockpit or ATTR_cockpit region.  Building a new panel for 3-d has a few advantages:
  • The instruments can be packed together – no need for windows or other texture-wasting elements.  This can help reduce panel size — panel size is expensive when using ATTR_cockpit_texture.
  • The 3-d panel can be smaller than the 2-d panel; having a huge panel feed the 3-d object is slow.
  • Instruments that are drawn with perspective in the 2-d panel can be redrawn orthographically, which is more useful for texturing real 3-d overhead panels.
Because the 3-d panel is meant only to be used as part of a 3-d cockpit object, spot lights and flood lights are not available, nor is a night-lit alternative.  Why not?
  • Such customized 2-d lighting would not match the rest of the 3-d cockpit visually.
  • We will eventually have a more global lighting solution.
Basically I don’t want to provide features that will clash with the future implementation and eat framerate!  The 3-d panel is aimed at next-generation content.
ATTR_cockpit vs. ATTR_cockpit_region
ATTR_cockpit_region provides a new alternate panel texturing path that gets rid of legacy behavior for improved performance and image quality.
  • ATTR_cockpit_region requires the region be a power of 2, which saves VRAM.  (If your panel is 1280×1024, then ATTR_cockpit rounds it to 2048×1024.  Yuck!)
  • ATTR_cockpit_region grabs the lit and unlit elements of the panel separately, and can thus provide lighting that is consistent with the rest of OBJ.
  • ATTR_cockpit_region does not preserve transparency (which isn’t a good way to model a 3-d cockpit performance wise) – removing the alpha feature improves framerate and saves VRAM.
  • ATTR_cockpit_region lets you pick out parts of a panel to texture only what you need.

This last point is less important now that we have 3-d panels (ATTR_cockpit_region came first) – it was meant to let you pick out a small subset of a large size 2-d panel, skipping windows.  But if, for example, you need more than 1024×1024 pixels of panel texture, two cockpit regions are better than one 2048×1024 – some graphics cards hit a performance cliff when a cockpit or region exceeds 1024×1024.

Expected Behaviors:
(Under all situations, the instrument brightness rheostats should be preserved correctly.)

ATTR_cockpit + 2-d panel:

  • The 3-d cockpit should look exactly like the 2-d cockpit.
  • The 2-d panel is used as source.
  • Panel transparency is preserved.
  • Spot/flood lighting effects are available and work.
  • Flood color is the forward flood color.
  • The panel texture and object texture may not look the same under some lighting conditions.
ATTR_cockpit + 3-d panel:
  • The 3-d panel is used as source.
  • Transparency is preserved.
  • Spot lights are not available, but flood flights work.
  • Flood color is the side flood color.
  • The panel texture and object texture may not look the same under some lighting conditions.
ATTR_cockpit_region + 2-d panel:
  • The 2-d panel is used as source.
  • Transparency is not available.
  • Spot and flood lights are not available.
  • Panel and object texture colors should match under all lighting conditions.

ATTR_cockpit_region + 3-d panel:

  • The 3-d panel is used as source.
  • Transparency is not available.
  • Spot and flood lights are not available.
  • Panel and object texture colors should match under all lighting conditions.

The Future

Basically both the 3-d panel and ATTR_cockpit_region are aimed at next-generation cockpits – they both strip legacy features to provide a clean platform for real 3-d cockpits.  The expectation is:
  • Global lighting will be applied to all 3-d geometry – panel texture and object texture. Non-emissive lighting (spot lights, flood lights) will apply to everything.
  • Windows will be built using geometry, not alpha.
  • The panel texture can be minimized by packing a 3-d panel and using regions.  Manipulators let you provide interaction to regular object geometry.

Posted in Aircraft, Cockpits, File Formats, Panels by | 1 Comment

3-d Cockpit Features (Someday)

I’m back from vacation and trying to catch up on email and close out 920.  I’ve received a number of emails regarding the 3-d cockpit, the big questions being:

  1. What can I do about the lousy lighting for 3-d object textures and 3-d panel textures via ATTR_cockpit_region?
  2. Can I use the new 2-d panel spot lights in the 3-d cockpit?

The answer is unfortunately “not much for now” and “no”.  Let me explain what’s going on with the 3-d cockpit and what we’re thinking for a long term strategy.

First, I try to organize my feature work around one part of the sim for each patch.  920 is a bit too big of a patch for us (featuring both a lot of cockpit/instrument work and some big rendering engine changes).  Austin has been on the road a lot this year, and in his absence I went a little nutty.  I wanted to do some work on the 3-d cockpit, but it’s different code, and with 920 in beta so long, this work will have to wait.
3-d Lighting
Our long term approach to the 3-d cockpit is “real 3-d lighting”.  By that I mean: multiple light sources, acting on all of the cockpit geometry based on 3-d positioning.  This means a few things:
  • Providing some way to specify multiple light sources inside the cockpit, as well as how they are controlled (e.g. how do you dim the flood light)?
  • Specifying which attached objects are considered part of the interior of the plane vs. the exterior.
  • Providing a way to provide emissive lighting vs. elements that must be lit by light sources.

The 3-d cockpit lighting environment must work the same for the panel texture and object textures.  This is necessary to keep the brightness of the finished cockpit consistent between the two textures sources.  With the current 3-d system (e.g. what you can do in 864) often the brightness of the panel texture and the rest of the object don’t match.

To this end, ATTR_cockpit_region, which is targeted at the new system, gives you the same lighting model for the object texture and panel texture.  Now that model isn’t very useful right now, but it will get better with future patches, and it will always be consistent.
Why Not 2-D Panel Lighting
We can’t use the new 2-d panel lighting features (spot lights), etc. because they are not scalable. Most of the advanced 3-d cockpits I have looked at use a lot of textures, quite possibly several 1024×1024 object textures, as well as a panel texture.
Now the panel texture is very expensive, so there is a penalty for letting it be any bigger than necessary.  Given this, we’d only have two options:
  • Provide the 2-d spot light features on the OBJ textures, effectively making them dynamic. This would be very expensive, performance-wise.
  • Have authors only use one huge panel texture.  This would limit them to 2048×2048 and be really slow.

If we don’t provide the spot lighting features for all panel textures then we have the problem of inconsistent lighting, which makes the feature fairly useless.

So instead I have withheld spot lighting (and _LIT replacement textures) from the 3-d panel; the cockpit object will instead end up featuring real 3-d light sources to create these kinds of effects in a 3-d correct manner.
The idea here is to avoid providing features that will be unnecessary, inferior, slow, or unsupportable in the future.  Otherwise such a “stop-gap” measure would just end up breaking existing airplanes.
So for now, the 864 system for 3-d cockpits still works as it always did.  It will be at least one more patch before 3-d cockpits get a serious upgrade.
Posted in Aircraft, Cockpits by | 4 Comments

Just What Is a Slider?

I’ve blogged in the past about the difference between key frames to animate changes to a dataref and key frames to animate an event. Simply put, key frames let you relate the position of your mesh to a dataref value, but they do not let you start a sequence of animations based on a change to a dataref.

In other words, you can make an aniamtion that puts the gear handle up when the gear dataref is 0 and down when the dataref is 1. If that dataref were ever 0.5 you’ d see something in the middle. (This dataref will always be 0 or 1 though.)

But you can’t use animation to make the handle slowly move from up to down over a few seconds when the dataref instantly jumps from 0 to 1. If the dataref moves instantly, so does your animation. There can be no time delay between the dataref and animation.

To get this “triggered sequence” effect, you need something else to detect the event and create a dataref that moves slowly. That something could be a plugin; X-Plane also provides a built-in mechanism: the “misc. slider”.

In an attempt to put the information somewhere useful, I have described the feature on the X-Plane wiki.

No Spare Datarefs (Usually)

In that last blog post I went on a rant about “spare” datarefs. Basically people would ask us to make some datarefs that did absolutely nothing, simply to wire parts of their panels and animations together.

And while I’m going off on a tangent about authoring and datarefs, we will not be adding any “spare” datarefs.

Well, the slider_on and slider_ratio datarefs are sort of “spare” datarefs – they’re 24 slots that have no default function.

I relented on my usual hard-line position on this (and a few other) datarefs for two reasons:

  1. These datarefs are tied to a real (albeit really simple) bit of simulation code – that is, the code that moves the sliders over time. We had to add these datarefs to make the slider mechanism accessible.
  2. Because sliders are an airplane feature, there is a logical scope: the person who writes the airplane gets to decide what the sliders do, and no one else gets to muck with them. (Since the cycle time is an aircraft file attribute, no one else could sanely hope to utilize them.)

I still maintain my original position that if you need a dataref that doesn’t exist at all, you should use a plugin to create it.

Someone in the X-Plane community can write a (really simple) open-source plugin whose sole purpose is to create trivial datarefs for aircraft use from a text configuration file, letting aircraft authors make as many datarefs as they need. (It is possible that this plugin exists and I just don’t know about it.)

Aircraft authors: to make sure that datarefs from differing add-ons do not have name conflicts, Sandy and I established a registry of plugin dataref prefixes. If you are going to add custom datarefs to your airplane, be sure to register a prefix, and only use that prefix. Do not start your datarefs with sim/XXX – that prefix is for X-Plane’s use only.

(Side note: the X-Plane SDK website has been under some kind of automated attack for the last week or so with lots of bogus user sign-ups. I haven’t had time to address this properly; if you are not registered on the SDK Wiki, I may not be able to approve new sign-ups for a few more days.)

Posted in Aircraft by | Comments Off on Just What Is a Slider?

Third Party Add-on Compatibility in 920

I am in Boston visiting family for the 4th of July, so there are a few compatibility bugs that I have seen but probably won’t be able to fix for a few days. Austin is still cranking out betas. So if new betas come out and these are not fixed, don’t panic – they are definitely on my todo list.

  • Sceneries converted via FS2XPlane crash on load. It looks like this is due to a bug in the new threaded texture loader – I think you can work around this by turning off “load scenery in the background” in the rendering settings (but then loads will be slow). I have found the area where the bug occurs but haven’t isolated it.
  • A user submitted a plane to us that crashes Plane-Maker on open – the panel code gets confused. I haven’t isolated it yet. If you have planes you’ve made, save the pre-920 versions!
  • I think Benedikt’s x737 plugin should start working again in beta 2.
Posted in Aircraft, File Formats, Scenery by | 1 Comment

New Panel Lighting

X-Plane 920 will have a pile of new panel features…this video shows the new “spot light” system. Basically you can define up to 3 gray-scale masks that define lit regions on your panel. 3 separate rheostats control the lighting levels independently.

http://www.youtube.com/get_player

I was excited when Blogger got its own video facility – saves me the hassle of keeping YouTube account active. Unfortunately the video quality is, well, “web-ish” at best. What you’re supposed to see is independent control of instrument lighting, panel and dash lighting, and flood lighting.

The performance hit is pretty tame:

  • The system works by recomputing the panel texture from sources when lighting or panel brightness conditions change. That doesn’t happen that often, so most of the time, the system costs nothing.
  • Panel layers are RLE compressed in RAM when not in use, so they aren’t that big.
  • If you have more than one core, the lighting recompute happens on the second core, which makes it virtually unnoticeable.

So the only case you’d notice this is if you crank the panel light rheostat really fast or fast-foward time (from light to dark) on a single-core machine.

Posted in Aircraft by | 6 Comments

What Goes Where

The moral of the story is: just because I dismiss an idea by email doesn’t mean it won’t get coded.  In particular, one user requested a generic instrument that could display text from datarefs.  While my initial reaction was “no way”, I ended up changing my mind.  The text instrument will be available in 920 – it displays a string as long as the input dataref is of type “data bytes”.  The first intended use is to let you build an FMC interface out of generic instruments – we’ll make datarefs that provide the display strings.

My initial negative reaction was due to the nature of the request: I get a lot of requests for “can you implement feature X in subsystem Y?”  One of the biggest questions about any feature is: where does it go within the maze of SDKs that X-Plane supports?  So if you specifically want it in a particular place, the answer is more likely to be no.
In particular, most people want feature X in the subsystem they are already using.  So 3-d modelers want a feature in the OBJ format, airplane editors want an ACF feature, panel creators want a new instrument, and off we go.
I can’t put a feature into the sim without considering compatibility, and the cost of compatibility goes way up if a feature is in the wrong place in the code.
Put It In a Plugin
A lot of the time my response is “a plugin can do that.”  Now I know that that’s a blow-off answer; plugins make all things possible, but they don’t make them easy.  Not everyone is a programmer.  At the same time, plugins often anticipate sim features by years: consider that the first planes to demonstrate key frames, 3-d cockpits, and per-vertex normals used plugins, with the sim developing the feature later.
My decision to include a text instrument is based on the idea that it makes sense to partition which “SDK” a feature goes with based on the nature of the activity.  As of this writing, custom systems modeling has to be done in a plugin – no other interface provides this.  But panels can be built almost entirely using the built-in panel editor; with 920 generic instruments provide a huge amount of flexibility.
So the purpose of the text instrument is to keep things this way – imagine that an artist is building a panel (using generic instruments) around the datarefs written by a programmer (using a plugin to do systems modeling).  Without the text instrument, the programmer has to write some graphics code (for the first time) and there’s one part of the panel the artist can’t manipulate.  This is a case where since the artist could already do 95% of the job, it makes sense to expand generic instruments so they can do it all.
(That’s not entirely true – there will always be custom displays so complex that they can only be programmed.  But the 920 generic instruments make most things straight forward.)
As a final note to the rant: we are not going to provide any systems modeling capability as part of generic instruments.  Generic instruments are how you visualize the simulation, not how you configure it.
To give a trivial example of why I don’t want systems modeling code in the generic instruments: it would be unfortunate if the pressurization model changed because the 2-d panel scrolled such that the pressurization instruments were no longer on screen!
Posted in Aircraft, Development by | Comments Off on What Goes Where

Perspective And Texturing

This is not terribly important (because X-Plane always does “the right thing”), but…what’s the difference between a trapezoid and a square that’s been tipped over? Well, consider the checkerboard below.

Note that in the “no-perspective” space the height of each row is the same; in the perspective case the bottom rows (which appear farther away) are less tall than the top ones. From a 3-d perspective, the middel image is the equivalent of stretching the square into a trapezoid; the right image is the equivalent of tipping it over a bit.

I mention this because PlaneMaker 920 will allow you to drag the corners of generic instruments to create perspective effects. When you do this, the positioning of the moving aprts follows the “perspective” pattern you see on the right. This means that if you make a trapezoid-shaped needle, the center pivot point of the needle will not be at the centroid of the trapezoid!

(Based on 3-d perspective it should not be, because the wide end of the trapezoid is “closer” – thus the center must be closer to the small side.)

Posted in Aircraft by | Comments Off on Perspective And Texturing