A few quick notes on 12.06-related chaos – it’s been a weekend.
Global Airport Errors
“Don’t rock the boat in a release candidate.” This is the lesson I should know, since I have cut at least 187 of them.
In 12.06rc1, we were missing HEKA (completely) and all of the airports at KLAS; the KLAS problem was due to a missing art asset. One of the multiple confounding factors in this bug is that the global airports don’t put up a “there was a problem with the scenery pack” pop-up message when art is missing. So, being the brainiac I am, I went “oh, that seems dumb, we’ll never know if the pack has problems, I’ll go fix that now”.
For 12.06rc2, I changed the policy so that the global airports would get a pop-up message like any other scenery pack that’s missing art.
As it turns out, the global airports are missing lots of objects – and probably have been for the entire X-Plane 12.0 run.
So coming soon to an installer you: X-Plane 12.06r3, which will be just like r2, but with the pop-up message turned off (just like the rest of the beta has been).
We have a more comprehensive plan to address these art asset issues for 12.07 – I’ll comment on why it’s important that missing scenery assets be errors in another post.
As a side note, it appears the most RCs we’ve had is X-Plane 9.40, which got up to release candidate 16 and took at least six weeks.
NVidia Users: No Zink For You (for a little bit)
In X-Plane 12.06r2 we have disabled Zink for NVidia users. We did this because there is an NVidia driver bug that interacts with Zink that will cause the sim to crash.
NVidia found the bug, is working on a fix, and they are quite responsive in pushing driver fixes. As soon as the fix is in non-beta drivers, we will change this from a “zink is banned” to a “you must have at least driver version x.y to run zink” message.
If you really really really want to run Zink on your NVidia card, you can still can, using these two steps:
Raise your right hand and repeat after me: I, _____, solemnly swear that I want to crash my copy of X-Plane by running Zink with NVidia drivers before the driver fix is available. Let it be known to all of the X-Plane community that I do this of my own volition. I enjoy having my flight end abruptly with a crash report dialog box on short final, and I will not complain about this on r/flightsim.
Run the sim with --zink
AMD users: you are not affected by this, so Zink is still available. Enjoy this rare chance to make fun of your green team compatriots.
We Put the ‘No’ In NOAA
Over the weekend the real weather servers went down. While we usually blame NOAA for this kind of thing, this one was super embarrassing: the server ran out of disk space (and the disk space monitor didn’t notify our ops team). The ultimate cause, I suspect, was that it was labor day weekend in the US, e.g. “a really good weekend for infrastructure issues.”
This isn’t the first real weather outage we’ve had this year, and for this reason we have a replacement weather server in development. The replacement will be able to serve the least old weather correctly when NOAA has a maintenance outage (instead of just 404ing everyone) and will hopefully clean its cache out correctly.
(The caching problem is slightly harder than it sounds: we do want to retain some old real weather files for test cases and bug reproduction. But we need to purge most of it to keep the server from filling up.)
What’s Next
If 12.06 rc3 is final, we’ll let it sit a little bit and then start private testing of X-Plane 12.07. The X-Plane 1.206 beta has taken quite a bit longer than we wanted, so 12.07 is intentionally a smaller release – about half the size in terms of code change. That’s still a lot of new stuff (and a topic for yet another separate blog post).
If 12.06rc3 is not final, I will set myself on fire.
X-Plane 12.06 beta 4 is out – we pushed for a second beta this week because I’ll be out of the office next week and the installer-making machine lives in my basement, so beta five will hopefully be in about ten days. Here’s some release notes.
The team has fixed a bunch of big bugs this week, including water flashing, clicking problems with mouse-flies and a bunch of crash bugs.
The Crash Reporter…Crashed?!?
XPD-14312 was a meta-bug: the bug was that on Mac, when the sim crashed, it would hang instead of showing the auto-crash-reporting box. I’d like to use this bug as an excuse for a public service announcement:
Please always auto-report your crashes.
Our crash reporting system automatically de-duplicates crash reports but also counts the number of crashes and can tell us the number of unique users affected; we count on repeated reporting of the same crash to get a picture of the most severe crash bugs affecting the entire community. By always reporting auto-reporting the crash, you’re up-voting the importance of fixing the crash and giving us valuable insights into what’s hurting our users the most.
Do I Need to Also File A Bug?
The short answer is: no. If you auto-report a crash you do not need to file a bug.
Filing a bug can be useful if you have exact reliable steps to reproduce the bug. In this case, please file the bug, include the clear steps to reproduce, and include a Log.txt from after the crash was auto-reported. These crash logs will have a “crash UUID” at the end that lets us locate your crash inside our system.
Please do not file a bug for a crash if you do not know how to reproduce it. “I was flying and the sim just crashed, I don’t know why” provides us with no useful clues; everything we can act on is already in the auto-crash report.
What’s Next
We’re trying to wrap 12.06 up; the rest of the beta will focus on a few more rendering bugs, weather bugs, and VR bugs. While we are not going to do a massive real weather overhaul, I do have to fix the bug where it rains for no reason.
X-Plane 12.06 beta 1 is here! And it contains a lot of changes. Here’s a few of the bigger things we changed, and a few notes about the beta process.
Clouds and Weather
Since X-Plane 12.0 shipped, we’ve been working on the clouds and the weather system to improve performance, accuracy and quality. 12.06 ships the first two steps in this multi-step process:
The cloud shaders are now faster and have fewer artifacts. Daniel rewrote the way clouds are marched, fixing zebra stripes and generally making things less pixelated and ugly.
The cloud shaders also contain a dedicated path for cirrus clouds that should look better than what we had in 12.0 (“really thin stratus clouds up high”).
Alex and I rebuilt the noise functions that build each weather type to get better looking clouds of all types.
While there are a few real weather fixes included, we have not tried to comprehensively update real weather; my thinking was that without proper rendering, it would be impossible to tell if real weather was actually getting better.
Coming soon: “Minecraft clouds” (e.g. square cubic clouds, especially with real weather) should be fixed in beta 2, so enjoy them while they last. Thick prism-shaped cirrus clouds should also be fixed, and we’ll be tuning up the presets and METAR parsing.
The future: we are looking at putting a 2-d “cloud shell” behind the 3-d clouds to handle orbital view and make the planet look less silly, and we’ll be going over real weather with a fine tooth comb.
Lighting
X-Plane 12.06 fixes some constants for sky colors but is not a lighting update. We have a bunch of lighting fixes internally, but the plan is to measure twice and cut once, e.g. make one patch to update lighting once we have all of the changes.
Improving dark cockpits is high on our todo list, but we also don’t want to tweak the light levels in the cockpit over and over and over, thrashing third party developers each time we do it.
My expectation is that when we recalibrate cockpit lighting, minor aircraft updates will be needed, but third parties who have chosen to “fix” cockpit brightness themselves (by adding extra light or hacking materials) may have to undo their hacks. I’ll try to provide clear guidance and early builds when we get to this point, but lighting is still “in development”.
Rendering and VRAM
The biggest change to X-Plane 12.06 is not one you can see: we’ve converted the main rendering pipeline from 12.0 (which was hand coded) into a rendering node graph.
Rendering graphs are all the rage today; if you’re curious about this you can look at something like AMD’s Render Pipeline Shaders. But here’s the why behind this change:
The render graph allows us to double-book VRAM used to render the main frame. X-Plane 12 has a lot more stages and processing in its pipeline than X-Plane 11, and that was consuming VRAM.
In 12.06 we treat VRAM more like an AirBnB and less like a second home – at different times in the frame different parts of the pipeline are using the same chunk of VRAM, which means we need less VRAM in total for effects. This change wasn’t possible in X-Plane 11 – you can’t double-book VRAM with OpenGL.
But it also would have been too tedious to hand code aliasing – the rendering node graph automates most of this and prevents bugs.
Coming soon: we have a performance optimization for beta 2 that should help CPU-limited users.
The future: in the future the rendering node graph will also let us render different parts of the frame using different CPU cores, for better CPU utilization and higher FPS for CPU-bound users. We still have a lot of work to do on this front, but once again the rendering node graph makes it possible.
ATC and AI Aircraft
12.06 has a lot of ATC improvements – months of Jim’s work went out in beta 1. I’ll try to get Jim to write up a detailed blog post on the details.
One big improvement to ATC: Austin fixed a lot of problems with the AI pilot. This affects ATC because the AI aircraft fly more reliably and are less likely to crash and bring airport operations to a halt. We’re expecting stability improvements because numeric instability from AI aircraft crashing into mountains would sometimes crash the entire simulator.
The future: Jim has more ATC fixes coming and is working on SID/STAR support.
What Comes Next In the Development Pipeline
X-Plane development works as a pipeline: as I type this…
12.05 is shipping
12.06b1 is in public beta
12.06b2 is being internally tested before going public
12.06b3 is in development – about half of the beta 3 bugs are fixed and we’re working on the rest.
12.07 development is almost finished – a mix of development and testing are going on right now.
We’re working on features for 12.08 and beyond.
Third parties: I believe all of the known third party compatibility bugs are scheduled to be fixed in beta 3, and most of them are fixed already. But these fixes missed the cutoff to get into beta 2, which was a few days ago. We’re hoping to get beta 3 out early next week.
We try to not hold up a beta for fixes that are almost ready – if we did the betas would never ship because there’s always one more fix that’s almost ready.
The future: Pawel’s been working quite a bit on the networking stack, and his first changes will ship in 12.07, primarily targeting pro-level customers. We also have more graphics changes coming, and some of Austin’s flight model improvement are in test right now.
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.
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™.
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.
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.
