X-Plane 9 has a number of recent features to let you customize the exterior lighting of your aircraft; see the wiki for notes and a sample plane.
X-Plane 940 introduced the concept of parameterized lights to support these features. Here’s the basic idea:
Named lights (available for quite a while now) let you add a light billboard to your model that we define. The idea is that since the lights are specified against a real world model (this light billboard should look roughly like a landing light) it lets us upgrade art assets and back the light with the fastest path on the graphics card.
The problem with landing lights is that they are one-size-fits all, and this is particularly problematic for airplanes, where the lights can look quite different in size and angle based on the size of the airplane. Parameterized lights fix this by letting you specify a limited number of parameters in your OBJ. By limiting the parameters that you can set, it means that we can still optimize the light when possible.
I took a few minutes today to round out the list of parameterized lights, and I think there will be 9.46 patch in which we can release them*. When we put 9.46 in beta I’ll update the example plane; the new set of lights will give you parameterized control over the navigation and taxi lights, as well as the generics, beacons, strobes and landing lights.
* We have a few small bug fixes we’ll roll out in 9.46.
X-Plane doesn’t natively and directly support popup panels, but that doesn’t mean you can’t pop them up. Generic instruments have a dataref-driven set of show-hide fields. (The “filters”.)
Now what you might not have realized is: groups have filters too! So you can hide an entire group with one filter, and you can put premade instruments in the group.
So…even though the FMS is a premade instrument with no filter fields, by grouping it you can show and hide it.
Important: the backgrounds of instruments are not shown or hidden. So if you want to do this, customize the FMS to have a transparent background, and use a generic rotary to put a real background behind it. The rotary goes in the group, and thus it can show and hide.
One more tip: clicking in 2-d goes through one instrument to another, for historical reasons. So if you pop up an instrument, you might want to hide the instruments it popped up over so clicks don’t affect them.
I am trying to be disciplined and put documentation on the X-Plane wiki, and limit the blog to announcements, rants, and explanations of what’s going on inside X-Plane.
You can read about custom lights here. The short of it is that a custom light is a billboard on an object where you (the author) texture the billboard (with part of the object texture), pick the texture coordinates and color, and optionally run all of these parameters through a dataref* that can modify them.
For named lights, the light texture comes from a texture atlas that Sergio made a few years ago – it’s a nice grid 8×8 pretty lights.
So…why can’t you use it with custom lights? Why do custom lights use the object texture?
The answer is: future compatibility. Sergio and I are actually already working on a new texture atlas for the sim’s built-in lights. (This has been a back-burner project for a while … I have no idea when we’ll actually productize this currently experimental work.) What happens when we create a new texture atlas with all of the lights moved around and scrambled? If your object referenced that texture, the texture coordinates would be incorrect.
Thus, for the lights where you specify texture coordinates (custom lights) you use your own texture. For named lights (where the texture coordinate is generated by X-Plane) it’s safe to use ours.
A Dangerous Bug
I found a bug in 940 that’s been in the sim for a while now: given the right strange combination of named and custom lights in a row, the sim would accidentally use Sergio’s texture atlas rather than the object’s texture for custom lights.
This is a mistake, a bug, and it will be fixed in the next 941 release candidate. I certainly hope there aren’t any objects out there relying on this erroneous behavior, which violates the OBJ spec and is pretty dangerous from a future compatibility standpoint.
* Dataresfs are normally thought of as data we read, so the idea of using them to “process” data is a bit of a bastardization of the original abstraction. You can read about the dataref scheme in detail here.
X-Plane 940 has these generic light things…what the heck are they? Here’s the story:
X-Plane has been growing a larger number of independently simulated landing lights with each patch. We started with one, then four, now we’re up to sixteen. Basically each landing light is a set of datarefs that the systems code monitors.
- You use a generic instrument to hook a panel switch up to a landing light dataref.
- The sim takes care of matching the landing light brightness with the switch depending on the electrical system status.
- Named lights can be used to visualize the landing lights.
See here for more info.
But what else lights up on an airplane? Sergio sent me the exterior lighting diagram for an MD-82, and it would make a Christmas tree blush. There are lights for the staircases, for the inlets, on the wings, pointing at the wings, the logo lights, the list goes on.
We have sixteen landing lights, so we could probably “borrow” a few to make inlet lights, logo lights, etc. But if we do that, the landing light will light up the runway when we turn on any of those other random lights.
Thus, generic lights were born. A generic light is a light on the plane that can be used for any purpose you want. They aren’t destined for a specific function like the strobes and nav lights. There are 64 of them, so divide them up and use them how you want. Just like landing lights, you use a generic light by:
- Using a generic instrument to control its “switch” from the panel.
- Using a named light to visualize it somewhere on the OBJs attached to your airplane.
Generic lights don’t cast any light on any other part of the plane – sorry. You can use ATTR_lit_level to light up part of your mesh dynamically when the generic light comes on though – the effect can be convincing if carefully authored.
Normally I try to make the X-Plane scenery and modeling system as opaque as possible — I want to make sure that nobody ever actually uses the rendering features that I spend weeks and weeks developing.
But the other night I had a little bit too much to drink, got distracted, and posted these:
In all seriousness, I have been trying to find time to put more documentation up on the Wiki. For these features, you will find an explanation of how the planes work, as well as a link to the planes (with plugins) to download, and a link to the plugin source code (on the SDK site, with sample makefiles for 3 operating systems).
Plugins? Do not panic! While plugins are necessary for some of the features demonstrated here, others can be created without additional programming.
BTW, if the existing documentation uses a concept that is not explained anywhere, please email me. I sometimes leave holes in the documentation by accident.
Well, I won’t stop you from lying to X-Plane, but if you do, your add-on may have problems in the future.
Basically: some parts of X-Plane take measurements of real world information and attempt to simulate them. I have previously referred to this as “reality-based” simulation (e.g. the goal is to match real world quantities).
In those situations, if you intentionally fudge the values to get a particular behavior on this particular current version of X-Plane, it’s quite possible that the fudge will make things worse, not better in the future.
This came up on the dev list with the discussion of inside vs. outside lighting. X-Plane 9 gives you 3 global lights for objects in the aircraft marked “interior”, but none for the exterior.
Now there is a simple trick if you want global lights on the exterior: mark your exterior fuselage as “interior” and use the lights.
The problem is: you’ve misled X-Plane. The sim now thinks your fuselage is part of the inside of the plane.
This might seem okay now, but in the future X-Plane’s way of drawing the interior and exterior of the plane might change. If it does, the mislabeled parts could create artifacts.
So as a developer you have a trade-off:
- Tweak the sim to maximize the quality of your add-on now, but risk having to update it later.
- Use only the official capabilities of the sim now, and have your add-on work without modification later.
Javier posted a video of his CRJ on the dev list today. I have not tried the plane, but there is no question from the video that it looks really good. What makes the video look so nice is the careful management of light. Part of this comes from careful modeling in 3-d, and part of it comes from maxing out all of X-Plane’s options for light.
But…what are the options for light on an airplane? I don’t know what Javier has done in this case, but I can give you a laundry list of ways to get lighting effects into X-Plane.
Model In 3-D
To really have convincing light, the first thing you have to do is model in 3-d. There is no substitute – for lighting to look convincing, X-Plane needs to know the true shape of the exterior and interior of the plane, so that all light sources are directionally correct. X-Plane has a very large capacity for OBJ triangles, so when working in a tight space like the cockpit, use them wisely and the cockpit will look good under a range of conditions.
You can augment this with normal maps in 940. Normal maps may or may not be useful for bumpiness, but they also allow you to control the shininess on a per-pixel basis. By carefully controlling the shininess of various surfaces in synchronization with the base texture, you can get specular hilights where they are expected.
The 2-D Panel
First, if you want good lighting, you need to use panel regions. When you use a panel texture in a 3-d cockpit with ATTR_cockpit, X-Plane simply provides a texture that exactly matches the 2-d cockpit. Since the lighting on the 2-d cockpit is not directional, this is going to look wrong.
When you use ATTR_cockpit_region, X-Plane uses new next-gen lighting calculations, and builds a daytime panel texture and a separate emissive panel texture. These are combined taking into account all 3-d lighting (the sun and cockpit interior lights – see below). The result will be correct lighting in all cases.
Even if you don’t need more than one region and havea simple 1024×1024 or 2048×1024 3-d panel, use ATTR_cockpit_region – you’ll need it for high quality lighting.
The 2-d panel provides a shadow map and gray-scale illumination masks. Don’t use them for 3-d work! The 2-d “global lighting” masks are designed for the 2-d case only. They are optimized to run on minimal hardware. They don’t provide the fidelity for high quality 3-d lighting – they can have artifacts with overlays, there is latency in applying them, and they eat VRAM like you wouldn’t believe. I strongly recommend against using them as a source of lighting for a 3-d cockpit.
To put this another way, you really want to have all global illumination effects be applied “in 3-d”, so that the relative position of 3-d surfaces is taken into account. You can’t do this with the 2d masks.
The 2-d panel lets you specify a lighting model for every overlay of every instrument – either:
- “Mechanical” or “Swapped” – this basically means the instrument provides no light of its own – it just reflects light from external sources.
- “Back-Lit” or “Additive” – this means the instrument has two textures. The non-lit texture reflects external light, and the lit texture glows on its own.
- “Glass” – the instrument is strictly emissive.
You can use 2-d overlays not only for instruments but also to create the lighting effect within instruments, e.g. the back-lighting on a steam gauge’s markings, or the back-lighting on traced labels for an overhead panel.
2-d overlays take their lighting levels from one of sixteen “instrument brightness” rheostats. You can carefully allocate these 16 rheostats to provide independent lighting for various parts of the panel.
The 3-d Cockpit
The 3-d cockpit allows you to specify 3 omni or directional lights. These can be placed anywhere in the plane, affect all interior objects, and can be tinted and controlled by any dataref. Use them carefully – what they give you is a real sense of “depth”. In particular, the 3-d lights are applied after animation. If a part of the cockpit moves from outside the light to into the light, the moving mesh will correctly change illumination. This is something you cannot do with pre-baked lighting (e.g. a _LIT texture).
Finally, ATTR_light_level is the secret weapon of lighting. ATTR_light_level lets you manually control the brightness of _LIT texture for a given submesh within an OBJ. There are a lot of tricks you can do with this:
- If you know how to pre-render lighting, you can pre-render the glow from a light onto your object into your _LIT texture, and then tie the brightness of the _LIT texture to a dataref. The result will be the appearance of a glow on your 3-d mesh as the light brightens. Because the lighting effect is pre-calculated, you can render an effect that is very high quality.
- You can create back-lit instruments in 3-d and link the _LIT texture to an instrument brightness knob.
- You can create illumination effects on the aircraft fuselage and tie them to the brightness of a beacon or strobe.
There are two limitations of ATTR_light_level to be aware of:
- Any given triangle in your mesh can only be part of a single ATTR_light_level group. So you can’t have multiple lighting effects on the same part of a mesh. Plan your mesh carefully to avoid conflicts. (Example: you can’t have a glow on the tail that is white for strobes and red for beacons – you can only bake one glow into your _LIT texture.)
- ATTR_light_level is not available on the panel texture. For the panel texture, use instrument brightness to control the brightness of the various instruments.
I have a sample plane that demonstrate a few of these tricks; I will try to post it on the wiki over the next few days.
Let me set the record straight on this: you should not need to re-save an airplane to have it work in a newer version of X-Plane. If you have to do this, X-Plane is broken … please report a bug!
(In the case of 940 – there is a big fat bug – see the end of the post.)
Here’s a little bit more about what’s going on under the hood.
When Austin creates a new revision of the acf format (which happens in virtually every major patch), he handles backward compatibility with old aircrafts in one of two ways:
- He sets the default value of a setting to match the “unused” value in the old ACF file and sets this default value to match the legacy behavior. This naturally initializes all newly introduced functionality to its “backward compatible default” for old airplanes.
- Where this is not possible, he writes some conversion code that maps old ACF values to new ACF values. This mapping tries to re-create the old systems functionality as closely as possible.
This forward conversion code runs in two cases:
- When you open the airplane in Plane-Maker.
- When you open the airplane in X-Plane.
Plane-Maker will resave the plane in the newest format, with the automatic system updates in place. But this should not be necessary because X-Plane applies the same automatic process on airplane load. This is why you should not need to resave – X-Plane will do the upgrade “on the fly”.
Now about that bug…it turns out that 940 incorrectly updates 930 airplanes – the generator amperage is not correctly initialized. This is why 930 planes will run their batteries down in 940. (This bug was fixed in 941 beta 2, btw.)
What was strange was that, because of the way Plane-Maker’s code was structured, this code was failing in X-Plane but succeeding in Plane-Maker. This doesn’t happen very often (usually the code fails everywhere) but the result was authors noticing that their planes would start working if resaved in PM.
And that brings me back to the beginning of the post. If Plane-Maker can update the airplane but X-Plane cannot, that’s a bug! Please report it as such.
I want to make sure people realize that auto-update should work, and that resaving in Plane-Maker should not be necessary. Otherwise authors will start silently resaving their airplane instead of reporting the bugs, and we’ll never find them.
(Systems bugs sometimes only show up with a particular combination of systems settings. So while I do hope that we can catch all such bugs in beta, it is always possible that one peculiar model will induce a bug once the sim is released.)
There are a few changes to 940 regarding airplane lights…I will try to get some permanent documentation on the Wiki, but here’s the basic ideas:
There is a new “type” of light in the OBJ8 format, called a parameterized light. A parameterized light is somewhere between a named light (totally as-is, can’t be modified, simple to use) and a custom light (totally complex, can do anything, requires a lot of work). In a parameterized light, you control just one or two aspects of the light.
Parameterized lights are aimed at airplanes, not scenery, because typically parameterized lights are customizable and slow.* The goal is to give airplane authors some flexibility without having to invent a huge number of named lights.
Consider, for example, landing lights. A landing light could vary based on what switch controls it (we have 16 now), how big it is (many authors have pointed out that one size does not fit all) or how wide it’s view angle should be. (Lights that are inset in a structure might not be easily viewable from the side.) With a parameterized light, we can provide one light definition with 3 parameters instead of a huge matrix of lights.
Generic lights are a new collection of 64 lights that can be used for any purpose, sort of like misc wings, misc bodies, and sliders. The main difference between a landing light and a generic light is that the landing light halo won’t show up on the runway when a misc light is turned on. They are meant to be used for logo lights, inlet lights, etc. A series of new named lights will “listen” to the generic switches.
(Tip: combine ATTR_light_level with generic lights to have a light turn on and your lit texture appear at the same time.)
Finally, there is now a plugin override for the beacons and strobes (and in the systems model there can be up to 4 separate sets of beacons and strobes flashing at different times). With parameterized lights you can make two sets of strobes and use a plugin to control when they flash.
The combination of these three things let an author create an airliner that models all of the various lights and their behaviors.
* Slow needs some qualifications here. There are two code paths for lights, the fast and slow path. The slow path IS pretty fast, just not as fast as the fast path. The fast path is expected to be able to draw at least 10,000 lights in a single frame on low-end hardware, while the slow path is expected to be able to draw at least 500 lights per frame on low-end hardware.
500 lights is a lot for one airplane, especially if you have to place them by hand. And most modern computers will easily do thousands of slow lights.
Basically slow lights are not appropriate for scenery objects in the library that might be placed a huge number of times: OBJs attached to roads (e.g. street lights), OBJs used for buildings, taxiway lights. The are plenty fast for airplanes. In the X-Plane world, slow doesn’t really means slow, just slower than something else.
A quote from the .org:
I actually did try the demo before I bought it, and I found it sorta arcadish as I took off with a King Air 200 and performed barrel rolls on t/o lol! That kind of tuned me out!
I don’t mean to pick on that particular poster – we hear that a lot, particularly from people who use MSFS. Andy Goldstein points to Bob Hoover as a counterpoint.
More generally, the criticism is that since X-Plane will allow you to do things in commercial airliners that you’ve never seen in real life, X-Plane must not be realistic. And phrased like that, you can see the possible flaws in the reasoning:
- How do you know your control inputs match real life?
- How do you know the real plane is physically incapable of doing such a thing?
The first is the age-old problem of consumer joysticks – to really maneuver an airliner hard you have to put a lot of pressure on the controls – they put up a lot more resistance than a $20 SideWinder.
The second is an issue of falsifiability again – the absence of evidence is not evidence of absence.
Now in truth there are things that X-Plane models and X-Plane does not model. If you load up the airframe too much with fail-on-over-G on and the G limits are set correctly, X-Plane will start removing parts as you try to fly a 747 like an F-16. But we don’t necessarily simulate some of the internal things that might go wrong. For example, accelerations on the fuel system might potentially cause flow to the engines to fail, stalling an engine. I don’t know how much of this Austin simulates, but we certainly don’t simulate the geometry of the fuel lines and the fuel as a fluid flow. So there may be cases where a maneuver is impossible for logistic but not aerodynamic reasons (e.g. you could do it but you’d lose your engines).
With that in mind, here are a few youtube links:
- Bob Hoover flies a Commander like an aerobatic glider – thanks Andy!
- Roll an airliner? It’s safe, really!
- The 757 has a lot of power – thanks Andrew.
- I have no idea what happened here…I thought the Airbus computer prevents you from doing this kind of thing.
On that last video: the first time I flew with Austin in his Cirrus (this is before he traded it for a Columbia) he pulled the same maneuver: take-off, very slow rate of climb to pick up speed, and then: yank. Our climb rate was well over 2000 fpm in a single-engine prop for a while.
(Logistic note: please don’t interpret this post as an invitation to contact me regarding any aspect of the flight model – when it comes to the physics engine I am just another user, with no special insight. Physics is Austin’s domain, definitely not mine!)