X-Plane 11.20b5 came out this week – notes here. Beta 5 fixed the rest of our open rendering engine/material bugs, including artifacts on orthophotos. If you are a scenery or aircraft developer, please check your aircraft or scenery against 11.20 beta 5 and make sure there are no rendering changes compared to 11.10. If it looks different than 11.10 in a bad way, we don’t know about it and it’s not going to be fixed if you don’t say something.
Over the last year we’ve been working quite a bit internally to automate testing. We still do a lot of hand-testing (that is, Jennifer flies the sim and then tells us we’re bozos) but we also have extensive infrastructure to script the sim. So we’re looking to automate the process of checking third party scenery for rendering artifacts, so we can catch more rendering bugs more often.
I’ll post once 11.20 is final about how to get your custom scenery into our test. My hope is that with automation, we can catch bugs faster and you (the third party author) can have your add-on tested without having to do the work yourself.
I’m OOTO next week but if things go well, we’ll have a release candidate when I get back.
We’ve been working on 11.20 beta 4 for a while now – the goal for beta 4 is to fix all of the SDK/authoring bugs and have docs for the new VR file formats. We’re making good progress; beta 4 should be this week, barring an unforeseen bugtastrophy. (Linux users: perf should be fixed with beta 4.)
We received a number of bug reports that beta 3 was showing large numbers of _vrconfig errors with third party aircraft. So this seems like a good time to re-iterate our policy on file format stability and betas.
Don’t ever ship an add-on that uses an undocumented file format. You can’t guess what the fine print is from example aircraft.
File formats are subject to change during beta, and are not stable until we go final. Don’t ship your add-ons against beta file formats.
In our case, the _vrconfig.txt file format changed in beta 3 and will change again in beta 4; as Chris wrote docs, he found issues that he is fixing.
Our priority during beta is not stability of your add-on, it is getting the file format right, so we’re not stuck with a buggy file format for the rest of time.
Once we go final, we’ll put compatibility code in to support the final version shipped in X-Plane when needed.
Similar logic applies to the SDK – it’s fantastic that people are using the latest SDK to test their plugins in VR, but don’t hit the “ship it” button until we’re final – it is always possible that the SDK will change in a way that breaks compatibility during the beta.
X-Plane 11 has had several fantastic updates to the library of lego-brick airport objects that ship with X-Plane. We’ve had new European-style objects, elements for small airports, and the terminal and jetway kits let you build really great looking airports that fit the exact shape of the real-world airport you are modeling.
In that context, I’m pleased to show you a sneak preview of the next set of lego-brick objects for gateway airport authors.
You can download a preview if the new lego bricks here.
Release notes detail the bug fixes here. We have another set of bug fixes that will go into beta 4 next week.
We’ve received a number of bug reports from plugin developers trying to use the new plugin APIs. We’ll have another beta next week to address the rest of the open issues, including the ability to (finally) use widget-based UI in VR.
Beta 3 fixes the MFD brightness going crazy in the G1000 C172, and fixes shadow casting on transparent-alpha-textured objects, but we still have an open bug with panel brightness in a Carenado aircraft that looks like a low level rendering bug. 11.20 has a lot of change to the rendering engine to support VR, performance and our migration to Vulkan and Metal, so authors: please be on the lookout for changes to how your models render compared to X-Plane 11.11.
If beta 3 isn’t found to be a smoldering wreckage of poorly thought out C++ over the next day, we’ll post a Steam version of the beta.
It’s like beta 1, but without the missing art asset. 🙂
We’re working on beta 3 now, which will have some fixes for rendering bugs. A few notes:
This is not going to be a typical eight-week beta. Please go check your add-ons this week.
The biggest area of code change for VR that affected other parts of X-Plane was the rendering engine. I’ve fixed 3 rendering bugs where I broke something while restructuring the renderer for VR, and none were surprising. Please check your aircraft or scenery pack for visual defects and let us know!
X-Plane 11.20 VR preview 6 is out, and if preview’s 2 and 4 are any predictor, it’s going to be a dreadful disaster, as all of the even number previews have been so far.
But maybe not! Maybe we can break the curse – after all, Star Trek did it with Nemesis. Anyway, VR6 is available for public beta. Steam users – we’ll post it on Steam tomorrow if we haven’t found a major problem, otherwise we’ll go right to 7.
Asynchronous Space Warp (ASW) works for the Oculus Rift.
No more white instruments.
No more crashes loading some third party aircraft.
The xPad won’t follow you around as you teleport around the tarmac.
Depending on how things go, this might be the last VR preview! ASW and xPad teleportation were the last two big VR specific issues; if things go well, we’ll produce a general 11.20 beta for everyone with the other features mixed in. I’ll post about that next week if VR6 doesn’t have to be recalled for insubordination.
Fellow nerds^H^H^H^Htrekkies^H^H^H^H^Hnerds are aware of the even-odd phenomenon – for nine films, every other Star Trek movie was pretty bad, then the next one would be okay. VR previews are now like that, with VR2 and VR4 being fatally broken. We’re planning to just skip 6 entirely.
Anyway, I broke VR4 – my code to put a loading screen in the Oculus Rift had a side effect of killing the render resolution on the HTC Vive and WMR-based headsets. Since I only have the Rift (Chris has one of everything) I never saw the bug; since I thought my change wouldn’t affect anything outside the Rift, Chris didn’t re-try the Vive.
So, VR5 is now up – this should restore the Vive/WMR headsets to the performance of VR3.
We can confirm that ASW is not working in VR4 or VR5 – we’re looking at this now, but for VR4 and VR5 you’ll see ATW but not ASW, regardless of Oculus debug settings.
(Edit: the first version of this post confirmed no ASW in VR5. ASW is off in both VR4 and VR5 because the native rift SDK is not permitting ASW for X-Plane. A number of commenters were concerned that they would lose ASW by going from VR4 to VR5. You will not! ASW is already off in VR4; if you like VR4’s performance, you clearly don’t miss ASW.)
(Edit 2: We have a very promising lead on the ASW issue for Oculus. We have it working again here but I want to do more testing before I declare victory. We do not need any more information. Nothing you can do on your end will fix this. If you think you’re fixing it by “jiggling the handle” you’re probably just falling into placebo effect. If everything goes well we will have an update to fix this over the next day or so).
We’re starting internal and private testing of VR preview 4 – if it goes well, we’ll release it early next week. A few notes on usability:
Have Your Mouse Cake and Eat It
We got a metric ton of “bug reports” that users couldn’t click “Disable VR” when using the 3-d mouse. I put bug reports in air quotes because disabling click zones on the main monitor when using the 3-d mouse was totally intentional! (In other words, I broke that button on purpose.) My thinking was that you might click on “Disable VR” by accident while in the headset because you don’t know what the 2-d mouse is hovering over while clicking.
In VR4, we have a solution to the problem of whether the 2-d or 3-d mouse is the “intended” cursor when a click happens: we read the headset’s “on the user’s head” sensor and disable the 3-d mouse (temporarily) when you take the headset off. So you can be clicking in 3-d, take off the headset and immediately click “Disable VR” and we figure it out. This feature is great for developers who need quick access to 2-d debug tools like the texture browser or DataRef editor. Read More
It’s basically VR2 with the crashes and chaos fixed. The plugin system in VR2 had a bug that seems to have caused plugins to go completely crazy and cause weird rendering settings changes. This should be fixed in VR3, but check your settings to make sure they match what you expect.
VR3 also fixes the sim not starting on older Linux installations.
EDIT: VR3 is now available as a Steam public beta too.