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.
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.
