Category: Panels

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

Why Don’t Skewed Instruments Skew the Background?

With X-Plane 9.20 you can stretch the shape of generic instruments, to create instruments that appear to be in perspective.  But why does this effect apply only to the overlays and not the burned-in backgrounds?  Two reasons:

  1. Some planes are made by cutting out photographs of real cockpits.  So the source imagery may already be distorted.  The current feature distorts only the moving parts that have to be dynamically distorted, but lets you use pre-distorted imagery from a photo.
  2. Our distortion might not be as nice as what can be done with high-end image editors like PhotoShop.  By pre-distorting the image you can get the best image quality.

And of course, the implicit reason 3 is that I’m lazy. 😉

Posted in Panels by | 1 Comment

Airplanes – How it Fits Together

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.)


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.


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.


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.).

Posted in Aircraft, Cockpits, File Formats, Modeling, Panels by | Comments Off on Airplanes – How it Fits Together

When Can You Not Use DDS?

There are a few cases where you cannot use DDS files in X-Plane:

  1. Airplane 2-d panels (any layer – base, lit, -1 shadow layer, 2-d or 3-d).
  2. Airplane instrument images.
  3. Bitmap-based region specification referenced in a library.txt file.
  4. Any gray-scale/alpha-only texture (e.g. mask files in the scenery system).

Beta 17 is treating cases 1 & 2 as an error; beta 18 will simply stop looking for DDS files in those cases.

Please note that airplane panels and instruments are not compressed right now, so there would be no performance benefit to using DDS in these cases. (If anything, PNG has smaller file size when compression is not used.) If we ever allow compressed panel textures, we’ll probably allow DDS panels at the same time.

Case 3 is just a particular version of case 4 – that is, the region bitmap is black and white (1 channel) so DDS provides no benefit. Use a gray-scale no-alpha PNG!

Posted in File Formats, Panels, Scenery by | Comments Off on When Can You Not Use DDS?

It’s Time to Try Nine

If you create plugins, airplanes, or scenery for X-Plane and haven’t tried your add-ons with X-Plane, please do so soon!! It’s much easier for us to fix backward-compatibility problems while we’re still in beta. Beta 14 introduced some bugs (that should be fixed in beta 15 real soon) but I think we’re reaching the point where you can do compatibility testing.

We’re working on a public Linux beta – see here.

Posted in Development, File Formats, Panels by | Comments Off on It’s Time to Try Nine

Don’t use the panel texture in a non-cockpit object.

Panels and airplanes aren’t really my thing. But we’re using the OBJ engine more and more in aircraft, blurring the lines between scenery code and aircraft code.

In X-Plane you can actually use the panel texture in any object. Pleaes don’t do this! There are two cases:

Airplane Objects

With X-Plane 860 you can attach many objects to an aircraft. But…you should only use the panel texture in the cockpit object.

The cockpit object is special! It is the only object that gets mouse-click tested. In the future we will decide how much of the 2-d panel to render to a texure (for the 3-d cockpit) based on the cockpit object. So…don’t use the panel texture in your other aircraft objects. Put your panel-textured triangles in the panel object.

(You should do this anyway; switching to the panel texture creates a new batch*, so using it in a lot of separate objects is bad for framerate.)

Scenery Objects

Technically you can also use the panel texture in scenery objects. This is really just a big hack — all of the issues with optimzation apply to this case, plus: how can you even know the layout of the panel texture in scenery? Don’t do this!

* “Batch” is the technical term in the game development and authoring world for a set of triangles that can be drawn by the graphics card via single CPU command. While graphics cards can process tons and tons of triangles, the number of batches they can process is limited by CPU and bus speed, which advance much more slowly. Generally the number of batches is the limiting factor in X-Plane’s framerate.

It’s easy to see how many batches your OBJ8 contains: open the file and count the number of “TRIS” and “LINES” commands at the end. Ignoring lights, the sum of the TRIS and LINES commands is the number of batches! (HINT: fewer is better, and only one batch is great!)

Posted in Cockpits, Panels by | 4 Comments