That got your attention, eh? Sorry, this is not a tip on how to tune your X-Plane system; it’s a tip for aircraft authors to make sure their 3-d cockpits are running at maximum performance.
Prefill is when X-Plane blocks out the clouds that will be behind the airplane cockpit. The biggest cause of GPU slow-down is cloud rendering, so reducing the area that the clouds have to fill is really important.
In the 2-d cockpit, X-Plane pre-fills automatically. But in a 3-d cockpit, the airplane author has to specify which objects should be used to pre-fill.
Aircraft Authors: go watch this video or read this page to learn how to set up pre-fill in your aircraft! If you aircraft has a 3-d cockpit this optimization is very important!
We have received a number of bug reports on the livery system in X-Plane 10, as well as complaints from both users and authors about how the system works. This post describes what I am thinking for liveries; if this proposal seems hair-brained, the comments section would be a good place to counter-propose.
Two notes on UI discussion before we jump into the details:
- We hate check-boxes. If the UI debate is “which is better, UI A or B”, then the answer is pretty much never “let the user pick A or B with a check-box”, because the point of UI is to present the program in a human-friendly manner. Having two different UIs with selection forces the user to become the UI designer, which is inherently harder. So while we don’t have zero check-boxes in our UI, we really try to keep the ‘have it your way’ stuff to a minimum; X-Plane is a product for sophisticated users and if we put in a check-box every time we get a request for one, the product would be absolutely unusable.
- In arguing for UI, describe what you want to do, not how you want to do it. If you describe an implementation but we can’t do the implementation, the discussion is over. If you describe what you want to do, we can find several implementations and pick the best one.
Liveries Now
As of X-Plane 10.11, you can:
- Select your livery when you open a plane using Open Aircraft…
But you cannot:
- Change the livery without reloading the airplane, mid-flight.*
- Select your livery from the Quick Flight dialog box.
- Change your livery quickly (since a plane reload is slow).
- Change which livery the QF dialog box picks for you – it always pick “no livery” (that is, default paint).
These first two bugs go hand-in-hand. Because you have to reload the plane to change liveries, you lose the initialization that Quick Flight may have done for you.
* There is one bug to note: if you go to the open aircraft dialog box, select a different livery and hit cancel, X-Plane will change your livery on the fly but not reload the plane. Some users have noticed this and use it as a back-door way to change livery mid-flight.
For 10.20
For the short term, I am converting the bug in the Open Aircraft dialog box into a feature – the dialog box will have a “change livery and keep flying” button to change your livery on the fly, and the “cancel” button will not unexpectedly change your livery. Thus the functionality of the old “open livery…” v9 functionality will be part of “Open Aircraft.”
This isn’t perfect, but it at least addresses the issues of changing liveries quickly, or changing them while flying, without having to know about and use a hidden UI bug.
For the Future
There are more features we’d like to do in the future:
- Have a dedicated livery-change UI again – perhaps one that ‘floats’ over the main window while you fly, so that you can see the liveries as you click on them. This would be a quicker way to rapidly preview a large number of liveries.
- Remember the last user selected livery in the per-aircraft preferences (along with quick-look keys) so that if you go to open an aircraft and don’t do anything else, we can pick the last livery you used.
- Someday have ‘drill down’ functionality in the Quick Flight window so that you can set more detailed info about your plane (livery, weight and balance, fuel, weapons) and then go back to the main QuickFlight window. This is a long ways off though.
None of this is going to make it into 10.20 – I mention it only to explain where we’re trying to go – the change for 10.20 are designed to not interfere with this future work. The future work is all based on user selected livery choice, with preferences an easy selection.
Livery Choice in Plane-Maker
This finally brings me to livery choice in Plane-Maker. I have always considered this a bit of a weird feature; it is inoperative in 10.20 and we are looking to get rid of it permanently – that is, setting a livery in Plane-Maker has no use in any of the above plans. Our view:
- The first livery you see if you first open a plane for the very first time in QuickFlight will be the default one.
- Preferences should record the users choice of livery, and this should be done entirely from X-Plane. It should not be necessary to open Plane-Maker to change livery preferences, any more than Plane-Maker is needed to change rendering settings or joystick preferences. User customization should be 100% in-X-Plane.
As I said before in the top of this article, if this seems half-baked to you, please describe what you want to do, not how you want to do it. And please understand that when it comes to UI, less is more; we need to identify a small, highly leveragable set of UI options to cover a wide variety of features. We don’t want to have 6 ways to do everything!
This rather odd 747 picture is from a quick test I did to make sure the shadow options in Plane-Maker were working right after beating the shadow code silly with a hammer. The wing objects have been marked “interior only” for shadows, and since we are in an exterior view…the wings don’t cast shadows. 🙂
Now this is a totally silly way to use the feature, but there is a legitimate use: mark as many of your interior objects as “inside shadow only” as possible; for example, in the 747 the interior passenger cabin object can be marked as interior only – it doesn’t cast meaningful shadows on anything outside the airport.
By marking an object as no-shadow in Plane-Maker you save the sim the work of drawing the object, which is good for fps. If your airplane is used for an AI plane, this makes AI plane drawing less expensive.
In fact, you save it the work of drawing it multiple times. X-Plane using a shadowing technique called “cascading shadow maps”. Basically X-Plane renders different parts of the world at different resolutions, so that the closer shadows (that can be seen in more detail on screen) have a higher resolution. The user’s plane ends up being drawn in a lot of these rendering passes, and as a result the cost of high-geometry-count objects in an airplane can be amplified several times over by shadows. So savings in object-shadow count matter!
(Given the choice of turning off shadows in Plane-Maker or via GLOBAL_no_shadow, use Plane-Maker; it stops drawing earlier and thus saves more CPU.)
Conventional 3-d games like first-person-shooters and racing games are just full of cheats in the rendering engine. And that is not a bad thing! By cheat I mean they find clever ways to optimize performance that make the game look good while doing less work. The result: better framerate, better graphics.
I look at these games with a bit of envy because those cheats are often inapplicable to general purpose flight simulators for two reasons:
- The unrestricted viewpoint of a flight simulator is incompatible with a number of optimizations that on-the-ground or movement-constricted games can apply.
- Since a lot of our content comes from a third party, we can’t apply restrictions and optimizations across the entire set of content for the sim.
Despite these limitations, rendering-engine specific optimizations are beginning to creep into X-Plane as the engine becomes more powerful. These options and optimizations are unsurprising to anyone used to making 3-d game content but new to X-Plane itself.
What Is a Light Group?
Light groups are a cheatoptimization available in many 3-d rendering engines. The basic idea of a light group is that the author of 3-d content can create 3-d lights, meshes, and then specify which lights apply to which meshes.
There are two big advantages to light groups:
- Lights are expensive in traditional (non-deferred) rendering engines; by restricting which lights affect which objects, an artist can reduce the average number of lights applied to their 3-d meshes, which is good for framerate. (Using light groups to remove lights from objects that are out of the light’s range can be done automatically by a pre-processing tool.)
- Lights in games often do not cast shadows, either because the engine can’t support this (this is the case for X-Plane now) or just because shadows are expensive to generate. With a light group, artists can get correct results without shadows by simply marking geometry that is shadowed by the light as not in the light group.
As an example of the second case, imagine that you have two rooms separated by an internal wall and a powerful light source in one room. If the light source casts shadows, the unlit room will be dark because the entire room is shadowed by the internal wall. But if the lights do not shadow, the light from the lit room will “leak out” into the second room.
With light groups, an artist simply marks the second room as not being part of the light’s group, and the rendering engine doesn’t even consider the light. The dark room renders faster and has no incorrect light leakage.
Light Groups in X-Plane
X-Plane implicitly has two light groups: the exterior of the user’s aircraft, all AI aircraft and the entire world, and the interior of the user’s aircraft. In X-Plane 9, landing lights don’t light up the cabin interior, and the 3-d lights inside the cockpit don’t light up the runway or the landing gear.
In X-Plane 10.05r1 HDR mode was not supporting these light groups correctly; one obvious example was the Piaggio tail landing light spilling light on the cabin seats. This is now fixed in X-Plane 10.10. Just like X-Plane 9, your choice of “interior” or “exterior” for Plane-Maker objects matters for lighting!
Light Groups and Spill
What if you include spill manually by attaching a named light that casts spill to an object? What light group should the spill cast light on?
My idea to resolve this is:
- Spill lights attached to “exterior” Plane-Maker objects will be part of the exterior light group and only light up the aircraft exterior and surrounding scenery.
- Spill lights attached to “interior” Plane-Maker objects will be part of the interior light group and only light up the aircraft interior.
- Scenery-attached spill lights will light up everything. (Perhaps this should be “exterior” instead? I am not sure!)
For a non-enclosed aircraft (E.g. an old biplane with no cabin) you would not use the interior light group at all – everything would be exterior and all lights would affect everything.
If an aircraft has two light groups (interior and exterior) and a light affects both, you can simply include the spill light in two objects; the spills are cheap. This also means you could make effects. For example, if the spill light does actually light up the interior a little bit, rather than having the actual landing light blast the cabin with directional light, you could include an exterior spill for the landing lights themselves and a second interior spill that is omnidirectional, dimmer, and tinted, to represent the reflected light that makes it into the cabin.
I’m way behind on documentation, and there isn’t any documentation for this yet, but to clarify:
In the named lights list, spill (casting light on the ground and other stuff in HDR mode) and billboards (a square that faces the camera with a picture of the light from a light bulb) are always separate!
Typically the spill light has the same name as the billboard with an _sp suffix, or the billboard has _bb.
Why did we do it this way?
The lights are kept separate because:
- We do not have enough information from the billboards to know how to make a spill. For example, you have a v9 parameterized landing light billboard on your aircraft OBJ. How big (in meters) should the spill be? We don’t know! The billboard params never included enough information to know things like the size and cone ark for a spill light.
- There may not even be a 1:1 correspondence of spill to billboards. For example, any time there is a multi-lightbulb enclosure, it can be a win to use more billboards than spills; overlapping spills hurt fill rate.
Spills are therefore “opt-in” at the named light level; you opt in by adding a _sp variant.
Note that if you use Plane-Maker’s light level, you get spill for free; that interface is a higher level, simpler “I want this thing” type of interface. It only knows about the basic airplane light types, but it is fairly powerful. For example, you can create multiple landing lights (controlled by multiple switches), and you can use the “generic” lights for utility purposes, like inlet ice lights, leading edge lights, logo lights, etc.
If you haven’t run beta 3 and already been told so, X-Plane 10.10 beta 4 is out. Hopefully we have a beta stable enough for it to last more than 48 hours.
The ability to draw the inside of your Plane-Maker fuselage is going away. In X-Plane 10.10 beta 4 you will still see this geometry if your airplane uses it, but:
- There is no option to enable this in Plane-Maker anymore and
- If you save your airplane in Plane-Maker, the feature is turned off.
I’ve blogged about the path to removing a feature before; the basic idea is that we are not forcing you to update your airplane now, but the next time you go into Plane-Maker to do work on your plane, you will have to fix your use of interior geometry too.
If you really want your interior to look exactly like your exterior, but inside out, it’s not hard to get this effect:
- Export your airplane as OBJs from Plane-Maker.
- Open the fuselage in a 3-d editor and flip the faces.
- Attach your new “interior” in Plane-Maker.
Here’s the overall LR viewpoint on Plane-Maker and drawing:
- OBJs are the way to draw an airplane. OBJ provides all of X-Plane’s rendering features, really good performance, a stable file format, and good tools to edit.
- Visualization of the built-in Plane-Maker geometry is good for simple planes and experimentation, but it is not at all meant for serious graphic work.
- We will not be adding any of the new rendering features to Plane-Maker’s “built-in” drawing.
- We don’t think “I can’t draw X without an OBJ” is a problem; use an OBJ.
In other words, we’d rather focus our effort on a single drawing path, OBJ, and not invent a parallel, inferior second drawing system using Plane-Maker beyond what’s needed to simply say “there is my airplane.” Thus we are not adding new drawing features to the Plane-Maker geometry.
At this point the only thing holding up a public beta of 10.10 is, well, me. I am currently working on a set of related aircraft rendering bugs, and as soon as I can get the car off of jacks, we can go beta.
One of my goals or 10.10 is to close out the issues that stop payware authors from releasing final conversions of their aircraft to 10.10. By final, I mean conversions that won’t need any additional future editing. Right now X-Plane 10.05r1 has a few bugs that cause v10 to look different from v9, different depending on rendering settings, or just wrong. I want to fix those problems in a permanent manner so that authors can release aircraft and not worry about having to update.
Here are my goals for 10.10, roughly in priority order:
- Rendering should be consistent from X-Plane 10.10 onward through the rest of the v10 version run.
- Rendering should be consistent between HDR and non-HDR mode. Authors should not have to create two versions of textures where the HDR and non-HDRs offer the same capabilities. (In other words, while you might have to make two textures to bake lights when in non-HDR mode, you shouldn’t have to make two textures to correct for differences in color-correction between the two renderers.)
- Where possible, non-HDR mode should match X-Plane 9.
The switch of priority between item 2 and 3 is a fundamental change in priority from what I originally intended for X-Plane 10.
Originally I thought that the best thing to do would be to keep non-HDR rendering as close to v9 as possible, so that at least content would look correct with HDR off.
My new thinking for 10.10 is that we should aim for consistency between HDR and non-HDR modes. Realistically, an author is going to have to make at least a few adjustments in moving v9 content to v10; better to have the cost of rendering engine changes be borne out in a v9->v10 upgrade than to have every v10 airplane require double authoring to cope with HDR vs. non-HDR differences. In the long term, it’s best to not have v9 haunt v10 like a ghost years after authors are making exclusive v10 content.
Why is HDR Mode So Weird
This begs the question: why is HDR rendering so weird? Why does it look different from non-HDR rendering, and why doesn’t it look the same as v9? What did you guys do?
There are a number of changes to how we render in X-Plane 10, some specific to HDR rendering, and some sim-wide.
- The entire sim now works with a linear lighting equation. Basically when the sim performs lighting calculations on the GPU, it thinks in terms of photons and not colors, which produces more realistic results in most cases. With lots of light sources, linear lighting is absolutely necessary for combining those lights.
- The order of rendering operations is very different between HDR and non-HDR mode, and the formats that they render into (24-bit RGB vs. floating point, etc.) are very different. HDR is fundamentally a two-pass format.
X-Plane maintains two separate rendering paths for HDR vs. non-HDR and they are quite different in both what happens at each stage and when the stages occur.
Fixing some of the authoring bugs has required further changing the HDR pipeline to allow for correct rendering. The up-side of this change in pipeline is that the new one supports better HDR tone mapping and possibly even better fill rate performance. The down-side is that it’s a lot of complex code to touch and it may take a few betas to work out the bugs.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
X-Plane Can Make a Panel Image for UV-Mapping
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
Plane-Maker Will Tell You What’s Wrong
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
A quick OpenGL note for plugin authors: if your plugin uses OpenGL to draw (e.g. for a plugin in an airplane that draws a custom glass display) you should:
- In debug mode: always check the OpenGL error state (using glGetError) at the end of each draw callback that you handle. X-Plane will not leave OpenGL errors around, so any error is yours. (To verify that it’s not another plugin, just add a glGetError at the beginning of the callback.)
- In release mode: never check the OpenGL error state, as it can slow down the driver.
An OpenGL error often implies that an OpenGL command did not complete as expected (because a param is bad, etc.) and this can mean that you are not cleaning up OpenGL state for X-Plane!
(And of course you should always use XPLMSetErrorCallback in debug mode to catch plugin errors. Set a break point in your callback to see exactly where the error occurred.)
A number of third party authors (bravely) promised X-Plane 10 updates to their airplanes. And I believe that a tune-up to be X-Plane 10 compatible isn’t going to represent a lot of man hours.
That is, unless you try to do this job now.
I have a number of open bugs where version 9 airplanes don’t load quite right in X-Plane 10. If you have an X-Plane 9 airplane and you try to work around these bugs, a few things will happen:
- You will only be able to work around some of the bugs, as others are pretty hard-baked into the sim.
- When I actually fix the bugs (in the next weeks) your airplane will be “broken” yet again, since “fixing” the bugs now means trying to make a right with two wrongs.
So third party authors: please do file bugs if you haven’t already, and give us a little time to work through them. Please do not try to work around these bugs, only to have your airplane become “re-broken” when we get the sim corrected.
And users: please be patient with your third party airplane authors. They can’t make their plane v10 compatible until we fix some bugs, and if they try they’re just going to get thrashed.
There are some things that do need to be reworked for version 10, particularly for HDR mode. But a lot of the reports I get are just things that are funky in the sim.
How to File an Airplane Bug
Since I am getting deluged with bug reports, support requests, questions, etc. I want to describe the best way to get an airplane compatibility bug to us. By following these guidelines, you’ll make it easier for us to kill off compatibility bugs fast.
- Please file the bug only once. If you have filed the bug and haven’t heard that it’s fixed, you do not need to tell us in every new beta that it is still broken.
- File bugs via //dev.x-plane.com/support/bugreport.html. We can route this form to whomever we think is best suited to handle the bugs. Please do not just email the last person you conversed with directly.
- Please only file bugs if an airplane looks different in the latest X-Plane 10 build and X-Plane version 9.70. X-Plane 9.70 is the version 9 release that we are targeting – no older version!
- Please get us reproduction materials – preferably a complete ACF pack, and preferably a cut down one if it can be simplified.
- Send us the v9 .acf file, before any modifications. We want to see what your customers would have seen if they just tried to use the plane. If you send us a version resaved in X-Plane 10, we don’t know what happened.
- Please provide illustrations of how the plane should look in version 9 vs how it does look in version 10. We need a reference point.
- Please try to keep reproduction steps as short as possible. If we have to make a 2 hours flight with 400 waypoints to see a bug, that’s a time sink for us.
A number of you have already sent us good bug reports – we will get to them as quick as I can. If all goes well tonight my fires will be out and I’ll be able to jump into this shortly.
