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!)
X-Plane 940 has a new electrical systems model and it has a few important differences from 930:
- You must specify exactly how many buses your plane has. 930 provided two buses but then did a bunch of cross-tying behind the scenes in case you didn’t have enough power sources.
- X-Plane 940 requires that each battery and generator be on exactly one bus.
- X-Plane 940 will not allow systems to be powered by non-existent buses.
Now this can have some strange side effects. Consider the default king-air with two generators and one battery:
- In 930 it has two buses, battery feeds both buses, and each generator feeds one. You could have systems split by bus and they would work unless you lost one generator and the battery.
- 940 defaults this plane to one bus, because on battery power only one bus will be fed.
- This means that in 940 all of your systems will be reset to bus 1.
But wait…if you import into Plane-Maker, the import will trash your system bus selections before you can increase the number of buses to 2. What can you do?
Here’s a work-around: before you update your plane, make sure you have two battery and two generator switches on your panel. Then open in 940. The import will set 2 buses and your systems will be preserved.
Of course, by the next few betas this may all be moot because we may get something less crazy in there.
When Sergio first proposed generic instruments, his model was “lego bricks”. The idea was to provide a number of very basic parts for panel makers and let panel makers mix and match. The result would be huge flexibility for airplane authors without code bloat.
The problem with non-generic instruments is that there is such a huge variety of behavior among airplanes…if Plane-Maker were to have options for every possible plane, the “special equipment” screen would require 3000 tabs and be completely unusable. Hence the need for a smaller unit of modeling: the lego brick.
The prop disc is the first feature I have done that is meant to be used only by a plugin, e.g. “lego brick” code. The X-Plane systems code sometimes suffers from the same “code bloat” problem as the instruments: a ton of very specific, very tweaky behaviors that interact in strange ways and become very difficult to manage. It’s not that the systems code is bad code – it’s that the scope of the problem is simply too large. That is, you can’t expect X-Plane to cleanly simulate the systems of every airplane ever in a ton of detail through an a la carte menu of check-boxes.
The idea of the prop disc is: someone (LR or otherwise) can write a plugin that encodes a certain style of prop disc. That plugin can then be picked up and moved around like a generic instrument between planes (perhaps with a corresponding text file to control it).
If someone else comes up with a different/better prop-disc algorithm, compatibility isn’t an issue…that person writes a new prop disc plugin and the airplane author selects the one desired. Think of it as sort of a portable flight model that stays with your plane.
So we win in three ways:
- Anyone can write the prop disc algorithm, not just LR.
- The code lives with the plane, to avoid compatibility problems.
- More than one plugin can exist, giving authors an a la carte menu.
That’s the theory at least.
X-Plane 940 allows plugins to customize the prop disc. Details here on the wiki.
I put these datarefs in so that modelers wouldn’t have to try to model prop discs with OBJs. The problems with prop discs are many:
- They need to be billboarded, and X-Plane does not provide datarefs for manual billboarding inside an airplane (particularly not to the engine’s coordinate system, which can be transformed by all sorts of fun stuff).
- They often need variable translucency, which OBJ does not have.
- They cause all sorts of depth buffer errors, which OBJs cannot manage.
In short, prop discs are weirdly special-cased enough that I thought it would be better to provide a general set of parameter datarefs for prop discs and let X-Plane do the drawing.
These options are not available in Plane-Maker. Why not? That’ll be my next post.
I have ranted in the past about the importance of not treating beta builds of X-Plane as having finalized file formats. Generally a beta should be used to explore, experiment, and test old content, but not to create new finished work or ship product. File formats sometimes change during beta to work around bugs we find.
Another reason not to depend on the file formats of new betas is that sometimes we screw up. In the case of 940 beta 1, the code that converts 930 airplanes forward to the new 940 electrical system is pretty buggy (hence the reports of electrical systems doing wonky things, panel instruments disappearing, and general weirdness).
This one is our bug to fix and will be fixed in beta 2 (at least we think). But to “get the fix” authors will need to open their 930 saved airplane in 940. If you already re-saved the airplane in 940 then the 930->940 conversion code won’t be re-run.
I’ll try to post some info on the new electrical system on the Wiki, but for now: if in beta 2 you have a bug with a plane that used to work in 930, send us the 930 version of the plane so that we can convert it and watch the conversion screw up. If the plane is already in 940 format we don’t know what our conversion code broke and what you edited in Plane-Maker.
X-Plane 940 now supports normal maps on OBJ models (both scenery and airplane). I’ll get more formal docs up once the rest of my office is moved and unpacked but here’s the details for now:
The normal maps are in “blender” format see here. The alpha channel is optional; if it is present, it serves to modulate the level* of specularity. Opaque means full specularity, transparent means none. You can use this feature to make some parts of an object shiny and some dull on a per-pixel level.
Shininess level is modulated by both ATTR_shiny_rat and the alpha channel, so you need ATTR_shiny_rat 1.0 and an opaque alpha channel (or no alpha channel) to see full specularity.
Normal maps are only available for objects and only appear if pixel shaders are on and per-pixel lighting is enabled.
Normal maps should be PNG format, not DDS – they will not be texture compressed because S3TC compression tends to kill them. (There are some modern formats for normal map compression supported by the newer cards but we don’t use them yet.)
* Specular level: most serious 3-d programs let you control both the specular exponent, which controls how “tight” the specular hilights are, and the specular level, which controls how bright they are. X-Plane only lets you control specular level; if specular hilights exist, they are always as the maximum exponent for the sharpest specular hilights.
With X-Plane 930 beta 8, we finally integrated the latest version of Max’s Cessna 172 SP. Grab the new beta and try it – he’s added a number of new features that demonstrate some of the newer X-Plane 9 airplane features.
- Real 3-d lighting in the 3-d cockpit. Note how the map light tends to illuminate only some of the cockpit as it fades out.
- 2-d back-lighting on all of the major steam gauges.
- A bunch of parts can now be dragged in 3-d, including the door handles. This is done via manipulators.
- Walls! In 3-d cockpit viewer mode you won’t be able to leave the airplane until you actually open the doors. The cockpit viewpoint is constrained.
- The model has the glass parts separated out for correct shadowing, and the glass works correctly from all viewpoints.
- Panel uses cockpit regions for accurate lighting.
The cirrus jet has been similarly updated. I plan to use the Cessna for a series of tutorials showing how to use these recent X-Plane features.
