Deciding what altitude a particular flight segment needs shouldn’t be tricky, right? You take off from somewhere near ground level, you climb to whatever you chose for cruise altitude, you start to descend when you get near the destination and eventually end up on the ground again. What could possibly go wrong?
Why, I’m glad you asked! Make yourselves comfortable, this might take some time.
A bug report arrived from someone saying they’d been vectored into a hillside on approach. That’s something that has had a lot of attention given to it for X-Plane 12, so I jumped on it and reproduced the flight. Happily the person reporting had included the correct logfile (not everyone does, we get loads where the log shows the sim sitting at the main menu!) and given the flightplan details; nothing complicated, a simple direct flight between two airports about 35 miles apart, cruising at 6000 feet.
I set it up and let the AI fly. Takeoff was fine, and then it was told to climb to 8000 feet – above the requested cruise altitude. Checking the map, okay, there was a mountain ridge in the way so that makes sense. Then the problems started. Descend to 7000, then descend to 5500, then climb to 7000, then an endless loop of climb/descend to what looked like random choices of 5000, 6000, 7000 and 8000 feet.
All of the “normal” – and a lot of the unusual – situations for approach and landing are covered in automated tests and they’d last passed the previous day, so I knew that this wasn’t a common problem but it would still be damned annoying if it happened to you.
Digging in a bit, the first thing I found was a good old-fashioned bug. Before X-Plane 12, the ATC system was pretty much exclusively written for airliners and an old bit of code had a problem where, if you were below a normal cruising altitude for an airliner, you might be told to climb slightly before starting the descent. This was kicking in because, when the AI was handed off from tower to the next level controller, it was already close enough to the destination airfield to be seen as an incoming arrival.
If you think about it, this completely breaks the simple altitude model already. The Cessna 172 climbs slowly, so it was approaching the whole “descend, approach, land” sequence from below. X-Plane 12 is wise to this though, so it shouldn’t have been a problem.
So, we’ve got one inappropriate climb instruction sorted. Re-test.
As expected, much the same as before; total indecision on the part of the controller. The next problem soon comes to light: terrain avoidance.
On the face of it, terrain avoidance should also be simple: If hill then climb. Most of the time, it is. Where that falls down is where you’re deliberately trying to get close to the ground like, say, during approach and landing.
If you’re familiar with aviation charts, you’ll know the acronym MSA – Minimum Safe Altitude. Basically the chart is divided into large squares and, in each square, there’s an MSA given. If you fly through that square, you’ll be guaranteed not to hit the ground if you stay above that altitude. It’s simple, it works, and X-Plane does pretty much exactly the same. The terrain elevation data is reduced so that a single pixel gives the MSA for whatever area that pixel covers, and this makes it relatively quick and easy to check.
MSAs departing to the northMSAs departing to the south
This flight had a couple of steep ridges going from sea-level to about 6,200 feet which ended just inside one MSA square, and the flight was going just along the top of it at about 90 degrees to the ridges. A few hundred meters difference in location when the terrain samples were taken were enough to change the MSA between about 50 feet and 6,200 feet.
Sample points giving a segment MSA
Checking a little to either side of the route can make this problem more or less go away, and that’s done in some places, but it can’t be used during approach because you’re actively trying to get close to the ground. If you went wide on the terrain checking, you’d never be allowed to land at any airport in a valley or just generally mountainous terrain.
So, back to the problem. The terrain avoidance systems were getting two very different readings depending on both exact timing and position because they were just clipping the edge of the MSA squares and one of those squares covered high ridges which finished at sea level just inside the square’s boundary. One moment it would think you had 5,000 feet of clear air beneath you, the next it was asking the poor, confused AI to climb to avoid terrain.
This problem can’t really be fixed as such, but it can be improved by reducing the sample distance and using full-resolution elevation data instead of the MSA-square summary. The problem with that is that it’s more expensive in CPU terms so it can’t be done all the time. Think of a flight from London to Delhi; checking that for every 30 meters along the route is going to take a long time, and not all of the high-res data is even in memory at once. However, high-res data is already used in some cases, notably for short legs close to the MSA or for known approach legs, but this was happening on a longer cross-country leg which happened to be the one before the actual approach started. Still, easy enough to adjust for that so let’s do that and see what happens.
The next flights were much, much better. Yay! Go for a celebratory coffee, but something nags at the back of my mind.
Coffee over, check the exact routes on the map (anyone can do this – it’s on the Developer menu as “Toggle Air Traffic Paths”). Yep. The wind had changed – I had real weather enabled – and the cross-country leg was starting a couple of miles further north, which meant that all the nonsense with clipping corners in the terrain avoidance code had simply stopped being an issue.
Righto.
Set manual weather, re-test, and… well, it’s better, but still bouncing between two different altitudes even though the MSA’s now more or less stable.
If you remember, this is all happening during approach. When these segments are created, the terrain clearance for each one is checked and the overall approach profile is modified so that you’re not told to descend to the normal altitude, then climb again for terrain avoidance for a later part of the approach. For this flight, the destination airport was on the plains near the coast but surrounded by high mountains to the south, so this system was kicking in and keeping the approach altitudes much higher than they would normally be. However, there’s one more waypoint involved; this is created somewhere between you and the airport and used as a kind of gateway between cruise and approach. The segment after this waypoint was also being terrain-checked, but if any terrain-related adjustments were made to the subsequent approach segments, they weren’t being pushed backwards onto this pre-approach leg. Normally, this wouldn’t happen and even if the approach were modified to clear terrain, it would have to be a very unusual, large adjustment to kick the approach legs higher than the pre-approach waypoint.
Yep, you guessed it.
Still, at least that’s a simple one to fix. Do that, re-test.
This fix is good and the next set of altitudes is… oddly low. So low, in fact, that the “oh shit” mode of the terrain avoidance kicks in. This ignores the route entirely and just uses the plane’s recent movements to predict a near-future location and checks that. This means that the MSA is being ignored somewhere, and there’s now a missing climb instruction.
More testing and this turns out to be caused by a check, during approach, which tries to avoid unnecessary climb instructions. If you’re already at low altitude and call in to an airport to land – i.e. a typical small-plane flight – you don’t want to be told to climb thousands of feet only to descend back to pretty much the altitude you’re already at. So, the controller tries to be nice and lowers parts of the approach if you’re already underneath it. That’s all fine, but… not… if… the approach has been raised to avoid terrain!
Fix that, re-test.
All is well for the first half of the flight. I know, from watching the code as it runs, that from here on in the MSA should be in the region of 5,200 to 7,200 feet depending on the exact timing. High resolution elevation data is being used now, the two mountain ridges are steep from left to right and fairly narrow back to front in relation to the flight direction, so the MSA can vary quite quickly. The expected climb instruction comes in: “Climb to FL080”. Wait; eight thousand?
This was a flight-level though. Checking the transition altitude (the point where it stops using “feet” for altitude and starts using “flight level” and a specific set of rules for choosing them) for the approach controller shows that it’s set at 6000 feet. Yet again, tiny changes in both timing and position were affecting the MSA, but this time it was because the high-resolution elevation data was being used. For the low end, a simple “add some wiggle room and round up to the next 500 feet” was coming up with either 5500 or 6000 feet. At the high end, it was being rounded up into flight-level territory and, because of the direction of flight, punted upwards to either FL070 or FL080. This was only happening because the requested altitude in the plan was exactly on the transition altitude!
Okay, so this one’s probably confusing, but not technically wrong – certainly within the limits of the system.
So the original, simple “Let the AI fly a route and see if it starts tunnelling” check has now taken three days to properly resolve, between investigation, code changes, many re-tests, and then validating the changes on a larger scale using the existing automated tests. On the plus side, it’s been an absolute torture-test for a number of systems which worked just fine in most circumstances, and has brought out problems that were able to be either fixed or at least explained. On the down-side… yeesh!
For a normal flight, none of this would have been a problem. You’d be way above the terrain, descending onto the approach from above. This flight was short, so the slow-climbing Cessna 172 was still on climbout when the approach vectors were issued for altitudes higher than it was currently at. In between the two airports there were ridges which just clipped terrain-altitude data squares so MSA checks returned altitudes which varied significantly with tiny variations in both position and timing. The destination airport had no flows defined, so X-Plane was auto-generating them, but this doesn’t look at terrain so thanks to the airport being in a steep valley, the MSA of the approach vectors unusually remained at 4,500 feet all the way in to final for an airport close to sea-level. Finally, the planned altitude was exactly the controller’s transition altitude, magnifying small differences which would normally be rounded away.
If either airport had been a few miles north or south, or further apart; if the ridges had stopped a few miles further south; if the coast had been a few miles north or south; if the aircraft in use had been able to climb to cruise altitude faster; if the plan had requested an altitude which was above the controller’s transition altitude; if the terrain MSAs hadn’t also straddled the transition altitude; if the airport had defined flows which prevented landings from the south; if the wind had been different. If any of these things had not been exactly as they were, little or none of this would have happened.
So, my – er – thanks to the person that filed this bug report! Completely by accident, you sent several systems beyond what they were able to do and, by filing the report and actually attaching the log from the same flight, allowed me to dig into the system and get rid of a good number of rough edges. It’s also given a fantastic example of “Pssh, how hard can it be?” for the obvious assumption of “well, you climb, then you descend, job done”.
Plus a couple of sleepless nights, but hey.
Oh, the “vectored into a hill” problem? Couldn’t reproduce it.
Well, this is embarrassing. I’ve been meaning to post to the dev blog for months now; all sorts of new features, important bug fixes, and interesting tech has gone by. As you can imagine, it’s been really, really busy with the release of X-Plane 12 and subsequent updates, plus a number of us spend time in the dev lobby trying to help third parties and sharing pre-release experimental code.
So this post will be a quick overview of some of what has been going on and what is coming.
Move Fast and Fix Things (Hopefully)
Since we shipped X-Plane 12.00, we’ve been aiming for a fast tempo for updates and patches; more frequent, smaller patches so we can get key bug fixes to the entire community quickly. X-Plane 11 had one or two updates a year, and each update would take three months in beta because it was crammed to the gills with features. We’re targeting less than a month with these patches.
Here’s what we have shipped so far:
12.01 – lots and lots of bug fixes, new weather datarefs, and new OBJ features to help aircraft authors move to X-Plane 12.
12.02 – fixed memory leaks.
12.03 – scenery fixes, approach light fixes, and library elements to unlock the X-Plane Scenery Gateway
12.04 – in beta now! New plugin APIs (dataref introspection, sound APIs, weather APIs), weather fixes.
If there’s a theme here, it’s sanding down the rough edges of 12.0 and making sure third parties can create add-ons for v12.
Some Details: Sound
In X-Plane 11, we moved to FMOD as our sound engine; in X-Plane 12, X-Plane does not use OpenAL at all. Add-on developers have two choices:
You can still use OpenAL, but you have to include it in your add-on yourself.
Use FMOD! The X-Plane SDK has a new XPLMSound API that provides basic sound capabilities and a bridge to FMOD for advanced use.
Using FMOD lets your add-on create sound within X-Plane’s 3-d environment.
Another way to add sound: in X-Plane 12, objects added by plugins via the XPLMInstance API can include .snd files and attached sounds, just like aircraft. We use this on our ground trucks, and you can use it too.
Some Details: Approach Lights
In getting the scenery system ready for Gateway authors to create airports, we fixed a few long-standing problems for approach lights:
Approach lights will now appear over water even if you use a pier. So you can model the piers for approach lights (e.g. at KBOS, KSFO) while using the built in approach lights.
Approach lights can sit on top of gantries when they need more height, like you’d see at KBWI (see runway 10) or Dallas Love Field.
The scenery has the approach lights and approach path cut out from the autogen so you can see the lights and make it to the runway. You don’t need to use exclusion zones – the cut DSFs are more precise.
Always use the built-in approach lights – you cannot create the ‘rabbit’ strobe in an approach sequence by hand-placing the lights, so we wanted to make the built-in ones work.
What’s Coming Next
There’s a lot more we’re working on, which I’ll discuss in a future post, but here are a few hilights:
The airbus FMC is close to being ready to show – there’s a ton of new tech there.
We are rewriting a piece of the rendering engine to use VRAM much more efficiently. This should help fix blurry textures.
Lots of bug fixes and improvements to cloud rendering, including performance optimizations.
Bug fixes and improvements for physics and systems.
Several features are down-stream of improving VRAM efficiency:
We’re not happy with how orthophotos and the new water system interact, but we need the more efficient VRAM system to fix this. I’ll post about orthophoto authoring as soon as we have more information.
We have improved bloom, also dependent on the new VRAM system.
We may bring back a lighter version of exposure fusion – this will be up to the art team to decide if or how they want to use it.
Beta 6 of X-Plane 12 Early Access is available on Steam & through the Laminar Research installer. You should be prompted to auto update the next time you launch the sim, if you haven’t already. Here is a link to Early Access release notes.
This version should fix the problems launching via Steam on Linux. It also has more fixes for magenta NaNs, so hopefully there is more or widespread relief on that front.
We’ve heard multiple reports about external visual networking being broken since beta 4, and we are currently investigating.
Finally, X-Plane 12.00 beta 6 includes internal changes to support the .ktx2 texture format. We are working on tools and documentation to go with these engine changes, and will post detailed information on how to use .ktx2 once the specs and tools are complete.
Beta 5 of X-Plane 12 Early Access is available on Steam & through the Laminar Research installer. You should be prompted to auto update the next time you launch the sim, if you haven’t already. Here is a link to Early Access release notes.
This build contains a fix for the crash at start many of you reported in beta 4. So again, if you are still seeing it, let us know by filing or re-filing a bug. Windows users should include their email in the crash report so we can find your specific crash. Mac users should send the Apple crash log with their report. We are actively working on restoring auto crash reporting on Linux.
We’ve heard a lot of reports that Steam users on Linux have been unable to launch the sim since beta 4, and beta 5 is no different unfortunately. We are investigating with Steam now.
Beta 4 of X-Plane 12 Early Access is available on Steam & through the Laminar Research installer. You should be prompted to auto update the next time you launch the sim, if you haven’t already. Here is a link to Early Access release notes.
This build contains multiple crash fixes, as well as our first go at fixing the magenta (aka pink or purple) sadness. X-Plane renders magenta when it hits a numeric error (a NaN value) inside the rendering engine. There may be multiple causes of NaNs – it’s not all one bug because magenta is a symptom, not a cause, and each bug has to be squashed one by one.
Don’t be surprised if some users see less magenta in the this beta and others do not. If you still see it, please file (or re-file) a bug that includes a screenshot or two of where you see it, and any steps needed to reproduce it.
We’ll start with the wings, which I’ve found to be very important:
The entire flight model is based on a new type of memory-access that is fast for the product you get, but slower and constantly self-checking for the internal builds we run for testing. We now have vectors of props, wings, and bodies… and access those vectors by accessors that hop right through to the memory for speed in the delivered sim, but do bounds-checking first to make sure no illegal accesses are even REQUESTED in our internal self-check builds. This entire new architecture, coded by me in the first month or so of the virus – when I could not even leave my house – sets us up with a platform that is flexible, fast, and bullet-proof to use. This new architecture allows for up to 16 engines and props, which is useful for the new generation of eVTOLs, many of which have more than 8 motors and props!
Now, for these wings and prop blades, we now allow THREE airfoil files per wing, not two like we used to, so you can have root, middle, and tip airfoils, which is especially useful for propellers! Well-modeled props have thick airfoil files at the root, mid airfoil files at the mid-span, and then go to a very thin foil right out at the tip to delay shock-wave formation at high speed. We now allow all the Reynolds numbers you like for each foil, so the way to get variation with Reynolds numbers is to put them in the airfoil files in Airfoil-Maker.. we don’t have multiple slots for different Reynolds numbers in Plane-Maker any more: that was always limited and awkward: It’s much better to save all your data for different Reynolds numbers for your airfoils in Airfoil-Maker, so that’s what we do now.
So everything you are about to read about is based on a new, high-speed, self-checking memory-layout that allows 16 engines and props, and 3 airfoils per flying surface.
First off: Wing sweep improvements. As air approaches a wing, it has to SPEED UP to get out of the way of the metal. It has to speed up to go around the wing! As a wing approaches the speed of sound, therefore, the air near the wing (still speeding up!) must EXCEED the speed of sound to get out of the way of the wing fast enough! In other words, the air around the wing goes supersonic even when the wing itself is still below the speed of sound. This causes shock waves, huge drag, and even loss of lift. The thicker the wing, the more the air has to accelerate to get around it, and the greater this effect. Nobody wants all this extra drag as they fly at airliner speeds (which DO approach the speed of sound) so in World War 2 the Germans came up with a way to cheat: Sweep the wing!
When the wing is swept back, the airfoil SEEMS THINNER to the air. That means that the air is in less of a rush to get out of the way: That localized supersonic flow, and shock waves and drag that result, are delayed! You can go faster before you run into these shock waves. But here’s the thing: You can only cheat so much! No matter how swept the wing is, once your airplane is going Mach 1.00, you have fully supersonic flow over every bit of that wing: You can’t escape supersonic flow with wing sweep! Wing sweep only makes the wing seem THINNER, letting the air accelerate LESS get around it, letting you get CLOSER to Mach 1.0 before you see supersonic flow over the wing! The thinnest, most highly-swept wing in the world will not AVOID supersonic flow, it will just let you get much CLOSER to Mach 1.0 before you get supersonic flow, and drag. X-Plane 12 now understands all of this, and invokes transonic drag at the right time based on wing-sweep, and transitions to fully supersonic flow by the time the aircraft Mach Number hits 1.0. It’s a nice interpolation from the subsonic to supersonic flow models as the flow goes from transonic to fully sonic on the wing! Back in X-Plane 11, the simulator delayed supersonic flow based on wing sweep until some value PAST Mach 1.0, which was erroneous! Forget that! So here is what version 11 did wrong: X-Plane 11 simply imagined that the effective airflow over the wing was multiplied by the cosine of the wing sweep. In other words, X-Plane 11 though that if you had wing sweep, that meant that you got out of challenging the air head-on, and it reduced the effective airspeed over the wing since the wing was getting out of a direct confrontation with the air by sliding through it sideways. This was so close, but not as good as it could have been.
To REALLY get it right, we need to understand that as you approach Mach 1, we do NOT imply REDUCE THE SPEED over the wing by the cosine of the wing sweep: Instead, we are making the AIRFOIL THINNER by the cosine of the wing sweep. Mach-1 flow hitting the wing is still Mach-1 flow over the wing! Wing sweep only makes the wing appear thinner to the arriving airflow.. it does not actually reduce the speed over the wing. This is really subtle, but matters a lot for transonic drag (drag from the formation of shock waves as we APPROACH Mach 1), so we will see more accurate formation of shock waves and resulting rise in transonic drag in X-Plane 12 than we did in version 11: Make sure your wing sweep is entered correctly, make sure you airfoil thickness is entered correctly in Plane-Maker, and expect drag rise as you approach Mach 1. Thinner, more-swept airfoils will be called for, the closer you get to Mach 1. The real Citation X (and the simulated Citation X in X-Plane, of course) are perfect examples of how important these two factors are in approaching Mach 1: The wing of that airplane is very very thin and very highly swept.
New tire rolling coefficient of friction data:
Observe these charts:
As you see above, rolling coeffs go from about 0.006 to 0.01 for high-pressure tires, and 0.01 to 0.02 for more medium pressure tires.
So your planes should probably use 0.008 for the airliners and fighters, And about 0.016 for the general aviation airplanes, And about 0.040 for the piper.
Everyone that enters airplanes themselves should go to Plane-Maker and set tire coefficient of fric to about 0.008 for airliners to 0.01 for lower pressure airliners to 0.02 for light planes to 0.04 for very low pressure tires like the tundra tires on the Piper Cub.
Hydroplane speed more accurate, and on-wet friction a bit higher.
Water: Improved floatplane dynamics!
I’ve been working with Bridger Aerospace to get their fire-fighting seaplanes simulated, and the result is really incredible. It took about FIFTY different alpha builds, each one with further-refined water dynamics, but we finally have the parasite drag, wave drag, plowing, step-taxiing, running on the step, wave interaction, and even drag from the scoops on the firefighters that grab water all simulated properly for Bridger to train their next generation of pilots! So the float-plane dynamics in X-Plane 12 are now professional-grade, for people that fly float-planes to put out fires for a living!
In addition to the dynamics of the floats themselves, we have better rendered wake, wind and wave correlation, and even docking with hard docks!
One subtlety is the new wave height paradigm:
Enter the wind and stuff, and look at the wave height slider: You see the range of heights as a little tip at the bottom, so you can drag the wave height slider accordingly for the conditions you want to fly… Then, at right you see the little tip on the wavelength and speed that results from the height entered We are doing first-principles with wave length and speed, and they match up with your chart pretty close, so I think we are good there.
For real-weather, the wave height is auto-set to the SHELTERED case, based on the lowest-alt winds So I think that has us where we want to be, with plenty of little notes there in the UI to show us what is going on… and give instructors the ability to set conditions as desired.. with the notes on the defaults available to them of course
Whew!
OK I like this paradigm a lot: Total flexibility, with super-easy normal-case references available at-a-glance.
Corrected spoiler dynamics, very noticeable on airliners and the F-14!
This is big: The spoiler effects were TOO WEAK in version 11. This meant that in the sim, all the planes that used roll spoilers, which certainly includes airliners, rolled too slowly!
As a result, many people over-sized their spoilers to get the desired roll-rate… and got too much DRAG from those over-sized spoilers as a result!
Sigh.
This has now been fixed for X-Plane 12!
NOTE: Aircraft designers should now go into their aircraft and make sure that they have entered the correct sizes for their spoilers.. they should now get more-accurate results!
Just a quick note that beta 3 of X-Plane 12 Early Access is available. You should be prompted to auto update the next time you launch the sim, if you haven’t already. Here is a link to Early Access release notes.
Beta 4 is currently in the works, going through test so we can release it next week. We expect to have our first go at fixing the magenta (aka pink or purple) sadness in that release, so please hold off on filing any further bug reports on this until you can try beta 4.
And this just in: X-Plane 12 for Steam is now available!
Well, this has been a crazy couple of weeks. X-Plane 12.00 is now available for Early Access – in other words, everyone can get X-Plane 12. Over the next few weeks we will post more about ongoing development and get into some of the new features in depth – there’s a ton to talk about in X-Plane 12. For today, here are just a few notes on some issues that have come up over the last few days.
Early Access
X-Plane 12 has been in a private alpha test program with third parties since December (!) – almost nine months. During that time we built 38 (!) official alpha builds, recut the global scenery five times, and committed over 4000 checkins to X-Plane’s source code (plus more to the aircraft, scenery tools and art libraries). The alpha program included completion of major features, lots of debugging, and changing the product in response to early alpha feedback.
So why Early Access now? Not because X-Plane 12.0 is done – we still have over two hundred open bugs and a lot of things we want to do. X-Plane 12 is in Early Access so that the entire X-Plane community can be involved in X-Plane 12’s growth, not just a limited number of testers.
With X-Plane 12.0 in early access, we don’t have to say ‘no’ to users and devs who want to get started with 12, and third parties can get their entire teams using the new sim and run their own test programs.
(We can also finally open up our developer relations program to a wider audience.)
Major Areas of Work
Here are some of the major areas of work ahead of us:
Clouds – we are working on the shaping and quality of clouds, improving resolution, fixing artifacts, and improving performance. Clouds are probably the single most expensive part of the renderer, so they are a constant tug-of-war between quality and speed.
Lighting – there are quite a few lighting and atmospheric scattering bugs that affect the sim, as well as work to do improving auto-exposure and tone mapping.
Philipp is working on an airbus MCDU, which we expect to ship during early access.
Third party interfaces – we have a few new SDK and authoring features that are mostly completed that will ship during early access. The elephant in the room is third party access to the weather system.
That’s One Blurry Airbus
X-Plane 12 moves some work that used to be on the CPU to the GPU (looking at you, ocean waves!), and virtually all new computing work in X-Plane 12 is on the GPU. When we discussed this before Early Access, there was a lot of teeth gnashing. “You’re gonna use more GPU power? I can’t buy a 3080, I’d have to sell my kidney!”
We still have a lot of GPU optimization left to do, but we also spent some time before beta 1 working on performance, particularly at intermediate settings. User with high end hardware have been pleasantly surprised to see production-level FPS in beta 1, and a common request is “I have 60 fps and blurry clouds, can I get a higher max setting.”
(I do suspect there is a huge gulf between the haves and have-nots for GPU power – because there’s a huge range of hardware performance amongst our users. We will keep optimizing.)
What we didn’t optimize was VRAM use, and this is why blurry textures is a common problem with the first beta. X-Plane 12 uses Vulkan/Metal as its renderer, always, so it uses our Vulkan/Metal memory management strategy: we dynamically bring the resolution of textures down to fit within your available VRAM, with some guessing as to which textures are most important.
The texture slider in the UI sets the maximum texture resolution X-Plane will attempt – if you have a card without a lot of VRAM, setting this lower can help avoid “thrash” as X-Plane tries to fit 4 GB of textures into 2 GB of VRAM. But X-Plane will further lower res until it fits – X-Plane will not use system memory as backup texture memory, nor will it slow the framerate and stutter by shuffling textures between vRAM and system memory on the fly.
I’m afraid I don’t have any useful information about how much VRAM will get you a better experience – we’re going to do an optimization pass and see what we can tighten up.
I suspect the big driver of VRAM is memory used for effects – X-Plane 12 has HDR always on, but also has extra VRAM reserved for screen space reflections, 3-d water, dynamic weather effects, clouds, etc.
One thing that can help (and I know no one wants to hear this) is to run at a lower resolution. The sim has to internally use VRAM proportional to the size of the winddow or monitor res you fly at. Jumping from 1080p to 4K doubles the resolution in each dimension (making each pixel half as big) but uses 4x the VRAM for surfaces. Full screen anti-aliasing increases VRAM by its factor (4x MSAA = 4x VRAM) for some of those textures, so it’s more efficient than higher res.
What’s All This Magenta
X-Plane renders magenta when it hits a numeric error (a NaN value) inside the rendering engine. Right now there are multiple causes of NaNs – it’s not all one bug because magenta is a symptom, not a cause. A few we know about:
We believe there’s some kind of problem specific to the GeForce 900 series. Sidney bought one on eBay so we can debug this.
I’ve seen NaNs caused by the traffic debugging lines for ATC – I suspect that particular shader has a bug.
We can sometimes get NaNs from the past frame – they get “reflected” by SSR and propagate from one part of the frame to the other.
There’s no easy answer here – each bug has to be squashed one by one. These are high priority bugs and we’re working on them now – hopefully each fix will make things a bit better, but don’t be surprised if some users see less magenta in the next beta and others do not.
Fuzzy Scuzzy Rendering
FSR stands for FidelityFX™ Super Resolution. FSR is AMD’s free open source up-scaling technology. The idea of up-scalers is:
Lots of people have 4K monitors.
Not as many people have GPUs that can run games and simulators at 4K – they’re expensive.
Upscaling a 2K image with a little bit of smarts uses a little bit of GPU and looks a lot better than just running the monitor at low resolution.
When you move the FSR slider to the left, X-Plane renders its 3-d image at a lower resolution and then upscales it to the monitor. This saves GPU time and VRAM at a cost of image quality. The image should look better than running at low resolution but not as good as running at high resolution.
Should you use FSR? I would only recommend using FSR if you want to/need to run at 4K and your GPU is struggling. Support has had a number of complaints about blurry rendering from users with FSR on – FSR is resulting in a less detailed image on purpose just like reducing resolution does. If you are going to use FSR, use full screen anti-aliasing – it helps.
We are still undecided about the future of FSR in the simulator. We added the option of up-scaling based on user requests, and if we didn’t ask for it, we’d probably be asked for it. But we’ve also had lots of “I set this slider low and now everything looks terrible.”
(Why don’t we use FSR2 or DLSS? Both of these upscalers require motion vectors as inputs from the rendering engine, something X-Plane does not provide. We may support them in the future, but adding motion vector generation is not trivial.)
Beta 3 Coming Soon
Over the past weekend part of the team met in person to do planning and roadmapping; beta 3 should be available shortly, with some of the bug fixes we’ve already coded. X-Plane 12 for Steam is in review — hopefully it will be available Real Soon Now™.
Our next milestone is the Early Access release of X-Plane 12. As we get closer to this public stage, we wanted to share a quick look into where we are in the development process, what’s being worked on currently, and what else needs to be completed before we release.
During Early Access:
Everyone will be able to purchase X-Plane 12.
X-Plane 12 will be available for purchase as a digital key for $59.99, just like always.
During Early Access, X-Plane 12 digital keys will include access to X-Plane 11 as well.
DVD copies of X-Plane 12 will be available later on, once X-Plane 12 is out of Early Access. These will be available from X-Plane.com in North America and by Aerosoft in Europe.
Early Access will also be available on Steam.
Flight Model
In Final Testing
Austin is working on a blog post now to provide an overview of the changes that have been made for X-Plane 12.
World Features/Global Scenery
Completed
Rain/Snow shaders for airports and global scenery
In Progress
Complete data import/finish scenery tile generation.
We import piles and piles of data and then use it to create our global scenery. Due to the sheer size of this data, the import process alone takes several days .
Improve performance of 3D trees.
Tune coastlines/beaches embedded new scenery tiles.
Boat/Seaplane 3D wake drawing.
Complete ortho photo compatibility.
We know that users have all sorts of ortho photo packs that they are using currently in X-Plane 11. Our goal is to maintain compatibility as much as possible.
To-Do
Finish implementing geographically-aware water colors.
Airport Features
Complete
Fully animated jetways.
Modular tower building kit for Gateway artists.
New ground vehicles with updated driving logic.
FMOD sounds for ground vehicles.
Dozens of new static aircraft + new airline/airport based logic for livery selection.
In Progress
New (all electric ⚡️) passenger buses
Fleet
Completed
SR22
R22 (skids/mariner versions)
Citation X
RV-10
PA-18
In Progress
A330
While this aircraft is ready for an initial release, there are some additional features that we are still working on – specifically a custom Airbus FMS.
F-14
To-Do: Finish liveries and finalize autopilot behavior/cockpit details.
Weather Engine
Largely complete – including fresh data sources for real weather, new logic, new rain/snow accumulation/windshield effects, new volumetric 3D clouds, etc.
To-Do
Fix a handful of bugs in the volumetric cloud system.
Ensure weather continuity between networked simulators.
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.
