We’re reaching the end-game with X-Plane 11.0 public betas. Right now I am working to try to solve three problems at once:
- Users of the beta really want to see rendering issues solved ASAP. Besides the constant chorus of “you know your sky looks like hell” in the comments section, the cloud code has serious performance tuning problems that I have been working on. We definitely want faster clouds in the next beta so it is a useful beta.
- We are trying to get the flight model locked down ASAP. We’ve received a number of really good bug reports in the last week and fixed a bunch of compatibility issues; the sooner we get those fixes out, the sooner authors can confirm their planes work.
- There are some issues that really need to be resolved in 11.0 because fixing them mid-version (where backward compatibility requirements are much stricter) is a lot harder.
You can see where this is going – those things are totally at odds with each other. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. If we don’t fix cloud perf, the build isn’t useful. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy.
I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. I also made some progress on cloud tuning last night; I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance.
(Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!)
I’m hoping to have beta 16 out Monday or Tuesday.
One Last Change
The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales.
X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.
The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would.
The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. if the knob is being driven by a custom manipulator or command or some internal plugin path.
This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent.
I have code that I am planning to put into beta 16 that puts the behavior back the way X-Plane 9 and earlier was: the value of these datarefs will be rounded to a grid only when Plane is done twiddling them. If you write to them with a plugin or manipulator, you’ll get exactly what you ask for – at least until the user touches a built-in panel instrument or command or some other pure X-Plane path.
This change is a little bit scary – there may be plugins or add-ons intentionally writing not-rounded values and counting on X-Plane to round them. This is a change that we can put in one beta and remove in the very next one if it turns out to cause too much chaos.**
But I am certainly hoping we can make the change – having X-Plane only round when needed makes a much better and more convenient interface for add-ons – add-on authors can get exactly what they want without having to wrestle with an octopus.
* Not impossible – just very difficult. To work around the problem, you have to inject your own values in a hook after X-Plane and manually track what the value should have been so that you don’t get fooled by X-Plane constantly snapping the value. There are a number of “unwritable” datarefs where you can write them by just shouting louder than X-Plane, but I strongly recommend against using this to make your add-on work. If you need to do this, contact us about what dataref you are fighting about – there might be a better way.
** This is going to be one of those cases where if one or two add-ons is broken by the change, we’ll declare it as “this is how X-Plane 11.0 is”, but if 100 add-ons are broken, we’ll put it back and I’ll have to go drown my sorrows. See also the usual joke about owing the bank $100,000,000.00 and all that.
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.
Changing Blending
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.
Just a quick note: beta 15 is up and fixes a few key bugs:
- No more Plane-Maker crashes opening files.
- ACF files aren’t locked while the sim is running.
- Cessna takeoff should be a lot better.
I’ve heard a lot of chatter about FPS problems with the new clouds. If you are having FPS problems with the clouds, here are a few key things we need for a bug reports:
- Include a log.txt. We get enough bug reports that if you ignore the “always include a log.txt” note in the bug report, your bug report will go to the back of the line. Everything that we tend to ask users that can be gathered automatically is in the log.txt: your CPU info, GPU info, driver, version of X-Plane, add-ons installed, scenery…there’s a reason why we want it!
- Be sure to note your monitor configuration (how many, how big, what you’re doing with them).
- Include a full res screenshot of the clouds where FPS are bad, preferably with the FPS counter showing. Please don’t use JPEG or crop it – I need to see what the rendering engine is doing.
- Try setting the weather to clear – does that improve FPS? Try changing your window size. Does that improve FPS? These differentials are useful.
- For a given view where FPS are awful, does regenerating the weather (bind a command key) change things or is it always bad?
- If FPS are always bad, send us a .sit file where, in the cockpit of an aircraft that we ship with the sim, framerate is really bad. We can load the .sit file, regenerate the weather a few times, and see what’s up.
- Update: one more thing – if you are using a third party aircraft, does changing to one of ours fix the issue? Does changing the shape of the 3-d cockpit (which blocks out clouds) fix the issue?
X-Plane 11.0 public beta 14 is out. This one is a bit of a two-steps-forward, two-steps-back. Some notes:
- You won’t need a ton of thrust to start moving anymore – Austin was able to remove that hack from the tire model based on some new ideas for modeling low speed tire physics that get around a years-old problem.
- The Cessna apparently wanders around the runway like a drunken moose.
- Max’s new cloud art is in. Under some views and conditions, you may get significantly better performance.
- Under other views, they may kill your GPU. I’m looking into this.
Most importantly, I broke Plane-Maker, so public beta 15 will be out in 24 hours, and I’m going to sit in the corner and have a time-out for a few minutes. If we have a fix for the Cessna in that time frame, we’ll ship both, otherwise I’ll get a patch out to fix Plane-Maker and we’ll get to tires soon.
The State of Various SDKs
SDK stands for software development kit, but the term is now used more generally for the various interfaces, tools, and file format standards to make add-ons of any kind for X-Plane, even if there is no program (software) involved. I’ve been getting a lot of questions about what’s safe to start developing on top of, and what’s going to be ready for third parties. Here’s a quick update on the status of some of the V11 SDKs.
FMOD + Sound
FMOD-based sound is one of the biggest new features for third party developers in X-Plane 11. Here’s the status:
- FMOD support is feature complete in public beta 14. Therefore we expect to have X-Plane sound “third party ready” by the time we go final with 11.0.
- There’s a lot to document about FMOD. I have already started the beginnings of full documentation, but it will take time to get it on paper. I’m hoping to have draft FMOD docs that you can use shortly after we go final.
- There’s a lot of details to get right in making an FMOD-enhanced aircraft; please do not ship an FMOD-enhanced aircraft before the docs come out – there’s a very high chance of doing something wrong if you’re just trying to guess how the system works from our Cessna project.*
When we ship, we will have bare bones tools for working with FMOD, but we will publish everything we had when we did the Cessna, and this setup is adequate for creating production aircraft. Fortunately, most of the work is done in FMOD Studio, a rich, full featured sound editing environment. It’s great to use.
The ‘thin’ side is X-Plane support: the sound attachment file (.snd) that links FMOD events to your aircraft has to be built in a text editor. We also have some graphical debugging and it is possible to attach a live mixer to X-Plane while you fly. All of this will be covered in the docs.
In the long term, we’d like to make the sound attachment system visual and have it run inside X-Plane while you fly.
What you can do now: learn how to use FMOD! Download the FMOD studio editor (it’s a free download) and start working with its sound design tools.
Graphics – Aircraft, Scenery and Modeling
I still have a list of graphic artifacts, but I think the overall operation of the new lighting system is as it will be for shipping 11.0. You can start using the new material model now; until the exporters have direct support, you can always add the NORMAL_METALNESS directive by a text editor or add it to a PNG comment.
Probably the biggest weakness of the new lighting model right now is the lack of detailed control over the interior of aircraft; I expect we’ll have new techniques to cope with this in future updates, but they won’t be mandatory aircraft changes. Unfortunately I don’t have good work-arounds right now for aircraft where the interior lighting is unacceptably weird.
What you can do now: tune the brightness and alpha levels of translucent textures – they need to be adjusted for X-Plane 11’s linear blending. Fix any panel problems introduced
Aircraft Physics and Systems
One of our biggest pushes right now is to try to get to “done” on the aircraft physics and systems code. The engines should be done – we don’t have known open bugs. The tire modeling is still problematic as of public beta 14; Austin has a fix for the bad behavior of the Cessna in beta 15.
What you can do now: test your aircraft’s physics model with X-Plane 11. If you have a fleet of aircraft, pick one particular aircraft and carefully update it for X-Plane 11. If you find out that there’s a physics problem after we go final, we’re going to have a lot less flexibility to fix things.
We run the physics engine on our own fleet (and we don’t use plugins to modify the physics) but that’s a limited set of aircraft. If you have good data about how your aircraft doesn’t work right with our flight model and good input data in Plane-Maker, we’d like to hear about it.
Weapons
The weapons SDK is the one area where we have moved temporarily backward from X-Plane 10. X-Plane 11 features a new unified weapons system that takes technology from both X-Plane 10 desktop (for physics) and X-Plane 10 mobile (for multiplayer simulation). Unfortunately, we haven’t had time to create an appropriate dataref interface to these weapons.
Getting the interface to weapons finished is on our short list for after 11.0 ships; I do expect that the list of datarefs may be different for 11.xx than it was for X-Plane 10. The new system has new capabilities that make the old “fixed index of weapons” model not a great fit.
Unfortunately, this means that if your add-on depends on plugin-controlled weapons, you’re stuck in a holding pattern until we can post a new interface that we can maintain.
Plugins
As of public beta 14, plugins should just work – we’ve closed the remaining plugin API and major dataref bugs. There are a few areas of fine print:
- You can’t use drawing callbacks in the map in X-Plane 11 – the totally rewritten map doesn’t use the same coordinate systems, so there is no way we can make old code work.
- Some datarefs and commands are not available in X-Plane 11. This is a normal part of the evolution of the sim.
- Multi-monitor support has a pile of bugs when you put X-Plane’s menu bar on the second monitor. If your plugin works normally except in this condition, it’s probably an internal X-Plane bug you’re seeing.
Note that to control toe brakes in X-Plane 11, you now need to set an override. Once you do, you completely own the toe brakes – you can look at the raw joystick input datarefs if you want to write a plugin that “processes” toe brake inputs to create some kind of effect.
What You Can Do: Check the command and dataref lists that are in Resources/plugins. If you need a command or dataref that has been dropped (and is not weapons related), contact us to discuss your use case and we’ll figure out what to do. If you are still seeing plugin bugs, file them now!
What we will not have done for 11.0 is entirely new plugin functionality to expose new X-Plane 11 specific features. We will need to do a major API revision to allow plugins to undock windows (like our GPS and map does), to expose some of the new FMS capabilities (expect a limited API) and to restore map customization functionality.
Particle FX
The particle system SDK is kind of done, mostly. We use it in the shipping mobile product, and the editor is available in the desktop product now. I still have two features left to do that Austin considers “must-have”; I expect to get them in shortly after we go final, at which point we can start providing documentation. (One of those features is the ability to control aspects of the particle system from multiple datarefs – that will change the UI enough that it’s not worth writing docs now and then changing them.)
My suggestion is to stand by on this – it won’t take that long to get the system to a “tinker with it” stage.
* I am quite impressed with how far some people have gotten without docs! But shipping an add-on that “seems” to work but violates the SDK rules makes a compatibility mess later.
Plugins can use OpenGL to draw directly inside X-Plane; this capability is almost fifteen years old and goes back to X-Plane 6. Plugin drawing typically falls into four categories:
- Drawing user interface (floating windows, HUD-like UI, map details, etc.).
- Drawing custom panel instruments (particularly 2-d glass displays).
- Drawing effects in 3-d (custom smoke or fire, or maybe diagram marks showing lift).
- Drawing solid stuff in 3-d (e.g. pushback trucks, parts of the airplane, etc.).
These first two use cases work pretty well; the third case works barely, and the last one is a bit of a train wreck.
Problems With Plugin Drawing
OpenGL an 3-d hardware was very different when Sandy and I created the original plugin SDK 1.0. Hardware had a fixed function pipeline built into the GPU itself, and your computer had one CPU core, so the issues I’m going to describe weren’t a problem back then. Here are some problems with plugin drawing:
- Increasing overhead just to draw. It used to be that we could just send a message to the plugin system at “good times” and let drawing happen. X-Plane now has to do a bunch of work to prepare OpenGL for plugin use; this synchronization work slows down X-Plane, and it’s getting worse as X-Plane’s internal design diverges from the canonical OpenGL 1.5 pipeline. (Example: we have to copy our matrices into the fixed function pipeline matrices before we call you, then copy them back if you call us with a drawing routine. Slow!)
- Plugins don’t have access to the fastest drawing paths. The less our drawing looks like OpenGL 1.5, the less efficient plugins are in comparison to X-Plane. This is getting worse over time too. (For example: if we want to render two VR eyes at once, we have to call your plugin twice, once for each one.)
- Plugins don’t have access to our lighting environment or G-Buffer formats, and thus can’t easily draw in a way that integrates with our 3-d world. This is getting worse as our rendering engine becomes more complicated.
So…this is not fantastic. The first two use cases (UI and panel) aren’t that badly affected because the two of them require only 2 or 3 call-outs to plugins, drawing in a very simple manner. The second two (3-d use cases) are quite problematic.
These costs are going to get worse when X-Plane moves to Metal and Vulkan drives; the cost of syncing over to OpenGL will be higher, plugins won’t even be drawing on the fastest APIs, and we may have to do some expensive texture synchronization.
Fixing The Problem
My goal isn’t to completely eliminate the costs of plugin drawing; rather just to minimize the costs by providing better alternatives for common tasks.
So in the long term, my plan is to add something to the SDK that we should have had for a while: the ability to create persistent object and effect systems in the X-Plane world.
Right now if you want to draw an object, you call XPLMDrawObjects – hopefully you’re doing this from just the right callbacks, but if you get this wrong, I forgive you; the rules for how to do this correctly in the v10 and v11 renderers are insanely complex, because the plugin API was invented fifteen years ago.
In the future, you will be able to simply create an object and X-Plane will draw it at all the right times, for any rendering mode, handling all of the special cases for HDR, shadows, reflections, you name it. You’ll just need to tell us when it moves. The same idea can be applied to particle systems for effects.
The one open issue with this scheme is how animation will work. Currently animations is handled by reading datarefs – if you want to animate multiple instances from a plugin, you have to figure out (inside your dataref handler!) which instance is being drawn and return the right animation values.
Not only is this a complicated mess, but it’s also slow; it requires us to call your dataref callback many times from inside the drawing loop, slowing everything down.
What I’d like to have in the future is some kind of ‘animation block’ where:
- Your plugin queries the object to find out which animation values it needs.
- Each time you update a particular instance of that object, you provide a packed block of the values of all of those animations.
- We use the block directly and never have to call datarefs.
This technique isn’t just faster, it also is easier to make multi-core and will play nicely when we can instance animation in the future.
The time frame for this is “during the v11 run hopefully” – that is, a new object API is not going to be in 11.0, and I can’t guarantee when it will be. I expect to support the old way (XPLMDrawObject and drawing hooks) at least through the entire v11 run, if not longer; our expected failure mode is ‘if you do it the old way, the sim might be really slow’. The new APIs will be designed to be completely friendly with multi-monitor, VR, Vulcan, and multicore.
X-Plane 11.00 public beta 13 is out, and hopefully it has restored engine operation that beta 12 broke. If you are developing an aircraft and your engines don’t work right in public beta 13, please let us know.
Posted in News
by
Ben Supnik |
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.
