We’ve been working on a single comprehensive document for aircraft authors – everything that changed in X-Plane 11. Jennifer has posted a draft here. This is still a draft, and we still have work to do, but there’s a lot already there, so we figured better to post it and let people comment and get started.
For entirely new features, we are creating separate articles on how to use them – it would be a little weird to have to look up “v11 aircraft checklist” to learn to use FMOD. This means that this document refers to some unfinished (and unpublished) documents that will be coming soon.
One of the changes listed in the document is that we changed the blending in X-Plane from blending in sRGB space to blending in linear color space. This is a universal change. It affects: all 3-d drawing, including everything drawn with an OBJ and the 3-d drawing of the panel texture. It does not affect:
- Plugin-based drawing in any 2-d drawing callback, including plugin UI drawing.
- Drawing into the panel (either via Plane-Maker instruments or plugin code).
In other words, your panel is composited in 2-d as it was before, but the usage of the alpha channel of that final panel texture is different.
How Am I Different?
The notes say blending is now linear and not in sRGB space. What does that actually mean, and how does it affect you?
Take a look at the color gradients in this blog post. (The whole post is really good, but the gradients show this issue). When you have a surface with intermediate alpha, you’re getting the intermediate gradient of the thing behind your surface and your surface’s albedo, with some fraction determined by the alpha.
As you can see from the chart, the intermediate colors are all brighter with the new linear blending. This intermediate brightness is more like what you would really see when working with translucent materials; the old model was losing light energy.
(X-Plane 10 was linear in the entire rendering engine except blending – we kept blending in sRGB space – it was very complicated and messy to do and hurt performance. So it was a priority to make things both faster, more correct and less insane on the code side for X-Plane 11.*)
What Do I Have To Do To Tweak My Textures?
Let’s get practical: textures with alpha will not look the same as in X-Plane 10, and while sometimes the new result is just better (light colored alpha-based lettering on panels almost always looks better in v11 out of the box), sometimes you’ll need to retune your alpha channel.
In pretty much every case, the new blending is brighter in intermediate values than the old one, which was losing light. (When we stop losing light, the net result is an increase in light.) So these cases will all involve ways to back off the brightness; you probably made things overly bright in X-Plane 10 to compensate for non-linear blending.
Here are a few typical examples we saw when exploring this feature with our art team.
Tinted Glass: tinted glass typically suffers from two problems:
- It’s just not dark enough.
- The tint color itself is too bright and now “shows” a bit, e.g. non-colored tinted glass looks light gray.
First: make the RGB of your texture darker if possible. Dark tinted glass should almost certainly have a black RGB (and use alpha for “how much” tinting).
Then: adjust the alpha as needed – if darkening the RGB didn’t do it, increase the opacity.
Painted Reflections: if you’ve painted reflections onto your glass, they may look too bright.
First: consider letting the engine be the reflection source – you may want to use BLEND_GLASS for cockpit glass and/or use metalness to increase reflectivity. Do these things first before editing albedo and alpha textures; they have a much bigger impact on your scene than the new blending mode.
Then: when done (or if you will not make these changes) decrease the opacity to turn down the reflections.
Dirt and Grunge: we found that our black markings on the ground looked too light – they were using alpha to anti-alias the edge of the marks and simulate pixels that contained a mix of dirt and the underlying surface in a single point. (This particularly matters when you zoom away from the marking and it becomes small on screen).
First: make sure your RGB channel contains correctly dark colors around the edges of the decal. (In what I’ve seen, artists pretty much always get it right in this case.)
Then: increase the opacity of the effect to make it darker (by emphasizing the dark decal more than the lighter pavement.
As a general rule of all of these, the RGB of a blended surface should be very dark (decals, tinting) or very light (fake reflections) and not be mid-range. Then the alpha can be made more opaque to darken darks or more transparent to darken lights.
* Nerd’s Nook: If you known enough OpenGL to be dangerous, you might be asking “Ben you idiot, why don’t you just turn sRGB blending off and on based on whether the content you are drawing is new to X-Plane 11 or old from X-Plane 10? You can just use glEnable!”
Sadly we cannot. In the forward renderer we might be able to toggle the blending mode per object or something, but in the deferred renderer (HDR mode), we blend all albedos together, all lit textures together (during G-buffer setup) and then we add the total lit to the total albedo during the single lighting pass where we apply the sun.
Basically we’re taking the math of the blending equation and rearranging the algebra. This rearrangement only works if the color space for adding the lit and albedo together is the same color space as every blending operation.
So for HDR to work, we have to pick a single blending equation sim-wide because we have to pick a single way to add lit and albedo together. For X-Plane 10 we picked sRGB color space and for X-Plane 11 we picked linear. Linear is a total win here – besides looking better in a lot of cases, adding lit textures to albedos looks better when done in linear space too. After all, we are adding light.
I just found a bug in beta 15 (and 14, and 13, and 12..etc.): if you use ATTR_shiny_rat or GLOBAL_specular with an intermediate value, e.g. between 0 and 1, you get an oily effect when HDR is off.
This is a bug in one of the shaders. We didn’t see it early because I have encouraged our art team to set the specular ratio to 1.0 and leave it there and use the normal map to modulate specularity. You should take that advice too! The GPU is really good at reading textures, and the CPU is not particularly good at interrupting the GPU to change what it’s doing, which is what ATTR_shiny_rat does.
Beta 16 will fix this; in the mean time, what you see in HDR mode (the top two FX settings) is correct, for the purpose of figuring out if your art looks good.
X-Plane 11.00 public beta 12 is out. A few notes on the engines:
- Jet engine thrust at low N1 should be fixed; you should no longer have to kill the ground crew to taxi around the ramp. If you find weird jet engine N1 behavior, please report a bug ASAP!
- Reciprocating props will need to have their idles adjusted, perhaps a bit higher, particularly if your idle adjustment is < 1.0 in Plane-Maker. We had to bump up our Cessna, which was set to about 0.8 and was stalling if not given a little extra throttle.
- The engine start code has some kind of bug that is stopping engines from starting.
If you’re hitting this last case, please file a bug and include the aircraft that won’t start.
From what I can tell, the beta 11 code is actually correct for some airliners, but is wrong for others. I’ll have more details later and I suspect we’ll have a beta 13 that addresses this by Tuesday.
In a previous post I noted that we weren’t attempting dynamic ambient occlusion inside the 3-d cockpit, due to problems of quality, availability, and because it wasn’t really better than what authors do now: prepare the AO offline using a high quality render in their 3-d modeler.
I’ve been thinking about this a while: while I like to get up on my soap box and shout that X-Plane is not like a first person shooter any time we get compared to a AAA console title, there is one case where X-Plane kind of is like one: inside the user’s aircraft.
First person shooters often specialize in rendering highly controlled, closed, constrained, claustrophobic environments in ludicrous detail at very high framerate. To achieve this, they take advantage of optimizations specific to those closed, controlled environments: lots of things are pre-computed, pre-baked, and pre-calculated.
X-Plane’s scenery engine mostly focuses on throughput; once you climb through 500 feet you can see everything at an airport, so we just try to draw really fast. But the inside of the aircraft is different. Baking at least part of the interior lighting is pretty much a standard practice. We provide object-kill datarefs to let authors script their own culling algorithms to squeeze framerate out of a confined space.* We define sound spaces within the aircraft that can change how sound effects are filtered.** We let you mark which parts of your aircraft receive interior and exterior light. (This feature is called “light groups” in a regular 3-d game engine and it’s very common, particularly in older forward-rendering engines.)
All of this stuff is a lot more like a game with a 3-d level editor than the rest of X-Plane. Techniques that focus on interior spaces are a good fit inside an airliner.
Better Baking: one of the features planned for our next-generation modeling format is to allow multiple UV maps for a given model***. We can then add an ambient-occlusion texture to an object’s shader and you can bake your aircraft interiors at a much lower resolution than you albedo textures.
For example, you could use a high-res repeating texture to draw the seats inside the aircraft, copy-paste the seat down the cabin, and then unwrap a second UV map that covers the entire cabin uniquely. Bake to this second UV map, down-size the texture to super low res (it’s ambient occlusion, “soft” is okay) and you’ll get high-res detail with unique correct lighting queues all over the aircraft. This is a standard work-flow for 3-d game engines and seems like a good fit for aircraft interior.
Edit in the Sim: we can take another clue from game engines and provide editing of graphical aircraft information inside X-Plane. We already do this for the particle system – the editor is built into the sim itself.**** The advantage of editing in the sim is that you can see your work exactly how it will look in real time.
* Engines that focus on interior spaces often have techniques like portal culling built-in and tools to precompute the information for this culling automatically.
** This is part of the new FMOD SDK – we will get this documented around or shortly after 11.0 goes final.
*** I realize this isn’t very “next-gen” in the world of rendering engines – it’s just the next major modeling revision for X-Plane.
**** The particle system isn’t documented because it isn’t quite finished yet. It’s shipping in mobile, enabled on desktop, but it is not running the default effects right now.
This has been a point of confusion for third party developers, particularly ones who were in the private beta (and saw versions of the sim that…cough cough…didn’t work right).
Screen space ambient occlusion (SSAO)*, when enabled by the highest rendering settings, only affects exterior objects. This means scenery and aircraft-attached objects marked “exterior” for lighting.
I tried SSAO in the cockpit interior, and it had a few problems:
- The scale for occlusion in the interior and exterior of the cockpits is really different – I couldn’t find one size for the effect that fit all cases.**
- When I went to apply the effect to our fleet, I found that virtually all of our aircraft already had occlusion baked into the cockpit by the artists. The dynamic AO thus provided almost no value and made the cockpit even darker than it already was.***
- SSAO only works at the highest rendering settings (and requires HDR to function at all), so if artists remove their baked AO, they’re taking a pretty big visual loss in a bunch of settings.
So in net, it just wasn’t worth going to dynamic AO in the cockpit. Our AO isn’t as high quality as what you can bake in a 3-d program (given a few days of rendering time), and it’s not always available.
The real win for SSAO is outside the aircraft, e.g. to cast AO around the wheels of the aircraft on the ground. That’s an effect that you can’t bake, and it helps a lot with lego brick scenery too.
* Nerd note: I’m pretty sure that what we do is actually HBAO
** We could, in theory, apply the effect twice with stenciling at two different scales.
*** The cockpit tends to be dark both due to errors in our approximation for indirect light (because most of the cockpit is in shadow, and thus only lit by indirect light) but also because cockpits are actually pretty dark compared to the great outdoors. But that’s another post.
OK the new engine modeling for X-Plane 11 is great, but what good is an engine to us pilots without a propeller?
X-Plane has historically done an excellent job of estimating the THRUST of propellers, typically to within just a few percent… but what about the SPIRALING SLIPSTREAM? This has been an area where X-Plane has been much weaker… I just don’t see any good solid references for determining the spiraling slipstream angles for propellers…
and it’s a real shame because the spiraling slip-stream hitting the vertical stab is so responsible for the left-turning tendency in single-engine props.
BUT, can we do better? How would we estimate the slipstream angle, exactly?
Well, as it turns out, there is a pretty darn cool way to do it, which is going into X-Plane 11 Beta-4: A spinning prop is just a spinning pair or trio or quartet of wings (as X-Plane has long understood) and those wings have LIFT and DRAG.
The LIFT from the propeller blade is referred to as THRUST. The DRAG on the propeller blade is what opposes rotation and makes them so darn hard to TURN. Read More
OK I overhauled and upgraded the jet engine model as well.
Here is how it works: For SUBSONIC dynamics, I curve fit maximum engine thrust ratio to static max thrust as a function of density altitude, Mach number, and engine bypass ratio. This is pretty easy and boring and I have been doing this for years.
But here is where it starts to get good: As the inlet is dragged by an over-speeding airplane above it’s critical Mach number, normal shocks will now form across the inlet, DECIMATING the efficiency of the engine and robbing you of thrust.
No arbitrary losses above your critical Mach number, the normal shock, only a few atoms thick, slows all air that hits it across the space of a few atoms, dumping a huge amount of the incoming streams valuable kinetic energy and turning it instead into HEAT.. the last thing you want coming into the front of your engine.
So that is for subsonic inlets being dragged above their critical Mach number. What about supersonic inlets?
OK this gets good: As we move through Mach 1, we transition from the subsonic curve fit for subsonic engines to the pressure-recovery of the total energy of the airstream. Here is where this gets interesting: The faster you go, the higher the Mach number of air incoming to the inlet, and the more energy is available from the airstream to turn into THRUST!
So, the faster you go, the more thrust you get! This is one reason that supersonic jet airplanes just keep speeding up, and up, and up, and up!
Planes like the F-4 Phantom, for example, take about FIVE MINUTES to get from Mach 1 to Mach 2 (a long time because the thrust only builds as the speed builds) but darn they hit Mach 2 and are still slowly accelerating!
Now, nothing this good lasts forever. At some point, the aircraft speed overwhelms the inlets’ ability to accept the shockwaves, and losses occur. We simulate this with a normal shock, and the inlet efficiency gradually moves from ideal (total pressure recovery) to the worst possible (normal shock) as the inlet moves to and then past it’s maximum allowable Mach number.
Here’s the equation for the losses across the normal shock, by the way:
const xflt gamma =1.4 ;
const xflt gamma_m1=1.4-1.0;
const xflt gamma_p1=1.4+1.0;
xflt nrm_shock_press_rat= xpow((gamma_p1 * sqr(M_use) ) / (gamma_m1 *sqr(M_use) + 2.0 ) , gamma /gamma_m1) // https://www.grc.nasa.gov/www/k-12/airplane/normal.html
* xpow((gamma_p1 ) / (2.0 * gamma * sqr(M_use) - gamma_m1 ) , 1.0 /gamma_m1); // normal shock total pressure ratio
So, if you open the F-4 Phantom in Plane-Maker, go to the engines window, and then the Jet Curves tab on the right, you will be able to SEE EVERYTHING that I just talked about.
On the left, at Mach 0, you see the static thrust for each altitude.
Then as you move right to Mach 0.5, the thrust falls as the turbine can’t deliver much ‘oomph’ due to the rapid inflow of air… like trying to climb a rope ladder while the rope is falling, trying to get thrust from an airstream always coming at you is simply an uphill battle that does not work too well. So the thrust FALLS as you speed up.
Then, above Mach 0.5 or so, something interesting happens: the energy in the oncoming airstream becomes significant, and the inlet starts decelerating that incoming airstream, using that deceleration to INCREASE the air pressure inside the inlet, which actually helps the inlet do the job FOR the engine! Now, that thrust starts BUILDING!
Now as we move to Mach-1, it’s crazy-time. The airstream pushing at the airplane is packing HUGE energy from all that speed, and nice, efficient, oblique shocks start capturing all that energy, slowing and pressurizing that air efficiently, and handing that high-pressure to the engine. A well-designed inlet at this point might develop MORE thrust than the engine itself… the job of the engine is simply to pressurize the inlet here. And, the faster we go, the farther to the right we move on those curves, and the greater the thrust becomes as we speed up. This is a recipe for an airplane that just never seems to stop accelerating. Enter the F-4. And the SR-71.
But, at some point, the shockwaves overpower the design of the inlet, and we start heading to the (terrible) efficiency of the normal shock. Here you see the curves dropping thrust hugely, on the fast-side of the max expected Mach number for the inlet.
So, you can see the thrust curves in Plane-Maker and now know what forms them. Set the reference Mach number on the lower left for you inlet on your plane to get the thrust peak right around the top speed for your airplane.
And then finally, MAXIMUM thrust is not the only thing here: We also need thrust variation with N1, and DRAG from the engine at idle at various speeds. Those things have been tuned and tested as well.
I have a full Citation Mustang POH with aircraft speeds and power settings, to test and tune the low subsonic flight regime for jets, and a recently de-classified F-4 Phantom Pilots Operating Handbook with subsonic and supersonic deceleration times (to tune the DRAG) and acceleration times (to tune the THRUST) to test and tune the high subsonic and supersonic flight envelopes of jet engines. All of the math above checked out very well with the POH’s for these airplanes… much of the accel/decel timing on the F-4 Phantom to within 1 second to get to and from various subsonic and supersonic speeds at full and idle thrust.
And a quick little detail: Low/high jet engine bypass types: GONE! Now we ONLY go off the bypass RATIO that you entered! This lets cool things like exhaust smokiness and engine mass for mass distribution all be floating point with bypass ratio for infinite variation, which is nice.
So, jet simulation has been improved now for V11, especially in the supersonic regime… because getting that F-4 PERFECT is just going to be soooooooo cool!
Thanks to a few hundred hours of flight experience in my Lancair Evolution so far, I am really improving the flight model in X-Plane in the area of PT-6 engines, electrical, and pressurization systems! And, while in the systems code, I’ve improved a lot of other systems simulations as well, which is always fun.
So, here is the new stuff done for 11.00 so far in the flight and systems modeling area! Read More
First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
- In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
- There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
- The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
- This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
- Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
- Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
- Yokes track via a 2-d XY manipulator.
- Anything that toggles or has only two states is a single click, particularly for small things.
- Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
- Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
Ondrej has posted a public thread about the new version of the Blender 2.7 exporter here.
The 3.3 release is the first release where we (Laminar Research) have worked closely with Ondrej to build what we hope will be one of the future cornerstones of modeling for X-Plane.
If you are currently using Blender 2.49 or AC3D, I expect that 2.73 will provide the best way forward for modeling in X-Plane.
The new release has a few major features, all aiming to create a new modern work-flow:
- All animation bugs are fixed. (At least,we think – if you find one, please report it ASAP!) This means animation is WYSIWYG. Armatures are supported for animation as well as animated data block containers.
- The exporter understands all modern OBJ features, including ones scheduled for release in X-Plane 10.50.
- Instancing is handled via a single option with exporter validation, so you don’t have to know how instancing works to get instancing.
- The material rules are validated, and materials are found automatically; you can simply model as you want and Blender will do its best to export it or tell you if there is a problem.
- Specular and Normal maps are ‘merged’ together from two separate sources. This lets you set specularity and normal maps in separate material channels in Blender for a more WYSIWYG approach. It also means no more messing with Photoshop to combine these layers.
The goal of many of these is to hide the idiosyncrasies of X-Plane’s modeling format and provide a cleaner, more artist-friendly view of modeling.
Regarding instancing: the model we have adopted is the one we used internally on the 2.49 exporter: you (the artist) tag an export as either “instanced” or not.
- If instancing is on, the exporter writes only data to the OBJ that will be hardware-instanced by X-Plane. If you do something that cannot be instanced, like animation, you get an export error telling you what you have to remove.
- If instancing is off, the exporter writes the object normally.
The win here is that you don’t have to know the (complicated) instancing rules; set instancing for the scenery objects you need to make fast in bulk (e.g. a luggage cart, a house, something that will be used many times in a small area) and you’ll get optimal output.
Optimization – Coming Soon
The goal of the 3.3 release was to set up an environment where authors could work using the new work flow. We have not finished optimizing the OBJ output.
If you are using the existing 2.7 exporter for airplane work, the output should be similar in performance. If you are using the 2.49 exporter, the new output is (like the current 2.7 exporter) not as well optimized.
In a future update, we will tighten up the generated OBJ code; this should not affect anyone other than producing better OBJs.
The new exporter should be fully work-flow compatible with the previous Blender 2.7 exporter; if you find your existing project does not work, please file a bug!
Our plan is to create a migration tool for Blender 2.49 projects; this will forward-convert the datarefs on annotations, manipulators, and object properties from 2.49 to 2.73 format. This lets authors using 2.49 move forward to 2.73 and have a migration path for existing content. (This work is not started yet, but is planned – we have our own aircraft we need to keep working on.)