Additive Lighting Equation
X-Plane’s “lighting” equation is fundamentally this:
albedo texture * external light level + emissive texture * internal light level
To define these components:
- The albedo texture is the “daytime” texture, used for an OBJ, airplane fuselage, or instrument. Typically it does not have a suffix. It contains an image of the object at its brightest during the day.
- The emissive texture is the “_LIT” texture, used for an OBJ, airplane fuselage, or instrument. The emissive texture typically contains the image of the parts of the object that emit light (e.g. light bulbs, neon signs).
- The external lighting level is the sum of all light falling on the object/instrument, etc. This usually includes the effects of the sun, and sometimes also landing lights or in-cockpit spot lights.
- The internal light level is the attenuation of the brightness the object/instrument is emitting. For example, the LED digits on a radio might have their brightness turned down by the user.
Additive Lighting in the Scenery System
Additive lighting has been available in the scenery system for a very long time via emissive textures.
- For older scenery file formats, X-Plane will automatically look for a texture with the suffix _LIT and use it as an emissive texture.
- For newer scenery file formats, there is typically a texture command (like TEXTURE_LIT) to define the name of the emissive lighting texture.
- Mostly the internal light level for emissive textures is determined by X-Plane. In 930, OBJ authors can override this light level using ATTR_light_level.
Additive Lighting for Instruments
In older versions of X-Plane, additive lighting was not available for instruments.
- Starting with X-Plane 920, generic instruments can use additive lighting – set the lighting mode for the instrument to “back-lit” and provide _LIT versions of the overlay textures. (The -1 overlay would be XXX_LIT-1.png, for example.)
- Starting with 930, any instrument can have additive lgihting – set the lighting mode to “Additive” for non-generic instruments.
- The panel background cannot use additive lighting – use generic instrument overlays to build emissive panel parts where needed. (For example, to make the labels for an overhead panel be emissive, you need to build them using a generic instrument overlay, like a rotary, rather than putting them in the background of the panel.)
- To get additive lighting in the 3-d cockpit, use ATTR_cockpit_region, not ATTR_cockpit!
Emissive Textures and Alpha Channel
The emissive texture (typically called _LIT or _LIT-1, etc.) usually does not need an alpha channel. Since the texture is added to the albedo (daytime) texture, a black pixel will have no effect. Thus no alpha channel is needed – black is the “alpha” of a LIT texture.
If there is an alpha channel for an emissive texture, how it is interpreted depends on context:
- For objects, if an emissive texture has alpha, the alpha is added as well. This means that an object can become less transparent when the LIT texture is visible.
- For airplanes, the alpha channel is ignored.
- For instruments, the alpha channel is not allowed – Plane-Maker will flag this as an error!
A tip on creating _LIT textures
Typically, your regular texture should have alpha while your _LIT texture should not. This would, for instance, be the case for an aircraft fuselage with transparent windows that is lit up the logo lights at night. The regular texture should use alpha to make windows transparent, while the _LIT texture should represent any lit parts of the fuselage over an opaque black background.
When creating emissive _LIT versions of your object textures, it’s important to know whether your textures have alpha channels or not. What’s a little confusing is that it’s possible for your _LIT texture too look perfectly opaque and still have an alpha channel which could cause undesired effects in X-Plane. How to avoid this depends on what graphics software you are using to create your textures.
To remove an alpha channel in Photoshop, you should select “Flatten image” in the layers toolbox before saving your _LIT texture. The result should be a single layer called Background. There is also a variety of image tools and graphics converters that allow you to save images with or without alpha.
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:
- A HUD texturing system should not alter the look of existing planes or require authors to change their planes and
- 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.
When developing art assets for X-Plane (specifically, any image file that will be attached to an X-Plane object, facade, or terrain overlay), note that the image must use powers of 2 in its resolution.
This means that an image can have a width or height (in pixels) of:
| 2 |
128 |
| 4 |
256 |
| 8 |
512 |
| 16 |
1024 |
| 32 |
2048 |
| 64 |
Images used with objects and facades do not have to be square; a facade image could have a resolution of 512 x 1024, or 1024 x 2048, or 2048 x 512, and so on.
However, images used for polygon overlays (such as orthophotos) have the additional requirement of being square. Thus, orthophotos may have the following resolutions (in pixels):
- 256 x 256
- 512 x 512
- 1024 x 1024
- 2048 x 2048
The only images that can be used in X-Plane without a power-of-2 size are those used in the 2-D panel/instrument system.
