3d cockpit HUD RFC

This is an RFC for a HUD system in the 3-d cockpit. It proposes ways for authors to create HUDs in 3-d cockpit objects.

12/19/08 – Initial Draft

Current Technology and Limitations

Currently, the HUD instruments in a cockpit are not rendered into the panel texture when a 3-d cockpit object is used. (For 921, a feature was added to render the HUD instruments into the default cockpit object for planes like the 777.)

Burning HUD instruments into the panel has (in the past) been limited to only a subset of supported OpenGL cards – some computers will simply not show the effect. There are alternate possible OpenGL techniques; we do not yet know their affect on fps for low-end machines.

921 does not render the HUD instruments into the panel texture because some existing planes (see: F-22) make the assumption that this will not happen — the panel region behind the HUD is mapped to the 3-d object in some way … often behind a 2-d HUD that is drawn when the plane is in 2-d forward view with the 3-d cockpit object visible. In this case, burning in the HUD gives us a double-HUD!

It turns out that EFIS instruments can be used like a HUD, and they will be rendered to the panel texture on capable hardware even in custom cockpits. This makes it possible to create a HUD-like 2-d system using existing instruments, albeit on only some hardware.

Instruments over transparency does not work ever with ATTR_cockpit_region – the cockpit region system was specifically designed with alpha omitted; processing alpha correctly in the panel texture requires a bunch of special processing and extra VRAM use in the panel system – the plan was: optimize the no-alpha case, ATTR_cockpit_region “tells” X-Plane that we can take these optimizations, and implement HUDs using a different technology (see below).

Clearly two goals can be gleaned from the above:

1. A HUD texturing system should not alter the look of existing planes or require authors to change their planes and
2. It should run on the widest range of hardware possible.

Possible Future Extensions

2-d Approaches

2-d approaches basically involve burning the HUD to the panel texture and then using it. Advantages:

• Simple.
• Works the same as the rest of the panel to authors.

Disadvantages:

• Potentially lower pixel resolution – HUD can appear aliased if a lot of panel texture isn’t consumed. VRAM inefficient.
• Potential performance problems, due to additional panel texture use.

Relaxed Rules

Under a “relaxed rules” scheme, we simply publicly recognize that dragging instruments into the transparent area of the panel is okay.

• An optional feature in the ACF would allow the author to specify HUD instruments are rendered to the 3-d panel.
• This option could wrok with HUD-type lighting.

The big problem here is finding a way to support the HUD being visible on older hardware. This might be possible for HUD instruments and generic HUD-lighting instruments.

ATTR_region_HUD

With this scheme, a panel region could be turned into a “HUD” panel region. Unlike regular panel regions, HUD panel regions would:

• Fully support alpha.
• Work correctly only with HUD instruments and generic instruments with “glass” lighting. (See HUD-type lighting below.)
• Not support mechanical or back-lit instruments, or non-HUD non-generic instruments.

The pros/consof this scheme are:

• Pro: Really simple implementation. Because it is so restricted in what goes into the HUD region, the sim doesn’t have to do a lot of work with all of the edge cases. This is a case that could run at near-full-performance on just about any hardware.
• Con: requires use of the ATTR_region system. This could mean rebuilding cockpits before the 3-d HUD can be used.
• Con: all the problems with a 2-d approach (e.g. VRAM use, etc.).

HUD-type lighting

In either case, should there be a “HUD” lighting mode for generic instruments? It would work the same as glass, but it would follow the HUD lighting level rheostat (and disappear when the HUD was off).

3-d Approaches

In a 3-d approach, the HUD is actually drawn during OBJ drawing. While the HUD itself is 2-d, it is being drawn as part of the virtual cockpit. Advantages:

• Really clean lines – lines are pixel perfect even at really huge zoom levels without a lot of VRAM. (BUT: if the HUD element in turn is based on a texture, we are limited by that texture’s resolution.)
• No requirement for panel texture usage – easier to adopt in existing planes, assuming any cockpit space is left.

Disadvantages:

• Unknown performance profile – might work well, might not.
• Unknown whether this would create a limit on what instruments could be drawn.
• Potentially incompatible with things like cockpit clicking, or putting cockpit texture over non-flat meshes.
• Potentially difficult or confusing to authors to have two separate ways to create panel texture.

direct_panel_rect

In this scheme, a new OBJ command would induce the OBJ system to draw a rectangular sub-section of a panel at an arbitrary 3-d quad location in the panel. This would “directly” map the panel to the HUD, without the use of a separate texture.