Here’s a quick update on X-Plane 12 to give you an idea of where we are, what’s being worked on right now and what the next steps are. At the end of last year, we started sharing early, rough builds of X-Plane 12 with a private alpha group, mainly 3rd party developers and subject matter experts. Everyone in the alpha program has signed a non-disclosure agreement, so please do not ask them to share X-Plane 12 or technical details. (The alpha program is also ful, please don’t email us for access… sorry.)
Here’s a snapshot of some of the development tasks we’re working on right now.
Recently Complete
In Progress
Up Next
Default Fleet Updates
Low Visibility
Rain Improvements
Rain/Snow on Runways
Water
Performance Tuning
Prop Physics Updates
Anti-Aliasing and FSR
Restore VR
3D HUD
Night Lighting
Recut Default DSFs
ATC Overhaul
Third Party APIs
Bug Fixes
Seasons
3D Trees
UI Refresh
FMOD 2.0
Moving Jetways
There’s a lot more that is already completed, too – this is just a window into our current work. Once we complete all of the open development tasks, there are still plenty of bugs to fix.
At some point during this bug fixing process, we will transition from the closed private alpha to an open “Early Access” beta program. Once we make this transition, anyone who wishes to participate in Early Access will be able to purchase a license of X-Plane 12 and use the new sim right away.
Here are some details on our recent development work.
Light Up the Night
X-Plane 12’s lighting engine is completely photometric and runs in true HDR at all times. This includes updates to how we do night lighting and artificial light sources. We are finishing up a very careful pass over a wide variety of light sources – urban lights, street lights, and most importantly light sources that affect pilots (e.g. approach lights, runway edge lights, PAPIs, etc.). The intensities of these lights are calibrated using spec sheets from the FAA.
Low Visibility
The new lighting engine also requires us to take a new approach to low visibility flying conditions. Low visibility daytime conditions in X-Plane 12 are naturally darker than sunny days, but also still lighter than night time flying. Low visibility isn’t just about making X-Plane look nice – X-Plane is used as a training simulator, so we need to make sure that visibility is limited by just the right amount to train for instrument approaches.
To solve this problem, our art director Alex Unruh built…a monolith.
The monolith is a calibration target for tuning the simulator – based on a certain position on the runway and the right visibility settings, the monolith will be just barely visible. The monolith is surrounded by runway lights so we can make sure the approach and edge lights respond to fog appropriately as well.
Water, Water Everywhere!
X-Plane 12’s water is 3D. Not only does this make ocean waves more realistic, but this 3D water interacts with the flight model. Austin has worked closely with seaplane pilots during alpha testing to dial in seaplane behavior.
A new feature in a simulator can create new bugs that need to be fixed – this is why we invited our third party developers to try out the simulator early in the process. For example: When we made the water waves 3D, they started sticking up through orthophoto scenery. (In X-Plane 11, orthophotos just “paint over” the 2D water.) Last week we implemented water masking, so that orthophoto scenery can cut out the 3D water to avoid these bugs.
Anti-Aliasing
X-Plane has featured a deferred renderer for almost a decade; with X-Plane 12, deferred rendering is the exclusive mode our graphics engine runs in – this is important because it makes the new weather effects and lighting possible.
With X-Plane 12 we now support real multisample anti-aliasing (MSAA) with our deferred renderer. In some versions of X-Plane, MSAA wasn’t compatible with deferred rendering, and the AA options were FXAA and SSAA. This was frustrating to users because SSAA severely hurts framerate. If your GPU is maxed out, 4x SSAA will typically cut your framerate by …. 4x.
The new MSAA code path should be much more efficient. We are also implementing AMD’s FidelityFX Super Resolution (FSR). FSR lets us render the world faster and then scale the result up to 4K – it’s a great option for users who want to fly in 4K but keep their framerates up. You can read more about FSR here.
Supporting Third Parties
With the new major version we are making some changes to the plugin environment:
The X-Plane SDK supports the new ARM M1 Macs.
We are removing OpenAL from X-Plane. X-Plane itself hasn’t used OpenAL in years, and we are in no position to support it. Plugins that use OpenAL in X-Plane 12 will need to package OpenAL themselves.
We are making the FMOD API available to plugins (in a few different ways) so that plugins that generate sound can interact with the full 3-d sound environment.
In X-Plane 12 we run Chromium Embedded Framework (CEF) at startup. In X-Plane 11, the first plugin to run CEF would ‘own’ it; this new setup allows X-Plane and all plugins to share CEF and should make it easier for plugins that need to access web pages to do so.
We are building our own test plugins and working with our third party developers to make sure these new pathways have been tested experimentally.
A major focus of the private alpha is to make sure that these changes will work with third party add-ons the way we expect, so we’ve prioritized getting the changes into the alphas early so our third party developers can try them.
What’s Next
The next phase after private alpha will be a completely unrestricted Early Access beta program – everyone will be able to run the X-Plane 12 beta (either as a demo or with the purchase of an X-Plane 12 license).
We have some feature work to wind down with some of these third party cases and new features, and once that is done, it’s going to be bug fix, performance tune, repeat, repeat, repeat to get to Early Access.
One of my favorite planes the F-4 Phantom. And one of our alpha testers recently casually mentioned that he was an Israeli Air Force F-4 Phantom flight instructor. I’ve been exchanging emails with him about every 30 minutes or so, on average, for 12-hour-long days, for the past 5 days or so. We have been doing DOZENS of changes of EXEs and ACFs to get the F-4 in X-Plane flying PERFECTLY.
And the success we’ve realized is beyond my wildest expectations.
So here we go: First off, thanks to this intensive, minimum-sleep, once-in-a-lifetime week, we now have an F-4 flight model that is accurate enough to be used for actual F-4 flight instruction: It flies JUST like the real plane through its’ huge flight envelope, from dirty, low-speed approaches, to high-G maneuvering, to Mach 2.2 travel at FL500, to the ceiling of FL600, with acceleration, deceleration, gliding, all representing the real plane as close as an instructor pilot can tell by flying it.
So here is the thing about the F-4: It has a HUGE speed envelope, going from 150 knots to… 1,500 knots.And a HUGE angle of attack envelope, going from zero to… 25 or 30 degrees AOA without losing control, as that huge delta wing rolls up a giant vortex to maintain low pressure above it, without stalling, up to absurdly-high angles of attack.
And it does this with almost no flight computer to speak of at all… just a rate-damper, nothing else! So, with these huge ranges of speed and angle of attack, hugely-detailed requirements for performance, maneuvering, and handling, this airplane makes the ULTIMATE airplane to test the X-Plane flight model. If it’s wrong in the X-Plane flight model, the pilot of the sim will NOTICE it! There are no flight control computers to hide the errors, and across this huge envelope, any shortcoming in the flight model will stick out like a sore thumb at SOME portion of the operating envelope!
So the F-4 Phantom has always been my dream airplane, and it exposes any error in the X-Plane code. It’s perfect.
And now, with an Israeli Air Force F-4 flight instructor putting in 12 hours days for five days or so with CONSTANT emails and iterations, we have this airplane DIALED IN TO FLIGHT PERFECTION.
And here is where it gets REALLY FUN: We did this not just by perfecting the ACF file (which we surely did) but ALSO by perfecting the flight model code in X-Plane, rolling in refinements that will subtly benefit ALL airplanes. There are NO hacks in the aircraft file. NO plugins. EVERY VARIABLE is entered as accurately as could be in Plane-Maker, and the flight model is now improved and refined to represent this model perfectly.In the past, people would sometimes have to put fake values in the airplane file in Plane-Maker to get realistic performance, but that is NOT the right solution. I wanted to enter this bird ACCURATELY, and then get perfect results.
So here’s where we start: The FIRST major issue we noticed was that the simulated F-4 was just not flying dangerous enough: It was limiting the angle of attack to safe values, not pitching that nose quickly and aggressively into the target, not going to huge angles of attack and lift and drag to CLAW at its’ target. The reason? The OLD X-Plane flight model was treating the wings of the F-4 like any normal airplane wings, limited to 15 or 20 degrees to avoid the stall, and with a flight control computer limiting the airplane to nice, safe, low angles of attack to prevent that stall.
BOOOO!
That’s not what the real airplane does! The REAL F-4 has a huge DELTA wing and DELTA horizontal stabilizer. These triangular wing plan-forms roll a VORTEX up off their leading edge, rolling the air up from underneath the wing, up around the leading edge, causing a HUGE VORTEX, or HURRICANE, literally to form over the ENTIRE TIP OF THE WING! This vortex does NOT allow the wing to exceed critical angle of attack and stall! No! The MORE the angle of attack, the STRONGER the HURRICANE over the wing, as the angle of attack comes up and the air ROLLS UP OVER THE LEADING EDGE AND INTO A VORTEX OVER THE ENTIRE WING.
Here is what is so amazing about this: For traditional wings like X-Plane has always simulated, air never comes up over the leading edge! Instead, at the stalling angle of attack, the air separates from the top, loses suction, and the wing stalls! And all of this is carefully orchestrated based on the AIRFOIL, or CROSS-SECTION SHAPE, of the wing!So X-Plane has always used the airfoil cross-section, corrected for the plan-form, or top-down shape of the wing, as classical wing theory calls for.
But now, with a delta wing, the cross-section of the wing hardly matters! Now what matters is the plan-form, or top-down shape, of the wing! That’s what lets the air roll up over that highly-swept leading edge to form the huge hurricane over the wing that SUUUUUUUCKS the wing up… and never stalls!
And X-Plane now used this classical wing theory based on the AIRFOIL CROSS SECTION for non-delta wings, vortex-generation based on the PLAN-FORM of the wing for delta wings, and even interpolate smoothly between them for partially-delta shapes, consider both the airfoil cross-section, and the delta plan-form, for a real three-dimensional understanding of the wing.
And that is what lets us simulate the delta wing of the F-4, with that huge over-the-wing hurricane that lifts the wing up without fear of stalling even at crazy-high angles of attack.
Of course, this gives HUGE LIFT, bit also with a resulting HUGE drag! So, to get this airplane right in X-Plane, job number one was to get this vortex formation working in the simulator, so we did! Now, as the wing as entered in Plane-Maker gets closer to the proper shape for vortex lift, X-Plane smoothly departs that oh-so-boring land of smooth flow up to the stall that we have gotten used to, and into the land of vortex-generation as a function of angle of attack! Now, when X-Plane detects the SHAPE of the DELTA wing, higher AOA means more lift (and boatloads more drag!) without any stall! And what is beautiful is that X-Plane PHASES SMOOTHLY INTO the delta-wing dynamics based on how CLOSE to a delta-wing the planform is. The F-4 wing is NOT QUITE a perfect delta-wing shape, so SOME classical wing dynamics remain in place: X-Plane is blending largely into the vortex dynamics, but still using some of the classical dynamics at the same time… and if you look at the slats on the leading edge of the real airplane, you will see that the designers telegraphed this to us, equipping the wing with slats to resist stall in the classical flight dynamics regime as well.
And, once that stall-proof delta-wing was done… I RIPPED THE ARTIFICIAL STABILITY COMPUTER RIGHT OUT OF THE AIRPLANE! NOTHING LEFT BUT A DAMPER, LIKE THE REAL PLANE! NOW, starting with THAT, we were able to feel the REAL F-4 Phantom: Hurricane lift, no computer in the way. Boom. NOW we feel the air, and can CLAW into the turn at crazy-high angle of attack and G-load. The the NEXT thing we noticed is that the simulated F-4 did NOT tuck the nose down coming through Mach-1, as it should!
The reason was quickly found: IN REALITY, for SUBSONIC airplanes, the lift acts at about 25% of the way back along the wing. The OLD flight model had this just fine.IN REALITY, for SUPERSONIC airplanes, the lift acts at about 50% of the way back along the wing. The OLD flight model had this just fine.IN REALITY, for SUBSONIC DELTA-WINGS airplanes, the lift acts at about halfway between these two values… at 37.5%.
And, and that LAST item is what the OLD flight model did not quite understand. NOW, I have coded that center of pressure for SUBSONIC DELTA WINGS to be right in the middle between 25% and 50% of the wing chord, which results in just the right stability for the real airplane. But here is where it gets interesting: Now, as you accelerate though Mach 1 in the simulated F-4, the center of pressure scoots BACK from 37.5% (delta-wing) to 50% (supersonic) suddenly pushing the lift BACK, and causing the airplane to suddenly become a lawn dart, wings at the back and nose in the front, causing the nose to suddenly drop. This is called Mach Tuck, and it’s exactly what the real airplane does. This is interesting enough, but here’s where it gets scary: Let’s say you are supersonic, turning hard. The center of pressure is back at 50% (because supersonic). Compression shocks blanket the front half of the wing, expansion fans blanket the back half. All of this is what happens in the real plane, and is simulated by X-Plane. Your stick is WAY BACK IN YOUR LAP as you try to get that nose-heavy lawn-dart to pull the nose UP though the turn. At some point, you drop below sonic. The moment the speed comes below Mach 1, what happens??? The center of pressure suddenly moves FORWARD from 50% (supersonic) to 37.5% (delta-wing)! SUDDENLY, the nose LURCHES upwards! The lift has just JUMPED forwards, now well in FRONT OF the heavy engines, and the nose suddenly lurches up from that lift coming forwards. The G-load suddenly jumps up, the angle of attack skyrockets, and the shock waves have vanished to be replaced by the hurricane vortex forming over the wing! The lift is huge, the drag is huge, the g-load is crazy by maxing out angle of attack at just barely below the speed of sound, and the nose claws around the turn at crazy angle of attack and g-load. All of this is a well-known characteristic of the real F-4, and all of this is simulated perfectly by X-Plane as EMERGENT behavior, because the center of pressure shifts on the wing, and all the physical dynamics follow it without any additional code at all. Lift from shock-waves to hurricanes: Welcome to the F-4 Phantom.
Boom. NOW we feel the transition from subsonic vortex lift to supersonic compression-shocks and expansion-fans and back to hurricane lift if we pull the nose hard in a supersonic turn to drag us back down to subsonic. But it wasn’t happening at quite the right SPEED. The transition to supersonic flow and back, with the resultant severe pitch-change, was happening at about Mach 1.25, when it SHOULD have been happening at Mach 1!
Why? Let’s look at transonic flight for a moment.
Imagine you are in a GLIDER. Nice long straight wings sticking out there. You are in thin air at 100,000 feet and diving down at a 45-degree angle. There’s probably RedBull logos on your airplane, and you’re in a pressure suit. As you dive, air speeds up to MORE than the speed of the airplane to get AROUND that thick, cambered wing. The THICKER the wing, the MORE the air speeds up to get around it. The GREATER THE CAMBER, or LIFT the wing, the MORE the air speeds up to get around the wing. (Remember, air speeds up to generate lift!) With your straight, thick, high-lift wing, as you get to Mach 0.60 or so, the airflow over the TOP of the wing has accelerate to the speed of SOUND to race up OVER that thick, curved airfoil! So, even at Mach 0.60, you have SUPERSONIC FLOW over the TOP OF THE WING!You have supersonic drag at just Mach 0.6! Bummer! Your speed is limited as you have hit an aerodynamic brick wall of shock waves.
But you are high on RedBull and have to pee so bad for obvious reasons that you want to get back down to Earth FASTER than Mach 0.60.You want more speed.How do you get it? OK, let’s operate with LESS LIFT. Let’s use a foil that is NOT SO CAMBERED on top. Without this airfoil camber and lift, the air does NOT speed up so much over the top of the wing! Of course, you have less lift now so the plane has a higher stall speed and HAS to fly faster, but who cares? You’re in a hurry. Reducing that camber and local airflow acceleration lets you get up to mach 0.65 before the flow goes to supersonic over the top of the wing. More speed!
But you still want to go faster. Nobody wants to pee inside a pressure suit.Ok, let’s make the wing THINNER! This means the air does NOT have to speed up as much to get around the wing, so now you can get to maybe Mach 0.70 before those thrice-damned shock waves form over the wing and block your acceleration. But you still want to go faster. As you get older, you can’t hold it as long. So now we SWEEP THE WINGS BACK. If we sweep the wing to a 45 degree angle, then the flow acting at a right angle to the chord is only 71% (cosine of 45 degrees) of the actual local speed.
Or, put another way, the wing is SLIDING out of a direct conflict with the air by slicing through it SIDEWAYS. Or, put another way, the wing appears THINNER to the air, because the air is sliding sideways ALONG the wing from root to tip, not suddenly being jerked around the airfoil in a direct confrontation. No matter how you look at it, you can go a LOT faster before the local flow over the top of the wing goes supersonic, invoking those shock waves that impede further acceleration.
So that wing sweep EFFECTIVELY lowers the speed over the wing: Less airspeed acting at a right angle to it! And X-Plane was applying this speed reduction to the MACH NUMBER on the wing as well! Ooops! BAD MOVE.NOT RIGHT. While wing sweep does indeed lower the effective airspeed at a right angle to the wing, localized flow still starts to go supersonic as we approach Mach 1, and by the time we are AT Mach 1, ALL of the flow is supersonic. No wing sweep in the world can avoid this. So wing-sweep lets you get CLOSER to Mach 1 before localized flow starts going supersonic, but that’s all. It doesn’t let you get PAST Mach 1 and still have subsonic flow.
So the subtlety is that: Wing sweep lowers effective wing speed, by reducing the airspeed acting at a right angle to the chord and lowering the resultant lift… Wing sweep lowers effective wing camber and thickness, reducing localized flow acceleration to supersonic speeds… But once you are going Mach 1, the shock waves form on a wing of ANY sweep… the sweep just DELAYED that localized shock-wave build-up until CLOSER to Mach 1. Wing sweep doesn’t let you exceed Mach 1 with subsonic flow.
So based on this, we would expect an airplane with a long, thin, lightly-cambered, highly-swept wing to get very very CLOSE to Mach 1, but never quite HIT it. Because that thin, un-cambered, swept wing sees almost no localized sonic flow until almost the very moment the plane hits Mach 1. There’s very little localized flow acceleration. So look at the wing of the Citation X. It’s all right there.Hidden in plain sight.Going Mach 0.925. Of course, as soon as I corrected the flight model to understand this subtlety, the transition from subsonic (tornado) to supersonic (compression-shock and expansion fan) happened smoothly between mach 0.9 and Mach 1.0, and the airplane Mach-Tucked or smacked you in the, um, everything, with G-load at just the right speed.
Bingo.
The the NEXT thing we noticed is that the simulated F-4 did NOT want to raise the nose quick enough in take-off!The real airplane could raise that nose at 155 knots in the take-off roll… so why was the simulated airplane building up to 185 knots on the runway before we could get the nose up? The first thing we found is that the simulated airplane was carrying all its’ fuel in the wings. OOPS! The REAL F-4 carries almost all of it’s fuel inside the body… ABOVE the engines!In the real airplane, under full thrust, the weight of all that fuel ABOVE the engine thrust was pulling the nose UP from the push of the engine UNDERNEATH it! Look below: All those black boxes are fuel… and all ABOVE the engine! The engine pushing forwards under all that weight will help RAISE the nose!
So the next thing I did was get all the fuel placed properly in Plane-Maker. Doing this, the nose came up at CLOSER to the right speed (175 knots?) under full acceleration, but still not he 155 knots we know the real airplane could do.
What’s next?
In the REAL airplane, downwash from the flaps certainly smacked DOWN on the horizontal stabs, giving more nose-up moment, but in X-Plane, we were just not seeing that downwash hitting the stabilizer during the take-off roll (but it was just fine in flight!!!) WHY?? As you may have guessed, it was GROUND EFFECT. IN REALITY, ground effect is BOUND to flatten out the downwash from the wing onto the horizontal stabilizer, and the old X-Plane flight model was OVER-DOING that effect, flattening out the ground effect a bit TOO MUCH. I went back to the ground effect reports I used, and found a better way to curve-fit the experimental data. As well, I looked at the induced drag reduction with ground effect, and since induced drag is tied to downwash (one is the cause of the other) blending the downwash in with induced drag as well mode the model more accurate yet. Doing these things, we shaved another few knots off the rotation speed, but only a few knots… the ground effect impact on downwash was not huge.
What ELSE were we missing?
We were still raising the nose at 170 knots… 15 knots too fast. We needed to get that nose up at 155 knots, 15 knots sooner.We need 15 knots more ‘oomph’.Somehow. 15 knots. Myself and the F-4 instructor wracked our brains wondering WHY we could not raise the nose until going 15 knots too fast… ALL elements of the aircraft definition in Plane-Maker were checked and checked agin. Vortex lift, which also applies to the stabilizer, was checked and checked again.
What were we missing?
Suddenly it hit me: There is a thing called ENTRAINED FLOW. ENTRAINED FLOW is wherever you find a fast-moving JET of air, and the air nearby is GRABBED AND DRAGGED ALONG WITH IT to some extent, speeding up the air all AROUND the jet. Look at video of any of Space-X’s or anyone else’s rocket engine tests on the test-stand: You plainly see air RUSHING through the test stand, entrained in the hypersonic rocket flow, and being dragged along with the current. Do you know of any jets of air located near the horizontal stabilizers of the F-4 Phantom?
If not, then here’s a small, subtle hint:
Now this is subtle, but if you look real careful and squint just right, you will see these HUGE FREAKING AFTERBURNERS PUSHING AIR OUT AT ONE FREAKING THOUSAND FIVE HUNDRED MILES PER HOUR. This entrains flow, without question. In other words, the entrained flow around the jet exhaust is getting dragged along by the supersonic core, speeding airflow over the horizontal stabilizer! But how MUCH? How MUCH entrained flow is near this jet blast???
I asked the F-4 instructor, really assuming I was wasting my time asking a pilot such a weird technical question that nobody ever even thinks about.
Then, in his endless series of mic-drop moments, he knew. He literally KNEW how much entrained flow there would be. How? Because the people making the airplane wanted to make sure that nobody working on the ramp ever got BLOWN AWAY BY THE JET BLAST! They MEASURED the entrained flow (and temperature!) to a careful degree, ALL AROUND THE JET EXHAUST, so they could tell the ground crew where to never go!
And here it is:
Boom. My jaw dropped when I got this. The answer is right there. NOW YOU KNOW how the jet-blast, complete with entrained flow, for both subsonic and supersonic jets. A careful look here shows that the plume expands out at a ratio of about 4 or 5 feet back to 1 foot out. As well, look carefully and see that as you move aft, the flow slows down as the volume increases (no surprise there, if you follow Bernoulli on Twitter).
Another fascinating thing you see is that as you move out to the SIDE from the CENTER, the flow cuts its’ speed almost exactly in HALF each bit of CONSTANT DISTANCE you move.
In other words, at a certain distance aft (call it 100 feet) the flow speed exactly cuts in HALF for each ten feet you move to the side! The EDGE of the drawn gray plume is NOT where the speed is ZERO… it is where the speed is fifteen knots… 1% of the core emitter velocity.And, as you can easily extrapolate from this, in another 10 feet it will be half of 15 knots! And, as you can easily extrapolate from this, in another 10 feet it will be one quarter of 15 knots!And, as you can easily extrapolate from this, in another 10 feet it will be one eighth of 15 knots! And, as you can easily extrapolate from this, in another 10 feet it will be one sixteenth of 15 knots!
I think you get the picture: The entrained flow goes out very very far (do you REALLY thing it WON’T be windy standing behind an F-4 Phantom at full afterburner?), but the flow speed simply gets very very small compared to the core speed as you move farther away. Carefully transcribing this flow into X-Plane, white lines showing flow boost speed on each element:
Boom. Average 15 knots of help on the stabilizer from the entrained flow. The horizontal stab of an F-4 gets help from flow entrained in the jetwash, increasing the speed over the stabilizer. By an average of 15 knots. There was our missing 15 knots. With the entrained flow jet-blast model right from the ground-personnel warning, we suddenly had an extra 15 knots on the tail, and the nose coming up right at 155 knots, JUST LIKE THE REAL PLANE.
The performance was all dialed in, but something was still not quite right: The plane seemed to be too sluggish in roll. Sort of… wallowing. Even more than the real plane! Especially at low speeds. At high speeds, it was basically perfect.
Why? How do you have the roll being too sluggish at low speed, but just fine at high speed? Suddenly it was obvious: The AERO effects were just right. The plane had too much MASS INERTIAL in roll. That mass inertia (the ‘radius of gyration in roll’) was too high, and at low speeds, under low aero forces, you really noticed that it just took too long to get that big mass rolling! At higher speeds, with the higher aero forces at play, you really did not notice it much: The large aero forces over-ruled even the too-high inertia enough that no human could detect the problem.
So, it was time to go into the way X-Plane distributes the mass across the airplane to DETERMINE the the inertias in pitch, roll, and yaw.Sure enough, X-Plane could be a bit better there! First, I updated X-Plane’s mass estimate for the ENGINES based on all the latest engine data I could find based on number of engine spools and bypass ratio. Then, I added consideration of the EMPTY fuel tanks to the mass-distribution estimate. Fuel itself was already added, but why not take it to the next level of accuracy and also add the weight estimate for the empty tanks themselves? They are mostly just above the centerline of the airplane, tightening that roll inertia right up. As well, why not consider the fact that THINNER wings probably weight less, since any airplane with really thin wings is not storing too much stuff IN those wings! Fighter jets store most of their stuff in their bodies, not in their wings! This is needed to keep the wings thin to keep the drag down! So, with fuel tank empty masses and locations considered, and thin wings pushing the innards of the airplane out of the wings and into the bodies a bit, X-Plane now had a more accurate moment of inertia estimates (on all axis) and that tightened up the roll inertia, resulting in proper roll even at low speeds, where the aero forces were low, and the body inertias very very apparent.
But now we got to a really odd subtlety: (this one also explained in a video found by Scott Manley on YouTube)
At really high angle of attack, the speedbrakes become blanketed in turbulent, separated or cyclonic flow, and frankly don’t do anything. Think about it: They’re in the middle of the wing, far from the leading or trailing edge, in the middle of a chaotic and turbulent zone of air. Why WOULD they do anything in that scenario? So, at a very high angle of attack, the roll spoilers become use lawn-ornaments on the wing, and lowering an aileron just increases the DRAG on the wing you want to raise, pulling it AFT and dropping it, while of course advancing and lifting the other wing, causing the pane to wallow in the OPPOSITE direction you commanded! As my F-4 instructor put it: “If you try to pitch and roll at the same time, the Phantom will not obey”. So now, with blanked flow diminishing and then finally at max lift eliminating speedbrake effects, sure enough in X-Plane: Near max angle of attack, full left stick causes the nose to yaw right, and the plane to gradually wander off to the right, and vice-versa. All of this is emergent behavior in X-Plane: None of it was tacked on.
But now we got to a really odd subtlety: (this one also explained in a video found by Scott Manley on YouTube… youtube.com/watch?v=iZiduQboyow, t = 9:33) At really high angle of attack, the speedbrakes become blanketed in turbulent, separated or cyclonic flow, and frankly don’t do anything. Think about it: They’re in the middle of the wing, far from the leading or trailing edge, in the middle of a chaotic and turbulent zone of air. Why WOULD they do anything in that scenario? So, at a very high angle of attack, the roll spoilers become use lawn-ornaments on the wing, and lowering an aileron just increases the DRAG on the wing you want to raise, pulling it AFT and dropping it, while of course advancing and lifting the other wing, causing the pane to wallow in the OPPOSITE direction you commanded! As my F-4 instructor put it: “If you try to pitch and roll at the same time, the Phantom will not obey”. So now, with blanked flow diminishing and then finally at max lift eliminating speedbrake effects, sure enough in X-Plane: Near max angle of attack, full left stick causes the nose to yaw right, and the plane to gradually wander off to the right, and vice-versa. All of this is emergent behavior in X-Plane: None of it was tacked on. Again, the huge performance envelope and nearly-absent computers, coupled with high mass and small wings made every single shortcoming in the flight model stand out like a sore thumb… so I could quickly address it!
So, we now have the F-4 flying at a level needs to give flight instruction. Think of the thousands of tons of fuel that would have been saved if we had had this in the 60’s, or even 10 years ago, when the plane was still in service!
But is there any OTHER use for these improvements in X-Plane?
Well, flying the new F-14 Tomcat, we suddenly do NOT need a fake, stall-proof airfoil for the horizontal stabilizer. Why? Because the horizontal stabilizer of the F-14 is a delta-wing. It doesn’t stall: It vortex-lifts itself to do any job. Now, the hurricane forms over the F-14 stabilizers, preventing any stall of the tail surface. Now, as well, the downwash modification due to ground effect is more accurate, thus giving more accurate downwash onto the horizontal stabilizers of the airliners, helping them get their nose up just a little earlier, as the A-330 has been needing. As well, this downwash tuning with ground effect will perfect that nose-down that airliners encounter in reality as the wash onto the tail reduces in the final bit of the approach and flare. Also, the transonic effects that I tuned carefully with Mach number are JUST STARTING to become apparent as airliners like the A-330 move into the their MAX-MACH cruise, and the Citation-X tops out at precisely Mach 0.925, just like the real airplane. As well, the new more-accurate transonic drag rise we developed for the F-4 exposed a teeny error int he A-330 aircraft file: As the A-330 approached its’ max cruise of Mach 0.85, the drag was just skyrocketing. Why? ONE TINY BIT OF THE WING did not have quite the right sweep: And it was tossing shock waves and slowing the whole airplane. Thank the F-4 tuning for finding this.
As well (and this is the big one) if you look at videos like this, you will see the horizontal stabilizers of large airliners shaking during their take-offs. And no, it is NOT from a bumpy runway: The main wings are as still as a rock in a field. Check it out:
So why is the horizontal stabilizer jiggling along as if something is smacking into it? Well, as you now know: THERE IS! It’s the entrained flow from the engines! X-Plane now applies the entrained flow model from the F-4 ground-crew warning to ALL jets of air (physics are physics!) and sure enough, about 15 knots or so is making it to the stab of the A-330! Again, helping raise that nose at a lower speed, as our model needed. Hit command-M a few times to see the various flow fields.
So, this tuning and upgrading of the flight model to NAIL the F-4 has been great, fleet-wide!
And, of course: Wow, what an airplane.
And the final note from the F-4 instructor:
Hi Austin, Tested this thoroughly….it is *ON THE SPOT* now (!) Perfect takeoff (!!!), landings, flameout landing path, aerobatics….X-Plane has a very fine F-4 simulation now 🙂 …. The F-4 nuances are very accurate now…amazing in fact. Well done! “Tuning” an aircraft is a familiar process to us developers, but Austin did not “tune” it. He simply increased the model’s design resolution, or “density”, accurately, using actual data and design aspects…and on the other hand, extended his flight model’s “blanket” to cover more of the edges of flight dynamics envelopes. …so the LR F-4 is not “tuned” at all. It is a 100 percent natural, “raw” aircraft in X-Plane…Impressive!
This is David Byrns’ show, where he does our favorite songs from the Talking Heads with a really incredible way of presenting both the band and the music… A free and liberating way I’ve never seen before. The theater is a small venue where you are really right there with David enjoying his creativity. It’s the best show I’ve ever been to. It’s shutting down in 30 days so if you want to see this incredible experience you’re just about out of time. New York is opening back up again so there’s just a narrow window left to hang out with David Byrne and see this. Seize the day while you can!
Simply put, a photometric renderer is one that tries to create realism by using actual real world light levels (specified in real physical units) in its internal calculations. In other words, we render the world as it is.
A decade ago, the image of the world you saw through your simulator was essentially built out of pre-made images drawn in Photoshop by artists. These images were drawn as realistically as possible, but they were low dynamic range (LDR) because that’s all the monitor could handle. The sky was as blue as the art director decided, and then created with Photoshop. This worked great in its time, but with today’s modern graphics cards we can do much better.
First We Have to Go Higher
A traditional low dynamic range (LDR) renderer has colors in a range from 0 to 255, but if we want to model the real world, we’re going to need some much bigger numbers. We measure luminance in candela per meter squared (cd/m^2) or “nits” (nt). Here’s a Wikipedia chart listing the luminance of a wide variety of stuff. A few examples:
Flood lights on buildings at night – 2 nts.
An old crappy LDR monitor – 80 nts.
A nice newer LCD monitor – 500 nts.
The clear sky – 7000 nts.
Clouds – 10,000 nts.
The sun at sunset – 600,000 nts
The sun at noon – 1,600,000,000 nts.
(That last one is why your mother told you not to stare at the sun.)
Note how wide the range of numbers are: daytime images are made up of things in the “thousands” of nts, but with a wide range of variation, while night ones might be single digits.
So to be more realistic, the sim needed to render using bigger numbers. X-Plane 12’s rendering pipeline is entirely HDR, from start to finish, using 16-bit floating point encoding to hold a much wider dynamic range of luminance.
You Can Stare at the Sun in X-Plane
Obviously you can look at the sun in X-Plane on your LCD monitor and not suffer direct eye damage – the peak brightness of your monitor might be 100-500 nts. How do we show a scene with 10x the brightness of a monitor, or more? To solve this, we needed to model a real camera to serve as your “eyes” in the simulator. This camera in X-Plane sets an exposure value that maps our HDR scene to your monitor.
The dynamic range of computer monitors isn’t very large, though. To address that, we applied a tone mapper to the exposed image. The tone mapper is a tool that “squishes” some of the bright areas of the image so that we can fit a wider range of bright colors onto the screen at the same time. The tone mapper can give the simulated scene a look that’s more like an image from a film camera, rather than a cheap shoddy digital camera. Using the tone mapper, our art directors tuned the parameters of X-Plane’s camera to make our scene look brilliant and realistic, given the constraints of computer monitors.
The exposure levels in X-Plane 12 are set by our art team according to time and weather conditions. They are also modulated by auto-exposure, so that as you look around the scene the camera becomes more sensitive in dark areas (to help read panels) and less sensitive in bright areas (to avoid being blinded).
A Physical Sky
Now that the sim had a rendering that accurately modeled the real world, a sky that was painted by our art team using Photoshop just wouldn’t work. It needed a new sky that would match the light values (nits) of the real sky.
To do this, we calculated the light levels of the sky by considering the composition of the atmosphere, the viewing angle, and the brightness of the sun. The sky is blue for a reason (oxygen molecules) and we get a blue sky by simulating that scattering effect.
This math for the sky works when looking in any direction from any location, so we not only get a blue sky, but we get the correct “blue-ish” tint when looking at the ground from the air, and this matches the sky without the artists trying to hand-paint two effects to match.
Lighting It Up
To create a photometric world in X-Plane, we needed light sources in the sim to be specified in real-world units. X-Plane comes pre-programmed with the brightness of the sun, but how bright is that LCD screen in your glass cockpit? In X-Plane 12, aircraft designers specify these values in real world units.
One of the advantages of this real world approach is that the “right” value for setting up an aircraft can come from the real specifications of the aircraft, rather than tuning some numbers in a 3D editor until it looks right.
Harmonized Results
One of the big advantages of this approach is that all of the elements that make up the sim play well together because they are all calibrated to the same standard – the real world. How bright are landing lights compared to the airport lights? How visible are the taxi lights when the sun comes out? With a photometric rendering engine, the answers are determined mathematically and by measurements that can be checked against real life, so the entire scene fits together.
With photometric rendering, we’ve taken another step closer to real life – the new X-Plane 12 renderer simultaneously produces realistic images and is more straightforward to work with, all thanks to its use of real-world values as inputs. Check out the video below for an A/B comparison between the lighting in X-Plane 11 and X-Plane 12.
First, I appreciate everyone’s cooperation with the RFC on scenery; we’ve had an ongoing discussion in our developer Slack as well as the comment section, and I don’t think I had to nuke any off-topic comments. The feedback was wide-ranging and there’s no one clear answer but it does give us a really good picture of how the scenery system is working (and isn’t working).
It’s Friday, so let’s do something completely different – her’s some show and tell from a few things people have been working on things week.
Light It Up
Alex has been recalibrating the runway and airport lights for the new photometric lighting engine. This spurred an internal discussion about how best to calibrate artificial light sources. Does the author specify the luminance of the bulb before a tinted plastic housing goes on top (this way is good if you have the bulb specs from the internet) or based on what you’d measure when the finished light is tested? (This way matches FAA specs for airport lights.)
After going back and forth a few times, our answer is “well, both”, and we have a system that now allows this, which should solve use cases for both aircraft (where often the bulb properties are known because you can look up replacement parts) and for airports (where the FAA has standards for the light’s final results).
Something to keep in mind: urban airports are quite dark compared to their surroundings. Ther are very few light sources near the runway that aren’t tightly controlled for brightness and direction. I used to fly over KLAX on a regular basis at cruise altitudes (commuting from San Diego to San Francisco for work) and KLAX was always an inky black void in the sea of lights that is the LA basin; at 34,000 feet no runway lights are pointed up at us.
Wet Surfaces
Petr and Sidney have been working on the weather surface shader, which applies water and other weather effects to surfaces. This is how we dynamically make the pavement wet when it rains.
The shader is tricky because the effect of a surface being wet changes a lot once the water forms a real puddle. When I took my kids to their swim lesson, I couldn’t help but notice the useful reference material all over the place.
A rough wet material – reflections change with angle in X-Plane and real life
Stop Writing on the Windows
I must be a dad, because I get annoyed when my kids get finger prints all over the windows when they “write” things in the frost on a cold day.
Turns out Sidney does the same thing.
What you’re seeing there is programmer art. Programmer art is when the programmers make their own texture files to test code. In this case, Sidney is testing the defrosting system for windscreens, which use a special texture to specify the pattern of defrosting. This lets artists control the defrosting effect and get faster defrosting near vents.
Another “behind the scenes” thing you can see here: that popup window is a set of internal controls for testing, debugging and developing the windscreen effects. The parts of these internal controls that are generally useful will become third party developer tools (like the texture browser and particle system editor in X-Plane 11).
Cessna In Spaaaaaaaace
Daniel rewrote the planet shader. In X-Plane 12, water is treated separately from land (so that it can be 3-d). The new planet shader shows a far view of water and a far view of land at the same time and correctly shows atmospheric scattering, which is normally pre-calculated in a special “froxel cache” for regular scenery.
If you haven’t noticed the pattern, it’s that the art team’s screenshots all tend to look good enough to ship, and the programmer’s screen shots tend to be very, very silly. In this case, the Cessna in space is pretty silly, but what we were looking for was the smooth atmospheric effects all the way out to the horizon.
Here’s one more goofy programmer screenshot:
I was calibrating the runway lights according to Alex’s spec, and typed an extra 0 into one of the internal art controls by accident. The result was this fantastic screen shot.
What you’re seeing is: the billboards for the runway environment are accidentally huge and are filling up the entire reflection cube map. The reflective underside of the Cessna wing picks up this blue lights and it looks like a rave.
This post is a request for commentary (RFC) – that is, it’s the beginnings of a discussion on the specific topic of mesh and overlay scenery packs. A quick note on moderation: unlike normal blog posts, I’m going to kill all off-topic comments for this post. We’ll have non-RFC posts and the discussion will be more free-wheeling, but in this case the goal is to have the comments for the post really flesh out possible solutions to one specific problem.
With that in mind, our topic of discussion: how best to separate mesh and overlay scenery packs?
New Scenery Packs Can Cause Chaos
Here’s how scenery packs work now: all scenery packs in “Custom Scenery” out-rank all of the scenery packs that ship with X-Plane. Except we put some of our scenery packs into “Custom Scenery”, so that strict “customizations bypass default rule” is already a bit broken.
Within the custom scenery folder, the scenery_packs.ini file defines the priority order of packs (and can bypass packs). When the sim runs, new packs discovered at startup that aren’t in the .ini file are added to the front in alphabetical order. So “newly installed wins” is the effective policy.
Here are some things that go wrong:
When a new mesh scenery pack is installed, it goes to the top of the priority list, hiding default Gateway airports below it. Custom mesh authors often want the latest Gateway airports to “show through.”
If a user manually reorganizes their scenery packs, they need to keep custom overlay airports above the default Gateway airports but custom meshes below the Gateway airports. If the user just puts the Gateway airports at the top of the list, custom overlays get replaced.
We regularly see user logs with 500-1000 custom scenery packs, so while I think a nice UI to organize pack priority might be nice, I don’t think it solves these problems. Telling users “go rank 1000 random items in priority order” is impractical.
Separate Custom Overlays from Custom Meshes
So my first naive idea is to simply have two custom scenery folders: one for overlays and one for meshes. Every pack in the overlay folder would completely outrank the meshes folder. This idea begs a bunch of implementation questions:
What happens if a custom scenery pack is put in the wrong folder (e.g. a mesh in the overlay folder or overlay in the mesh folder)?
Where do Gateway airports go? Do they live in custom overlays (and if so are they always ranked last)? Or do they get buried somewhere inside Resources and always rank between overlays and meshes?
Where do library packs go? Library use isn’t mutually exclusive with overlays or meshes.
Is either folder “Custom Scenery” for compatibility? If not, do we simply have no “Custom Scenery” folder, or does that break too many add-ons?
One of the strengths of this idea is that it’s really dumb and simple, and sometimes when the problem is “we have a complex mess,” simple and easy to understand is better than “really clever.”
Automatically Prioritize Packs Upon Discovery
An alternative to two install locations would be to have X-Plane determine the pack type upon first discovery and then rank it in the priority list in the middle if it’s a mesh.
If this were to work, the win would be that it would “just work” with no changes for third parties or users. However, I think in practice it may not be practical – it would be a lot of file sniffing by X-Plane at startup, and the categories of mesh and overlay are a little bit fluid. If a pack contains an overlay and a mesh DSF, how do we categorize it? If the scenery packs are in some scattered order with meshes on top of overlays, where do we put the new scenery?
Author-Selected Rankings
Another lever we can pull is to allow scenery authors to annotate their packs (perhaps with a text file or new library.txt directive) indicating the appropriate installation ranking for the pack. This approach would be similar to automatic prioritization, except priorities would be explicit and cheap to discover.
Authors would opt in; some kind of default behavior would have to be defined for legacy packs. Some open questions:
How would authors define where they want their packs installed relative to other packs?
Would users still be able to customize ranking? If so, would weirdly-ordered packs make it difficult to prioritize new packs?
Author-Selected Sub-Folders Within Packs
This idea came up during some discussions in the third party developer Slack channel: we could introduce a scheme within scenery packs to allow a single scenery pack to include both base meshes and overlays. X-Plane would automatically load all overlays from within these packs first, then global airports, then all base meshes. There’s some nice wins here:
This scheme puts the burden of correct organization on authors, not users, which is better for support load for third party authors – third party authors already need to know how the scenery system works in detail.
This scheme solves a related problem: packs that contain a base mesh and a few custom airports can now be distributed as a single pack rather than several packs that are each installed separately.
Categorization of packs is cheap, as it is simply based on file location.
Thomson and Philipp are at FlightSimExpo in San Diego; at 2 pm PDT (5 pm EDT) he’ll be showing our video presentation. You can watch it here or on our Youtube channel.
Back in June, Ben shared some information regarding X-Plane’s next generation lighting pipeline. It’s now time to go back to the future and talk about another piece of the next generation: Vegetation. In case you have missed it, Chris and Thomson made an awesome preview video for this as well:
If you’ve been experiencing frustration with the airport locking mechanism on the Gateway, it’s probably my fault! The logic behind this feature was changed recently and it kinda caught us out. All of this deserved an explanation, and some further tweaking from us to make things better.
Background
To protect against two artists working on the same airport, some time ago we introduced the capability to ‘lock’ an airport on the Gateway (for the duration of its development cycle). Originally this feature was unlimited, but was later revised to restrict the number of simultaneous locks that could be taken.
Recent changes
The original locking mechanism was better than nothing, but not much. There was no intelligence behind it, that is to say, nothing to prevent an artist from holding an airport indefinitely (by releasing and renewing the lock) and no taking into account previous submission history for a given artist. As a result, we sometimes heard from frustrated artists that a certain high profile airport was being held for a silly long time by a newbie. Another source of frustration was not being able to lock enough airports to keep busy, a direct result of us trying to solve an earlier problem that artists were occasionally holding too many airports!
So, we brainstormed a new design that took into account each artist’s skill set and submission history. Higher skill sets = more airports that can be locked, more and longer extension periods. Locking an airport and then abandoning it without making a submission = fewer airports that can be locked, fewer and shorter extension periods. I signed off on the new design and Daniela (as always) did a beautiful job coding it to the exact specifications.
Shortly after we went live there was a noticeable drop in Gateway submission levels. This sometimes happens, and I attributed it to the normal ebb and flow. However, it has since become apparent there is more to this. The new ‘locking’ mechanism that was supposed to make things better and fairer was having the opposite effect. At first I could not understand this–surely artists don’t need to lock more airports than they can simultaneously work on? But of course this is wrong! The problem is that, during the wait period between submission and moderation, the airport must remain locked, and hence an artist potentially needs to hold onto a bunch of airports that are ‘in limbo’. No doubt everyone in the community already knew this, but I failed to take it into account when signing off on the new logic.
The Solution
The solution is to not tally airports that are waiting ‘in limbo’. This means as soon as you submit your airport, it is no longer tallied against your lock total (but is still locked in an absolute sense, and therefore cannot be claimed by another artist). One thing to be aware of – when an airport becomes approved or declined, it ceases to be in limbo, and WILL be tallied against an artist’s lock count. It’s important therefore to manually release locks that are in effect, but no longer needed.
If you’re reading this, it’s already done. Things should be a little better!
It’s been very busy here internally, but a few things to mention.
X-Plane 11.55 – Crash Fix
We’re focusing almost all of our effort on future technology, but Stairport reported a bug severe enough that we went for a patch: X-Plane would randomly crash when plugins use the new “instancing” drawing APIs.
The instancing APIs are the Vulkan-compatible way to draw objects from plugins, the way to add particle effects via plugins, and will someday support sound as well. Simply put, instancing is meant to be the foundation for plugin-created dynamic content. Third parties did a great job of switching to instancing to be Vulkan compatible when we released X-Plane 11.50, so having this API be rock-solid is really important.
With X-Plane 11.55, correctly written add-ons should “just work.” The interaction between instancing and datarefs does sometimes confuse developers, so I’ll cover that in some nerdy detail in a future post.
The Latest Gateway Airports
While we were cutting a hot patch, we took another set of airports from the X-Plane Airport Scenery Gateway – 11.55 features over 1000 new 3-d airports and 443 brand new airports. I remain amazed at the Gateway community’s progress and results.
I’m excited to finally be able to talk about something I’ve been working on for a while now – the new photometric lighting pipeline. Here’s the preview video Chris and Thomson made:
X-Plane’s lighting and rendering have leveled up several times – in X-Plane 10 we moved to HDR with global lighting, and in X-Plane 11 we introduced Physically Based Rendering.
I know this kills, but it’s too soon to talk about release dates. I can say a little bit about what you’re seeing in the video though.
First, the new lighting pipeline is photometric. What that means is that color values during rendering match real world values (in real world units) through-out the entire rendering process. Rather than say “1.0 is a bright thing, and, um, 4.0 is a really bright thing”, with photometric rendering, there are real answers. The sun is about 120,000 lux. The blue sky might be 8000 cd/m^2. A landing light on the 737 might be 200,000 candela at its peak intensity.
The idea behind photometric rendering is to have all elements of the scene be calibrated to real world values so they all match each other. That cloud should match that sky and that airplane because they’re all in the same units. No more tweaks to try to make things match.
We shipped an HDR renderer years ago, but the new pipeline is, well, more HDR. A lot more HDR. Because we’re working in real world units, we have to maintain a wide HDR image from beginning right to the very end when we tone map. The result is that every part of the scene can have a wide dynamic range.
While our shipping pipeline dims displays during the day by darkening them (to give the appearance of wash-out), the new pipeline simply draws everything in real world units – the camera is simply set for day time exposure (set in real EV units like a real camera) and the displays look dim due to the camera.
The new pipeline features a new tone mapper – one thing you might notice from the videos is that color with the new pipeline are richer. This is partly because the new tone mapper (which works well with real-world illumination values and is HDR-display-ready) does a better job of preserving saturation.
Sun and sky colors in the new pipeline are driven by a new atmosphere and sky simulation – they’re not painted textures. We get the sun color from the composition of the atmosphere and the relative position of the sun and scenery.
Finally, the new pipeline can run screen space reflections (SSR), dynamic exposure, bloom and other effects (still to be previewed), all running with real world photometric HDR values.
Why Photometric Rendering?
The photometric renderer gets us a bunch of visual quality improvements and new effects that were high on our TODO list (and, based on the feedback site, yours too.)
Photometric rendering also serves as a foundation for a bunch of other features that are high on our priority list. That will be a topic of a future preview and a future blog post.
X-Plane can be configured to model real-world weather conditions. It does this by downloading weather report data from a server, operated by Laminar Research. That server, in turn, periodically fetches three total files from two different sources at NOAA: one for METAR-format weather condition data, and another source for two grib2-format files describing, separately, winds and turbulence. Internally, we tend to refer to this system, overall, as Live Weather, or, in the context of anything server-related, just Weather.
Around March 22nd, it broke down.
What went wrong
As is often the case: several things.
X-Plane began reporting that it couldn’t fetch all the data it needed for real-world weather. This was a little surprising since our weather server is supposed to cache the latest data it received, even if it’s outdated, to smooth over any connectivity or availability issues with NOAA’s servers. Further investigation revealed that only one of the three files it needed was both missing from its local cache, and unavailable from NOAA.
The root cause of that data being absent from cache hasn’t been tracked down, for the reason that that part of the system has been replaced (see below). There may be a bug in the caching logic. The server may have suffered a silent crash-and-restart some time after NOAA stopped serving the file. We’re not sure.
Investigation into the causes of the missing data was sidetracked for a little while because, right around the same time, NOAA happened to suffer a widely-reported, significant disruption to their networks and server operations. Naturally, we initially assumed this was the cause of the problem, and our efforts were mainly aimed at mitigating the harm of a temporary outage, not dealing with a longer-term problem.
In fact, what had happened was a longer-term problem, and the outage was, at most, only part of the cause of the disruption we were seeing.
In which we miss a NOAA systems upgrade
Effective on or about March 22, 2021, beginning with the 1200 Coordinated Universal Time (UTC) run, the National Centers for Environmental Prediction (NCEP) will upgrade the GFS and Global Data Assimilation System (GDAS) from version 15.3 to 16.0.
NOAA Service Change Notice 21-20 (Updated)
What that means is that X-Plane’s Live Weather system was about to break.
The system mentioned in that notice is the one that provides turbulence and wind data for the Live Weather system. These are the grib2-formatted files mentioned above.
Some time into this minor crisis, we noticed that both, not just one, of those files were missing—one had been properly cached, as intended, so it’d initially escaped our notice—and that the directory structure and file naming conventions on the NOAA server from which we source them had changed. Then we found the PDF containing the notice quoted above. Nestled deep in that PDF was the line:
Remove WAFS blended product at 1.25 deg
This refers to the file we used for turbulence data. The wind data we’d been using we could still find, albeit in a new location, but here was confirmation that the turbulence data we’d been using was simply gone.
In which various solutions fail
Our situation at this point was: we had found our wind-data grib2 file, and we had several WAFS (World Area Forecast System) files that looked, judging solely from their names, like they might contain the turbulence data we needed.
None of this was true.
We learned that the NOAA system upgrade had included an upgrade to the compression used on their grib2 files. X-Plane couldn’t understand it, and in internal testing actually crashed when attempting to use these files. That meant that though we had found a file containing the same data we needed for wind, we couldn’t actually use it.
Also, none of the other WAFS-related files contained the same turbulence data we’d been using, nor anything readily translatable to same.
So much for the easy solutions.
Fortran: friend or foe?
NOAA provides a program called cnvgrib to convert grib files to other sorts of grib files—for instance, as one might guess from references above to grib2, there is a grib1 that predated it, and cnvgrb can turn one into the other. It can also, most usefully to our situation, change the compression scheme used by grib2 files, so it should let us turn these new grib2 files into something we can use without having to modify X-Plane itself. Missing turbulence data aside, at least we could convert the wind data grib2 files to be usable.
Fortran is a… let’s say venerable programming language, like, for instance, COBOL. It’s a bit obscure these days, outside certain very long-lived systems and niche applications.
Cnvgrib is written in Fortran, and no recent compiled binary version is available. The Fortran (with some support from C) source code is provided by NOAA, though, along with instructions for compilation.
One Linux VM, a couple hours, and 17GB(?!) of Intel compilers and tools later, and we have a compiled copy of cnvgrib. As hoped, it can turn the new-compression grib2 files into old-compression grib2 files that X-Plane can understand.
There’s still the matter of the turbulence data, though.
Enter the Matrix
I skipped ahead a little. At this point in the troubleshooting process we hadn’t yet noticed that the turbulence data from NOAA wasn’t the same as what we’d been getting before, and once we could convert it to grib2 files that X-Plane could handle, it even looked like it was working.
So we deployed it.
By “it” I mean a very low-tech shell script that periodically downloads the two files we need from NOAA and uses cnvgrib to make them usable by X-Plane.
90s legible-clothing Geek Chic slogans at their finest. Also, I did actually do this to about 2/3 of the existing weather server.
Though this apparently worked, we quickly realized something was very wrong when support began fielding reports of way-too-powerful wind in X-Plane, when using the real-world weather feature. This was caused by X-Plane applying inappropriate turbulence modifiers to wind effects, because we were feeding it (from its perspective) bad data.
Having no new source of the turbulence data we had been using, and with the new data causing serious issues, what could we do without cutting a new release of X-Plane?
As it happens, we’d snagged exactly one of the old WAFS-Blended files, containing the kind of turbulence data X-Plane could use, from the NOAA servers, before they dropped off forever.
Yeah. It is.
The clear stop-gap solution, then, was to simply serve the working, reasonable turbulence-data file that we’d saved. All the time. Even though it’s increasingly outdated and definitely not “Real-World” anymore.
That’s right: so far as turbulence data goes, if you’re playing X-Plane with real-world weather turned on, you’re trapped in an old facsimile of the real world. You’re in The Matrix.
Fortunately, the effect of turbulence is minor enough, overall, that this doesn’t throw things off too badly (most of the time) and having some outdated real-world data is better than having none. Still, if you notice things behaving just slightly strangely—or if you have a sense of deja vu with real-world weather turbulence while flying—that may be why. The Matrix has you.
Are we going to keep lying to X-Plane about turbulence forever, then?
Nope! We’re working on translating other forms of turbulence data into something usable by existing copies of X-Plane, and have plans to make future versions of the Live Weather system more robust so that, hopefully, it won’t fail again—at least not in the same way.
