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.
Default Fleet Updates
Rain/Snow on Runways
Prop Physics Updates
Anti-Aliasing and FSR
Recut Default DSFs
Third Party APIs
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.
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.
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.
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.
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.
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.
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?
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.
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.
Every week for the last ten weeks I’ve thought “I should really write a dev blog post” and then…not done that. This isn’t because all is quiet on the Western front – on the contrary, everyone on the team has been really, really busy, and the dev blog is never the loudest thing shouting for attention. But now we have a new RC available, so here we are.
Mi Memory Es Tu Memory
11.53 fixes one bug, and it’s a rare bug, but it’s “exciting” when it happens. It turns out that if a Lua plugin requests a really huge amount of memory, instead of saying “no,” X-Plane gives the Lua program someone else’s memory. This is not good! If the bank gave you someone else’s money, that’d be a bad bookkeeping error. This bug is too, and the consequences of the bug are typically “really insane stuff happens later,” which is hard to sort out. The plugin that crashes may not be the plugin that requested the memory.
X-Plane 11.53 fixes this – large allocations that cannot be fulfilled are denied, which should cause the Lua plugin to halt the affected script without destabilizing the system.
Script authors, if you’re wondering “now can I allocate a lot of memory in my Lua script,” the short answer is “no.” The longer answer is: when your Lua plugin uses a new version of LuaJIT that can use 64-bit addressing, this limitation will go away via a new plugin, without a change to X-Plane. Since the limitation is in LuaJIT, it’s out of our hands.
G2 Controller Support
Since we were doing a bug fix release, we have included support for the HP Reverb G2. For reasons I don’t fully understand, controller support didn’t “just work” in 11.52, so we had to create a new profile.
G2 users should be able to use their controllers with X-Plane 11.53. However you should also read our KB article for any additional issues with controllers, especially with misalignment. This version also includes a CLI option to adjust this if needed.
Tyler Has Left the Building
After almost seven years, Tyler has joined the ranks of Laminar Research alumnae. You may know him from such hits as:
The X-Plane 11 User Interface
X-Plane Mobile’s global scenery
X-Plane Mobile’s mass multiplayer
He will be missed! It took several weeks just to figure out all the things he maintains.
We Need More Jims
A few weeks ago, we posted a developer opening – I am pleased to announce Jim Keir as the newest member of the X-Plane development team. Jim is already fixing our screwed up code contributing bug fixes and learning the insides and outs of X-Plane’s almost 1 million lines of code. Jim brings our count of Jims up to two, which is still less of a namespace collision than our three Dan*s.
Multicore and Plugins
Most of what we are working on is still in the lab and hasn’t escaped yet. A few weeks ago we did have a discussion with developers in our third party developer Slack channel about multi-core and plugins.
The short story is this: in X-Plane 11.50, Sidney added a widget to the plugin admin window that shows how much main thread time they’re consuming, which in turn reveals how much each add-on is impacting FPS.
Plugin authors responded! Lots of plugins moved their CPU processing time to a worker thread. This is mostly great – other cores tend to be underutilized on high-end machines so this gets us more FPS.
Here’s the concern: a lot of plugins are doing this, and they are each moving work to other cores in their own private way. There is no coordination between plugins, and one day we are going to wake up and X-Plane will stutter because plugins were (just for a frame) using all of the cores and leaving too few for X-Plane itself.
We are looking at a mechanism for plugins to use the background processing system that X-Plane has built in. The win would be that X-Plane could play traffic cop between plugins and the sim itself, and prevent background plugin loading from causing frame stutters.
I will write up a Request For Comments (RFC) as a future blog post, so that a wider audience can comment on this.
Thanks to the users who filed bugs (especially Bill), we now understand the issues with the HP Reverb G2, but the fix is not in 11.51r1. The fix needs more testing than will fit into this patch. If you have an HP Reverb G2 and haven’t filed a bug, please do, so we can find you to send you a possible test build. In the meantime, we won’t hold up 11.51 and the new Gateway airports; rather we can work on the G2 in parallel.
When we released X-Plane 11.51 beta 2 last week, we included up-to-date Aftermath support. Aftermath is an NVidia driver feature that catches detailed information when the GPU crashes (e.g. “device loss” crashes).
Full Aftermath debugging slows X-Plane down. The sim is still flyable, but you might go from 50 to 35 fps, for example. It’s noticeable, so we didn’t just turn Aftermath on for all eligible users. It’s too big of a perf hit to just leave it on all the time.
Unfortunately, while we know from auto-crash reporting that device loss errors are happening, we also know that no one is using Aftermath to capture detailed information that we could use to find and fix the potential problems in X-Plane.
So: if you hit device loss errors while flying with Vulkan on Windows with an NVidia card, please follow these instructions and run with Aftermath for a little bit. If you can drop us a few auto-crash-reports with Aftermath enabled, it could get us the key breakthrough we need to fix device losses.
Tyler also fixed some low level networking bugs. This doesn’t change how multiplayer fundamentally works – if you can’t do a LAN flight across your WAN or you need command line magic to get the right NIC, that’s all still true and really not in the scope of what we’re fixing in 11.51. This whole beta run is targeted bug fixes.
X-Plane 11.51 Beta 2 is now available. (Release notes here.) Here’s a few more details on bug fixes we are working on.
Device Loss Errors on Windows
A device loss error occurs when shaders running on the GPU crash. In the old days this might hang or blue screen your computer, but fortunately we live in the age of enlightenment – the GPU catches the error, stops running X-Plane’s shaders and leaves a note for the Vulkan driver to tell X-Plane “hey, you your code died.”
NVidia’s “Aftermath” is a diagnostic tool that can tell us why our shaders crashed on the GPU. When we tried to use it in the past it crashed, but NVidia has since updated their drivers, so we are trying again.
Aftermath can collect lightweight or heavy crash info; the lightweight crash info doesn’t hurt FPS, so it is now always on. Heavy crash info significantly lowers FPS, and must be turned on by the command line –aftermath flag.
So…we are looking for a few brave volunteers. If you:
Have an NVidia card with driver 457.09 on Windows 10 and
Sometimes see device loss errors during your flights and
Can live with some FPS loss for a little bit to fix these errors
Please run with
and auto-report any crashes that come up. If you get a device loss error with Aftermath running, the automatic crash report will contain all of the info we need.
Device Lost Errors on OS X
Device loss errors can happen on OS X in Metal, too – the mechanics are the same as Vulkan. We are aware of one AMD driver bug that caused them which we have worked around in 11.51b1. If you still see device loss errors in 11.51 betas, please file a bug, as we don’t have automatic reporting for these.
HP Reverb G2
We are looking into controller problems with the HP Reverb G2. In X-Plane 11.51b2, the grip trigger should start working again, but the default configuration will still be weird.
The problem appears to be that SteamVR identifies the first-gen and G2 WMR controllers the same way; we are still looking into this. If you have these controllers and haven’t yet sent us a bug report, please try them with 11.51b2 then send us your log with the additional diagnostics.
Clicking Settings Crashes on Windows
A few users have seen crashes when opening the settings menu on Windows, before ever turning on Vulkan. As best we can tell, the crash happens when we open the settings screen because we have to go inspect the Vulkan driver to see if it is usable, and that code goes off the rails. We have a possible fix for this; our theory is that it happens to users who have various third party “layers” (layers are basically plugins for the Vulkan driver) that have gone off the rails.
We are still fixing bugs in the Gateway airports export; it’s not ready for beta 2, but it should be in the next beta after this one.