X-Plane 11.02 should be out this week; we’re down to one bug, whose fix I am verifying now. There have been a number of questions about performance, so to start, here is some info on three things we’ve done to make 11.02 faster than 11.01.
8-bit Water. The dynamic FFT-based ocean wave textures we stream in X-Plane 11 are floating point textures in 11.01 (F32 on the CPU, F16 on the GPU). This was an easy decision for getting the tech working, but as it turns out, transferring the textures to the GPU is slow, particularly on the NVidia drivers.*
For 11.02, Sidney has rewritten the shaders to cope with 8-bit waves. The results look almost the same, but the amount of data transferred is 4x smaller, and more importantly, 8-bit RGBA is the path most likely to be handled well by the driver, so this should be a win.
Sidney also wrote some code to transfer the textures asynchronously, but we’re holding off until 11.10 for that, as it may require debugging or behave weirdly on some drivers.
Faster Car Bucketing. The cars have always cost more CPU than they should, and profiling indicated that 90% of the work was in moving the cars around in our scenery system as they drove. The code to “rebucket” them has been modified and is now significantly cheaper. We are not turning the car density up yet (it’s not that fast), but at this point with the cars at the highest setting we ship, they now take 2-3 ms total to compute, which means they have no frame rate impact. I’d like to bring the density up in the future if we can get further performance wins, which I think we can.
Better Core Scheduling. If you’ve been reading carefully, you should be shouting at the screen about now about how the hell something that takes 2-3 ms total is “free” – 3 ms means that if you were running at 60 fps you’re down to 50. That’s not free?
I am declaring the cars free because they now run in parallel to the flight model, and it’s very likely that the total flight model work takes at least 2-3 ms, even without AI planes. The third optimization is a big cleanup of the multi-core scheduling that we do within a frame.
X-Plane uses multiple cores both to load background scenery as you fly and to speed up some calculations within a frame. As of now, the major “per frame” multi-core computations are:
The flight model (if you have more than one aircraft – we can’t multi-core a single plane).
DSF scenery maintenance (not super expensive, but does get multi-core acceleration).
Car computation (typically uses 1-2 cores at most).
FFT water calculations for the next frame (uses up to four cores).
X-Plane 11.01 was not scheduling these particularly well – here’s a picture.
What you’re seeing is X-Plane kicking off the FFT water too early, and that work blocks X-plane from completing AI aircraft calculations. The big red bar up top is the sim waiting (and FPS dying) because the AI planes weren’t done in time.
(The bottom ‘track’ with nothing on it is an IO thread that’s waiting in case we need to do UDP I/O. Since I had IO off, it is efficiently sleeping. This profile is on a 4-core machine so we couldn’t have stuck work down there.)
Here’s 11.02:
We start the (newly optimized) cars as early as possible so they complete at about the same time as the flight model; we get all DSF work done immediately, and we don’t start water until the very end. In the meantime, the main thread is free to go do the actual frame rendering.
This is just an incremental step for multi-core use; we have been steadily adding more multi-core work for the last few years, and we’ll be adding more in future X-Plane 11 updates. For example, X-Plane 10.50 re-structured the renderer, separating the work of discovering what to draw (“culling”) from the work of actually drawing. In X-Plane 11, we can do that culling on multiple cores, improving total framerate.
I don’t have great numbers on what kind of performance change you’ll see in 11.02; it’s actually hard to measure the improvements here with the FPS test because the FPS test runs a replay (and not the actual flight model) and doesn’t run long enough to generate car traffic. But we think it should be a good incremental improvement.
* It is not a bug that this case was slow for the NVidia driver; no OpenGL driver is contractually obligated to do anything in a particular time frame. It was slightly surprising in that NVidia seems to go farther than other GL vendors to optimize less common and less efficient code paths.
NVidia does normally allow for complete threading of CPU-side driver work, so it’s possible they thought there was no need to optimize this case directly since it would be on a worker thread; by comparison, Apple does not use a general worker thread for their driver but does use a worker thread for all CPU-based texture transfers, at least as far as we can tell by profiling X-Plane.
If you want to make an aircraft that is FMOD enhanced, you must start with this starter project! If you already have an FMOD project, please copy the events into this new starter project.
When can an FMOD project be shared?
Use only one starter project for an entire family of .acf files that share an ACF folder. These ACF files will share the master bank in the FMOD folder, so you need one project for all aircraft. (Each aircraft gets its own .snd file in the FMOD folder.)
You must use a new starter project fore each aircraft in a new folder – you should never have a single project with banks copied into two different FMOD folders!
We are working on more documentation on how to use FMOD, but with the sample project, you have everything you need to create an FMOD-enhanced aircraft.
X-Plane 11.01 is now final, both via our installer and Steam. We’re going to do one more bug fix release (11.02); at this point it looks like Gateway airports will go into a separate 11.05 release to give authors a little bit more time to work with WED 1.6, but we’re still discussing this internally.
In terms of timelines and releases:
Small bug fixes, fixes for aircraft SDKs, and small, tactical performance improvements will make it into X-Plane 11.02.
Big things like an XPLM revision to pop out windows, fixing the weapon API, the G1000, and more invasive performance improvements as we move toward next-gen rendering APIs will have to wait for 11.10.
That’s a lot of stuff in that second bullet point – there is basically no chance that all of that will make it into 11.10; we have enough long term efforts going on at once that some will go into 11.10 and some into 11.20 or something later. I don’t even know which of those things will be in 11.10 – basically, what’s ready around when we get to 11.10 will be released, and we’ll do another release when more features build up.
This is a first draft, so please: use the comments section to ask questions about FMOD only. I’m going to do something a little bit unusual and delete off-topic comments on this post so the entire comments thread is FMOD specific. FMOD integration with X-Plane is complicated, so it would be really useful to know what needs more explaining.
There is one more piece of the FMOD puzzle that is missing – Tyler is working on it now and hopefully we’ll have it live soon: the FMOD starter project.
The short version is: to get an FMOD project that will properly integrate with X-Plane and other third party FMOD aircraft, you need to get a starter project from us – it will come with the mix buses already in place and set up for X-Plane to use them; you can just add signal processing, etc.
What makes this tricky is: everyone needs a unique starter project or else multiple FMOD aircraft won’t be able to coexist. (And that would be sad – one of the really cool thing about FMOD-enhanced aircraft is that you can finally hear the AI aircraft. It adds a ton of depth and realism.)
Tyler is working on a download link that dynamically creates a unique FMOD starter document to avoid FMOD conflicts between AI aircraft. I’ll post when this is up and running.
In the meantime, the docs hopefully answer some questions about how aircraft like the Cessna work.
Right now FMOD can only be used to add sound to aircraft, but we are looking at adding FMOD to scenery, as well as our own ground vehicles.
X-Plane 11.01 release candidate two is now available – on Steam too! We hope this is the one.
Here’s one more before-and-after view – the new fog applied correctly to lighting spill and billboards.
11.00
11.01
11.00
11.01
11.01 should go final too and then we’ll move on to 11.02 – we have more bug fixes to get out and a performance improvement for NVidia Windows hardware.
We posted an X-Plane 11.01 release candidate today.
The good news: it fixes the XPLM navigation buffer overruns that were crashing plugins. So that should be a big win for people using plugins with the beta.
The bad news: we found and fixed the flashing cloud shadows bug after the RC went out.
So we’ll do an RC2 with the cloud shadow fix over the weekend. We have a bunch of bugs we kicked to an 11.02, so that we could get the 11.01 fixes to everyone. We’re also looking to make WED 1.6b2 uploadable to the gateway so we can push out more gateway airports.
X-Plane 11.0 shipped with all new Physically Based Rendering – the lighting and material model is based on the real physics of light interacting with dielectrics and metals (kind of) to make rendering look more realistic with less art tuning.
But…X-Plane’s night lighting in X-Plane 11.00 is not physically correct – the night lights ignore the materials and do what X-Plane 10 did.
X-Plane 11.01 betas fix this. In the pictures below you can see side-by-side comparisons of the same scene with the 11.00 lighting and the new physical night lighting for 11.01. The array of balls floating around the Cessna is a test project I use with a 2-d grid of materials (metal on the bottom, rough on the right).
Materials 11.00
Materials 11.01
737 11.00
737 11.01
737 beacon 11.00
737 beacon 11.01
747 11.00
747 11.01
One of the effects of this is increased accuracy of light location – that is, you can really tell where the lights are by the reflections they cast on specific materials.
Here are some material comparisons with the day seen included so you can see what the original materials were. Observe the rim of the engine cowlings on the 737 and 747, and of coarse the entire fuselage on the MD-82.
737 Day
737 11.00
737 11.01
MD-82 Day
MD-82 11.00
MD-82 11.01
747 Day
747 11.00
747 11.01
There’s no authoring change needed or work to do for third parties – if you were modeling your aircraft to look correct during the day, 11.01 makes the night lighting look better.
A number of blog comments have been (cough, cough) rather vocal about the cockpit lighting being too bright in the cockpit at dusk. As it turns out, this was a shader bug! Here’s some before and after:
Day – 11.00
Day – 11.01
Sunset – 11.00
Sunset – 11.01
Dusk – 11.00
Dusk – 11.01
To get a sense of the bug and the fix, look at the panel of the Baron and the wall of the building behind it. These surfaces are both bright-albedo rough reflectors facing in the same direction. You’d expect roughly similar direct lighting levels* for the same surface, and yet in the 11.00 pictures, the cockpit panel is way brighter.
X-Plane uses atmospheric scattering equations to calculate the sun’s direct sun color – the sun light becomes “reddish” at low angles because the blue light has been scattered out more, by going through more air than at higher sun angles.
But we can’t always use this formula! When you view a weapon in the weapon preview screen, where in the world is it? What time is it? The answer is: no one knows, so we just render with proxy lights and not the full atmospheric model.
The bug was: we were using proxy lighting colors and not the actual scattering-based lights to calculate the interior of the airplane, causing huge direct-lighting mismatches between the interior and exterior of the aircraft. If you had a part-interior, part-exterior model (e.g the air-stairs of the plane folded up inside the cabin) you might see a huge lighting difference.
11.01 correctly uses scattered sunlight in the airplane too, resulting in much less “electric” sunsets.
* Assuming no cockpit shadows – if you really want to put back cockpit shadows after this fix, um, go ahead, but I continue to think that the shadows look too awful due to the very low sun angle, and the direct light isn’t a problem now that it’s fixed.
X-Plane 11.01 beta 1 is out now – to get it you have to check “get betas”. Since we now have a stable release version, my suggestion is: don’t check the box unless you are an add-on developer or are willing to deal with some beta-crazy. We try to make sure that every beta works, and things are less crazy here now that 11.00 is out, but you can read the release note history and see that dead betas still happen regularly.
Linux Users: if you use the Aerosoft DVD and have been using the special posted build of the sim to unlock the DVD, please use 11.01 beta 1 – the Linux fix is incorporated.
I’ll post some pics of some of the graphics changes in 11.01 in another post.
A note on the various SDKs: we made a real push to get the various authoring SDKs stabilized for 11.00, but there were things we missed. Most of the authoring SDK changes in 11.01 are:
Removal of old datarefs and features that didn’t work anyway and hadn’t been “cleaned out”.
One exception where an authoring rule is actually changed: during the betas and in 11.00r1, the prop disc is blended using incorrect gamma, matching X-Plane 10 behavior. Not changing this was an accident; all other alpha blending in 3-d is gamma-correct in X-Plane 11.
For 11.01 I chose to change the prop disc now to make everything completely consistent across all interfaces for the rest of the X-Plane 11 run. This isn’t ideal, but running the prop discs with incorrect blending would be a performance penalty for the entire rest of the version run (we’d have to change rendering passes in Metal/Vulkan to support this) so I figured best to rip the bandaid off quick.
As with all gamma-correct blending, the most likely problem with this that the mid-alpha parts of your texture appear too bright in 11.01b1. Incorrect blending loses energy, so the natural authoring work-around is to make things too bright to compensate; now that you are seeing too much light energ you may have to back things off. Looking at our Cessna, the white paint on the prop disc is a little bit too bright with the change.
In other SDK notes: I’m part way through writing draft FMOD notes – one that’s done, Jennifer can turn that into something human-readable. We will probably do an 11.02 to collect gateway airports; WED 1.6b2 is out now but it’s not approved for gateway use yet; we’re waiting to get some test time on it. If 11.01 goes final before gateway airports can be pushed, we’ll do a separate patch to get those airports released.
