Terminology

X-Plane has two viewing modes for panels: a forward 2-d view that shows the 2-d panel and a 3-d view that shows the 3-d cockpit (which corresponds to the virtual cockpit in MSFS). Unlike MSFS, X-Plane does not provide multiple 2-d panel views – the 2-d side views may not contain working 2-d panels. X-Plane does not provide native support for popup panels, but it is possible to create them using a plugin or other tricks.

X-Plane’s panel consists of a background image (where alpha creates the transparent windshield) and a gray-scale or RGB overlay image that applies shadowing and some 2-d spot lighting to the panel. While MSFS has “gauges” X-Plane has “instruments” – the individual unit of placement.

Instrument Differences

The MSFS panel is created using an XML file; gauges can also be coded in C++ and can be in the form of *.dll or MSFS specific *.gau format.

X-Plane panels reside inside the ACF file in binary format (but can be exported as text from Plane-Maker); most panel editing is done using Plane-Maker’s near-WYSIWYG user interface.

X-Plane provides hundreds of types of instruments built in:

  • Pre-made instruments model existing real world instruments; X-Plane ships with a complete set of real world instruments for VFR and IFR flight. Limited customization is possible by replacing bitmaps, and tuning a few parameters.
  • Generic instruments provide basic “mechanism”, e.g. a needle that rotates, a button that toggles, etc. The generic instruments have a large number of customized parameters and visualize data from a “dataref” – that is, a sim variable from X-Plane itself or a plugin.

Therefore the closest thing to building gauges using the XML file is to build a panel out of multiple generic instruments. Typically a modern panel might be built primarily from generic instruments, but use the pre-built instruments for the moving map and a few other cases.

Custom Gauge DLL Vs. Plugin

While MSFS allows a custom gauge to be built via a DLL (where the gauge provides a bitmap of its 2-d image), X-Plane has a slightly more generic mechanism:

  • An airplane can contain one or more plugins.
  • Each plugin has full access to the X-Plane plugin SDK API – this includes building menus, custom UI and windows, creating and modifying sim variables, and drawing using OpenGL.
  • Often the generic instruments can be customized by feeding a dataref from your plugin into the generic instrument – that is, the generic instrument rotates the needle (and X-Plane does the drawing) but the animation is keyed to output from your plugin.
  • A plugin can also draw directly onto the panel – this happens on a panel-wide basis, not on a per-instrument basis. (This is how a complex custom nav display might be built.)

X-Plane does not provide a general mechanism to let an author “place” a custom plugin-drawn instrument into a panel using Plane-Maker; typically custom instrumentation is specific to a single plane. Where users have tried to build add-on instruments via plugins, they have had to create ad-hoc mechanisms to place those instruments.

The Virtual/3-d Cockpit

X-Plane’s 3-d cockpit environment is actually a rendering of the entire airplane in 3-d; all of the 3-d modeling work you do for airplane will be visible in the 3-d cockpit, allowing for the user to exit the VC and do a walk-around of the airplane. (See “Camera Restriction” below.)

Therefore the virtual cockpit is is simply modeled in 3-d using OBJ files, which contain meshes. Standard animation is used for instruments like steam-gauge airspeed indicators; this is similar to MSFS where a 3-d animation can be driven off of an animation source. Like MSFS, using “real animated 3-d” is often the fastest path for mechanical instruments.

X-Plane does have one “special” object (the “cockpit object”) that is intended particularly for VC work; it allows a 2-d panel to be UV mapped onto some 3-d surfaces, similar to using a material to indicate a 2-d panel mapping in MSFS. This work-flow is largely the same – you would create a snapshot of the “unwrapped” set of 2-d gauges (Plane-Maker can make this snapshot) and then UV map using it. The precise way to indicate “panel texture” depends on the 3-d editor you use.

Like MSFS, X-Plane provides a separate 2-d panel for the purpose of providing a material/texture for the 3-d virtual cockpit; therefore you can tightly pack this texture even if you want to ship a 2-d panel as well. In X-Plane, 2-d panels scroll and are often 2048 x 2048; it is important for performance to tightly pack the panel that is used in the 3-d cockpit.

Mouse-click interaction in the 3-d cockpit in X-Plane is annotated directly on the 3-d mesh; you mark a sub-section of the mesh with a “manipulator” describing what you want to have happen and the gesture. Typical manipulations include drags in 2-d or in arbitrary 3-d space, clicks, etc. Manipulations typically change an X-Plane dataref or run an X-Plane command (similar to an MSFS sim event) to affect the flight model.

Besides direct 3-d manipulation, you can mark any part of the 3-d mesh that has a panel texture mapped to it as “panel clickable” – this causes 3-d clicks to be passed through to the underlying 2-d panel, where the click operates as expected.

Things X-Plane Doesn’t Have Yet

Arbitrary Transforms

X-Plane can show and hide instruments but it cannot arbitrarily rotate or move them; there may be some XML transformations that are not yet possible in X-Plane. In many cases, a pre-built instrument will exist, and you can simply retexture it.

Things MSFS Doesn’t Have

Gradual Lighting Control

For any 3-d model in X-Plane, you can tie the level of the emissive (_LIT) texture using ATTR_lit_level, which arbitrarily scales the texture using a dataref. This has application for more realistic baked lighting, but can also be used to create gradual light faders in the 3-d cockpit or even to create instruments. (For example, the gear light LEDs can be made to appear by tying their lighting level to the gear status.)

Camera Restriction

You can restrict the movement of the camera in the 3-d cockpit by tagging a mesh as solid to the camera; this will stop your user from walking through the walls of the VC.

Use a hidden, simplified, manifold mesh to restrict the camera; the camera restriction will react better and use less CPU power with the simplified mesh.

You can use animations in your camera-restricting mesh. For example, if you animate the doors of your fuselage in the camera-restricting mesh, a user can exit the airplane only when the door is open.

See the default Cessna 172 in X-Plane for an example of this.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please do not report bugs in the blog comments.
Only bugs reported via the X-Plane Bug Reporter are tracked.