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.
I’m not sure if these will make it into X-Plane 9.30 (we’re trying to close down features, but it doesn’t do much good to hold off features that help people make airplanes) but…while I was in Italy I created a few more manipulator types.
The set of manipulators let you change the value of a dataref directly with a mouse-click – the various flavors control how the dataref is changed.
These manipulators are the natural corollary to the command manipulator, which runs a command on a click.
Why have both? Commands are good, but they don’t cover 100% of sim functionality (just like datarefs don’t cover 100% of sim functionality). By having both, it will be possible to control switches and buttons that are best accessed by a dataref change.
For the basics on commands vs. datarefs, see
here.
The generic instruments already write to both commands (via the trigger instrument) and datarefs (via the rotary instrument) – these new manipulators provide the same functionality for 3-d cockpits.
X-Plane’s panel system does not have true “masking” based on a bitmap. You can clip an instrument to its rectangular region, but most masks are made by overlaying another layer or instrument on top of the moving parts. Examples include the circular mask for the moving map and the outside of the artificial horizon dial.
If you are using ATTR_cockpit then what you see in the OBJ is just like what you see in the 2-d panel, and the masking problem is simple: pick a mask that matches your background. In particular, if the back of the panel is black, your mask must be black; if the back of your panel has a gradient, the mask must contain a copy of a slice of the gradient.
But there are two cases where this rule does not work the way you might expect.
Masks for 2-d Spotlights
The 2-d spotlight textures (panel-2, panel-3, etc.) have a strange property: they light the background of the panel (the “burned in layer”) per-pixel but the overlays are lit per vertex. This is a cheat to keep the frame-rate high.
Normally this is not a problem – the moving parts are small and look different enough from the background that the lighting mismatch is not visible. But if you have a mask in the 2-d panel and spot lights, it will not match!
Unfortunately there is not much you can do about this. The only thing you can do is to keep the spotlight color uniform over the entire mask region.
Masks for Cockpit Regions
When you use ATTR_cockpit_region, the lighting model for your 3-d cockpit changes: instead of drawing the panel (as you saw it in 2-d), X-Plane calculates the albedo (day-time) and emissive (“_LIT”) components of the panel separately and then combines them with real 3-d lighting.
The good news is that the spot light problem is no longer a problem. Since the spot lights are 3-d and are applied to these final “panel textures”, a mask that matches the background will blend perfectly.
But in order to mask, you need to know which part of the panel texture you are masking (albedo or emissive!). If you are masking the albedo texture (e.g. a mechanical artificial horizon), create a mask that looks just like the panel background.
But for a glass instrument, the moving parts go into the emissive layer. Your mask must be pure black! Where did I get that from? The emissive layer adds light to the object. Black is an absence of adding light. So pure black ‘erases’ any light-only elements (which include all glass EFIS instruments, etc.).
One nice thing about this strategy: you can build a custom glass instrument (with a black mask) and put it over any background. This means you can reuse your art assets no matter how they are positioned on the panel.
I have said this before, but now it’s finally true: new file specifications are subject to change in the middle of beta!
In particular ATTR_light_level has changed slightly from beta 7 to beta 8. If you are using this feature in your objects, you will need to update your objects.
A new ac3d beta will be posted later today that supports the updated syntax.
You can read about the syntax here.
Propsman caught something:
…is modifying the value of a batch of ATTR_light_level tris comparable [performance-wise] with toggling the state of a backlit generic instrument? Instinct tells me that you must have the latter more streamlined than the former, but maybe not?
He is right: in the current implementation, ATTR_light_level is probably a bit more expensive than using generic instruments. This may not be true in the future though.
- The generic instrument code is pretty tight.
- Right now ATTR_light_level sometimes has to adjust shaders, which can be expensive.
- In the future, ATTR_light_level has the potential to be very heavily optimized, while the generic instrument code will always be CPU based.
But to put it in perspective, all instrument drawing is slow compared to scenery drawing – in the scenery world we draw 50,000 triangles of identical OpenGL state in a row, and modern cards do that very, very well. In the panel, we have to put in a lot of CPU time to figure out how to draw each quad or tri-strip. Fortunately you probably don’t have 50,000 individually programmed flashing lights in your panel. Heck – there’s “only” 3608 datarefs published by the sim.
Perhaps other questions are important when picking ATTR_light_level vs. panel texture:
- Which is more useful: to be able to have several variant images and variant images that are not “lights” (this is only possible by generics) or the ability to vary the light level gradually and not just have on or off (this is only possible with ATTR_light_level)?
- Which is simpler to author given the rest of the panel?
In other words, it’s all pretty “slow”, but fortunately “slow” isn’t that slow. If your light has to blink, you may want to pick what looks best and is straightforward to author.
I have been trying to put documentation on the X-Plane Wiki, and use this blog for announcements and “the inside story”, rather than letting the blog turn into a poor-man’s users manual. An aircraft developer asked me via email whether there was a blog entry on some of the pitfalls of the v9 panel lighting system. There is not, and the lighting system is under-documented. I will be working on improving the documents over the next few weeks, but the point of this blog entry is: “how did we get here?”
I am a huge fan of incremental software improvement. That’s the subject of another blog post (perhaps on another blog), but for now I’ll say this: all changes to the rendering engine since version 8.0 have been incremental ones, and yet if you were to look at the code, you wouldn’t see a series of band-aids taped on top of each other. Each incremental change leaves the rendering code “fully updated”, as if it had been written yesterday. I start each new scenery feature by first reshaping the existing code into the most useful form for what we want to have in the future, and then coding the new feature is relatively simple.
But this strategy has an Achilles heal; if the code being refactored has a public interface (whether it is a file format or programming API), then all of the intermediate steps in the journey become requirements for future products in order to maintain backward compatibility.
This is not a problem as long as the programmer knows where he is going. The danger comes when one of the intermediate steps is actually a step in the wrong direction, and becomes dead weight around a future design.
A Reasonable Progression: OBJ
The OBJ 800 file format has had a reasonable progression* since its birth in version 8. It has gained a number of new features, but each one has generalized and made more powerful previous ideas, such that “legacy behaviors” are not so painful. Some examples:
- Hard surfaces may now be decks (e.g. you can fly under them) or not, and you can specify what kind of hard surface you have. The original hard surface command was simply “it’s hard” or “it’s not”. But viewed under the lense of the new scenery system, that old hard surface command implicitly implied “the surface is smooth” and “the hard surface is not a deck”. So the new hard surface command is a more general version of the old one, which continues to work under the new system.
- Animations in version 9 can be key framed; in version 8 you simply specify start and end values. But start and end values are just like having two key frames. So viewed under the lense of the new scenery system, all animations are key framed; older objects always just have two key frames. The new key framed commands are a more powerful, more general version of the old ones.
I can’t say that the relatively pain-free evolution of OBJ files over the last 4 years comes from good design or genius on my part – in truth it’s probably just good luck. But I think one thing has helped me keep the new OBJ extensions relatively sane: most of them are conceived several months before they make it into X-Plane.
I have a scenery system to-do list that will last me at least another four years; most of it is filled with things that Sergio has asked for. This to-do list acts as sort of a road map for future scenery system extensions; for any possible OBJ change, I can look at it relative to the other todo items and ask: “is this extension going to play nicely with things to come?”
(As a side note, this is one of the reasons why there are not light maps in any of the X-Plane modeling formats. Light maps don’t play well with a number of other scenery system extensions. I want to resolve the conflict between these future additions before they go into the sim.)
Wandering In the Desert
By comparison, the evolution of the panel system in version 9 has been more like wandering in the desert than a straight line toward a goal. Repeatedly, I put features into the panel system without a clear roadmap of where we would end up or how they would work together. The result is what you see now when looking over the panel documents: complexity and chaos.
Basically there are several major changes to the panel system that affect each other in strange ways:
- A more complex lighting model on the 2-d panel in version 920. (That is, the 3 2-d spot lights, and generic instruments with back-lit, mechanical, or glass lighting.)
- A more complex lighting model in the 3-d cockpit in version 930. (That is, 3-d spot lights, ATTR_cocpkit_region and generic instruments with back-lit, mechanical, or glass lighting.)
- A separate panel used only to provide texture to the 3-d cockpit. (That is, the 3-d panel.)
The problem is the order that they were invented: first ATTR_cockpit_region, then the 3-d cockpit, then back-lit generic instruments, then 2-d spot lights, and then 3-d spot lights.
The result is two sources of confusion:
- Some combinations of features simply don’t work together. Since all of the features appear to be independent, I sometimes get bug reports on these. For example, you can’t use the 2-d spot lights on the 3-d panel. This is not a bug, it is by design! I will explain why some of these limits exist in future blog posts.
- Among the remaining combinations that do work together, there are a lot of choices about how to structure a plane – too many choices!
This second point is a tricky one: X-Plane has to continue to support whatever set of features was available for any given release (864, 900, 920, 930) so that older planes continue to work. But some of those combinations (e.g. the ones that exist in version 900) don’t make a lot of sense for new planes made in 930.
I am open to ideas on how to solve this. I intend to document a “correct formula” for a modern plane, perhaps with tutorials, on the Wiki. I am also considering programming Plane-Maker to flag unusual combinations of features as a warning when saving 930 planes.
Either way, I fear I’ve learned my lesson from the panel system: incremental improvement of code is only a good idea if the programmer knows where he is going! Next time I will use Google Maps. 🙂
* I suppose that whether you think the OBJ 800’s evolution has been reasonable depends on your standards for file formats. OBJ 800 absolutely does show growing pains. I would only say: consider the number of revisions and the change in the hardware platform OBJ 800 feeds when you consider its stretch marks.
I thought I had already blogged about this, but I can’t find the old posts, so here goes. The big question: why can’t we have “X” in the OBJ file format or as part of generic instruments?
I get a lot of requests for “more power” in the OBJ or generic instrument system – the ability to play sounds, to do simple math operations on datarefs, more show-hide filters, the ability for a generic instrument to change a dataref in response to another dataref instead of a mouse click.
And invariably I say “No! Go write a plugin!”, which I realize is a fairly rude thing to say to a non-programmer. First, let me explain why I say no, and then what we can do about this.
Keeping Systems Separate
These feature requests fall into two broad categories: “systems programming”, which is really anything that has a side effect (play a sound, change a dataref, apply some logic), and “visualization” (e.g. a user needs more flexibility to better visualize the sim’s state.
I definitely do not want any kind of “systems modeling” code inside OBJs or generic instruments. To give a trivial example: imagine that you could make a generic instrument that would set the generators to on when the landing gear is raised.
What then happens if this generic instrument is off the bottom of the screen when the landing gear is raised? Does the generic instrument get to perform its logic? Both OBJs and generic instruments are fundamentally “visualization” systems – both will short-circuit for performance when they are not visible. If we put systems modeling code into them, then the sim has to evaluate a potentially large number of otherwise unimportant (non-visible) objects and instruments to do system behaviors.
In computer programming, there is the notion of a “model-view-controller” design. The basic idea is to keep the code that changes the model, the model itself, and the code that lets the user see the data model, all separate. Keeping them separate keeps operation consistent – the model does not change its behavior depending on how you look at it, which is very important for consistent simulation.
So for all systems modeling, my answer is always the same: not in viewing code!
Expressions and Visualization
Some requests are simply requests for more visualization complexity – there is only so much you can do with key frames, animation, and a few filters.
I do have to admit that on some level, it is perfectly reasonable to ask for infinite power to visualize data in OBJs and generic instruments.
On the other hand, there would be a real cost to having programming-language complexity in what are otherwise relatively simple-to-use parts of X-Plane (e.g. the simplest model is just an export from ac3d…). My solution for both problems (systems and visualization) is a scripting system, but in the case of visualization, it is about not reinventing the wheel and keeping complexity limited to one place (the scripting system).
Scripting
Plugins have the power to solve all of these problems – they can change almost any aspect of the sim. But they are also very difficult to create; you need to be a programmer who knows a language like C or Pascal, and you need to know how to use the development tool for each platform you want to support. That’s a huge amount of specialized knowledge just to customize a few systems.
Basically we need to have a line in the sand. At some point, when the systems to visualize information (OBJ, generic instruments) are not powerful enough, we need to make programming easier, rather than make modeling and authoring more complex.
What we need is a scripting system. The scripting system would provide a relatively simple text-file syntax to do simple scripting of systems and instruments for airplanes.
Such a scripting system should be implemented as an open source plugin; it should not be built into X-Plane. The advantage of this would be:
- Anyone could improve or add features to such a scripting system, not just Austin and myself.
- People could freely customize the scripting system as needed for specific projects.
- By having the code be part of a plugin and not the sim, backward compatibility would be improved – even if the “official” version of the scripting plugin changed, you could always include an older version with your plane that worked exactly the way you want.
Who should work on this scripting system? I don’t know. Probably not me — I am not very good at making simple systems; see also what a complex disaster the panel and instrument system has become!
When a user requests that I add a feature to the generic instrument system, there is an implicit request – that Austin or I take programming time to do the feature. So for now I can only say that if/when I take time to do some of these feature requests, it will be in the form of a scripting system, not as extensions to the generic instrument and OBJ systems. This will give us better long-term compatibility and extensibility (via an open source plugin) and will keep systems modeling code separate from the visualization system.
930 will have some new options for attached objects. One is to declare a “glass” object. When an object is declared to be glass, it is moved to the very end of the drawing order – even after the cockpit object.
The idea of glass objects is to let you make translucency that works from any view angle. To make multiple layers of glass, the trick is to use pairs of one-sided triangles. The glass (visible from the inside only) goes first, then the glass (visible only from the outside) goes second. All of this goes into the object with the “glass” property in Plane-Maker.
One side benefit of the two-triangle approach is that the inside and outside of the windows can be tinted differently.
Having glass objects does three things for us architecturally:
- It takes pressure off the interior cockpit object. The interior cockpit is the only object that can have manipulators, so texture space in the interior cockpit object is quite valuable. By allowing translucency in an attached object, you can put your window textures somewhere else and save texture space for the cockpit object.
- It gets around the current weirdness where the interior cockpit object is drawn last but the exterior cockpit object is drawn first. The glass object is always drawn last. Period.
- It sets us up someday for some kind of shadowing scheme in the cockpit. This is a bit pie in the sky, but most pixel-based shadowing algorithms go a bit bonkers on translucent geometry; by flagging the whole object as “glass” we can simply omit it from shadow calculations.
The 921 draw order has the exterior cockpit object drawn first (if drawn) and the interior cockpit object drawn last (if drawn). This made sense at the time – the exterior cockpit object was being used primarily for a pilot figure, with windows in the ACF paint – so it had to be drawn before the ACF fuselage. The interior cockpit object has to be drawn last because the coordinate system is changed to a super-close-to-the-user coordinate system that has to be drawn last.
Now that there are attached objects, people are modeling a lot more of the airplane, the usual approach is to have all 3-d present all the time, so that a roaming camera won’t reveal missing parts of the airplane.
I have found the cause of a rather serious bug in Plane-Maker: sometimes instruments disappear from the hierarchy (but are still visible in the main window).
The problem is that the cut-paste facility, when used with multiple-instrument selections, was corrupting the hierarchy information. Because of the way instrument hierarchies are managed, this corruption persists – even if it isn’t visible. So if you manage to ungroup everything, it looks okay until you work more, then the instruments disappear again!
This is a really bad bug of mine, particularly since a panel is such a time investment. Here is what we’ll be able to do in 930 to get around this:
- A new “flatten panel” command simply ungroups everything and completely cleans the hierarchy. All corruption of hierarchy is fixed with this command, finally exposing every instrument. From that point on, you can then re-group and things should be okay.
- I am fixing the cut-paste commands to not trash the hierarchy, and I am looking for any more hierarchy-corruption problems.
- 930 has export/import of instrument groups to text files. So another way around instrument corruption problems would be to export the panel to a text file, fix the grouping problems (which is a matter of moving the GROUP/END_GROUP lines) and then re-importing. If you do not have a selection, the entire panel is exported, including any hidden items in the hierarchy.
I believe that text-based panel import/export will also be useful for sharing individual instruments (or clusters of grouped generic instruments), archiving work, and making large-scale changes using search-and-replace.
These two issues have been discussed a lot in the forums, so I thought I’d mention them:
First, I finally found and nuked that star-burst pattern in the rain. It turns out that for some textures, compression was destroying the lower res
mip-maps, causing the geometry that the rain drops are drawn on to show up as that starburst pattern. It should be fixed for 930 beta 1.
Second, it turns out that the code that converts the 900-format generic instruments to 920-format generic instruments* was being run on the user’s airplane whenever a multiplayer airplane older than version 920 was being run. That could cause generic instruments to disappear, appear incorrectly, or just crash the sim, because the aircraft data in the user’s plane (once the user is flying) is already in 920 format…if you interpret it as 900 format again, you get non-sense.
I am fixing this for 930 beta 1; there may be other bugs relating to multiplayer and generics, so we’ll see if this fixes most of the problems, or others crop up. The panel system is essentially “global” (that is, there is one panel for the user in all of x-plane) but the instrument data is per-plane…so there is always a risk of code mistakes where the multiplayer planes affect the user’s panel.
When will 930 beta 1 be out? I don’t know. Hopefully pretty soon – when bug fixes make it into the blog, we’re usually in the push to get to beta. But I’m working on features on a few fronts, so it’s hard to say which ones will be done first.
* X-Plane 920 revised the ACF format from version 900. The file format for generic instruments was pretty much completely changed to accommodate new features like key frames. 920 has code that converts the 900 generic instruments into 920. For example, simple key frame tables are built out of the older offset-scale parameters per instrument.
