****EDIT: There’s apparently an issue for people running the Vive and WMR where they’re seeing reduced resolution. We’re looking into it and will post an update as soon as possible.
****EDIT2: We’ve found the issue affecting Vive and WMR. We’re testing a fix internally and will release an update hopefully in the next 24 hours. Please do not submit any more bug reports about Vive/WMR resolution.
11.20 VR4 is Live on the servers. Aside from the usability fixes that Ben already mentioned, the major ‘feature’ in VR4 is…Oculus users will no longer need SteamVR. If you downloaded it just for X-Plane, go ahead and remove it. It will no longer be necessary.
As we said we would do from the very beginning, we investigated the relative performance of X-Plane through the native Oculus SDK versus SteamVR and what we found, through data collection, is that the overall experience for Oculus users was better by going through the Oculus SDK directly. I know many of you are thinking “Duh! I told you that a month ago ya big dummy!” and yes…yes you did. Fortunately/Unfortunately, we try not to make engineering decisions based on gut feelings and anecdotal evidence when we have a way to collect actual numbers. We wanted to tackle a majority of the usability issues affecting everyone before we looked into performance.
In the various A/B tests that we performed, we found that going to the Oculus SDK directly got us about 25% improvement in frame rate. This does not necessarily indicate that there’s anything wrong with SteamVR itself. There are several factors influencing the performance in VR. First, Oculus has their “home”, that little bachelor pad where you hang out while waiting for games to load. SteamVR has their “home” as well. When you use SteamVR, BOTH are running on your machine. Those houses are not free and X-Plane is already CPU bottlenecked so anything consuming CPU resources is going to directly affect performance. (I noticed an Autodesk updater in my task manager that was stealing 5% of my CPU consistently. That too was decreasing my performance….every bit matters!). Going directly to the Oculus SDK removes the SteamVR house from the equation.
Sure, getting 25% improvement is a huge win, but that’s NOT the biggest win. The biggest win, in my opinion, is that Asynchronous Space Warp (ASW) works MUCH better even at very low frames rates down to about 22.5fps. It appears as though the timing of the frames is critical for ASW to work properly. Being at 22.5, 30, 45, 90fps feels smooth! Being in between those frame timings seems to make ASW lose its mind creating an annoying judder; the opposite of what ASW is supposed to be doing for us. Oculus seems to be V-Syncing us to hit those intervals, allowing their algorithms to make reliable timing decisions and predictions. It’s my suspicion that SteamVR was just not hitting those intervals, causing ASW to flip out.
TLDR; Performance for Oculus will be on par with what Vive users have been seeing all along. The smoothness of the rendering seems consistent even down to 22.5fps. If you’re a Vive user, you will still, of course, need SteamVR as that IS your native SDK. If you’re a WMR user, you will still need SteamVR. I have not seen any reprojection issues with WMR like we have with Oculus. Supposedly the upcoming versions of SteamVR have some performance improvements coming for WMR users as well so we’ll be sticking with SteamVR for all headsets other than Oculus. That can always change in the future…based on data.
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.
Posted in News
by Ben Supnik
We’ve seen a few critical bug reports over the weekend, so:
- We’re going to hold off on the Steam release of VR2.
- VR3 should be out really soon – basically as soon as we can get these critical bugs fixed. We’ll put that on Steam.
- VR2 won’t launch on some versions of Linux due to a plugin DLL problem. We don’t have a fix for that; we have to fix the sim.
- The HOTAS Warthog causes the sim to crash if it’s plugged in. We’re fixing it.
- If you have any other hardware that either won’t calibrate or crashes the sim, please do file a bug! Commenting on the blog does not count! If you’ve commented on the blog, even if LR staff has replied, file a bug. Only bugs go somewhere that get tracked.
- We’ve seen reports of plugins crashing that did not crash in VR1. If a plugin is now crashing in VR2 that didn’t crash in VR1, please report it! It’s useful to know whether the plugin crashes in VR2 even if VR is not being used.
Anyway, we’ll try to stabilize this stuff in VR3, then move on to more investigations WRT Oculus performance, and fixing other VR bugs like xPads floating in the air.
Posted in News
by Ben Supnik
Set your updaters to grab the latest Beta and you’ll find yourselves with VR2 Preview Release. We put a lot of time into this release in an attempt to tackle as many of the usability issues of the VR1 release as we could. (Steam users — VR2 should be available as a public beta on Steam sometime this weekend, as soon as Philipp gets it uploaded.)
Important Note: If you are trying to run VR2 on an X-Plane install that was previously running FlyInside’s plugin, you might experience a crash on startup. We suggest installing VR2 to a fresh copy of X-Plane on your hard drive. If you can’t do that, you might need to uninstall FlyInside and reset your X-Plane preferences.
EDIT: There is currently a known issue with the Thrustmaster HOTAS causing the sim to crash. We’re looking into this and once it’s fixed, we will release VR3 which will address this issue and possibly others should they arise in the next 48 hours or so. For now, if you want to use VR2, you’ll need to do so without your HOTAS.
I’ll enumerate the major headliner features/improvements and talk about them individually, but first, let me be clear what is NOT in this release. This release will NOT dramatically improve the performance or reduce judder for any VR platforms. The goal of VR2 is to address usability for all users. Read More
After an intense year of development and a few demos of the technology at various Flight Simulator conferences, it’s finally time to let you all in on a preview of X-Plane 11 with VR support built-in! I will admit that I personally thought this was another technologic fad that was going to fade without ever gaining traction but I’m happy to say that I think I was wrong. Once you try a VR headset, you’ll never want to fly without one again. For the first time EVER, you can fly precisely and accurately by looking around and interacting with the cockpit without being anchored to a narrow field of view and small clickable hotspots viewed from unnatural angles. VR lets you have unlimited freedoms to move your head and body around naturally. You also get a sense of scale for the first time. Objects and manipulators are the right sizes and distances…just stand next to the tires or engines on one of the airliners and you’ll understand what I mean by scale. Read More
X-Plane 11.11 is now final – you’ll be notified to auto-update. 11.11 is a small bug fix release that fixes a few key issues that we didn’t find out about in time to get into 11.10. Here’s the release notes.
Our VR private beta program is underway – we’ve been cutting VR private betas in parallel to 11.11 testing; I’ll post more on VR over the next few days.
X-Plane 11.11 is available for testing – to get it, run the X-Plane 11 installer, pick “Update X-Plane” and make sure “Get Betas” is checked. Two big fixes:
- This build should fix crashes for AMD users.
- This build restores functionality for FltPlan.go and a number of other iOS moving map apps that.
Release notes are here.
Posted in News
by Ben Supnik
X-Plane 11.10 went final Thursday night – you’ll be notified to update. Jennifer has a good write-up of the high level features here, or you can read the release notes.
11.10 was a big patch for us – new airports, new autogen, new lego bricks, the G1000, joystick profiles, London landmarks, and significant engine enhancements to both the physics and rendering engines.
We may do an 11.11 patch next week – we have a few bug fixes that didn’t make the RC. Jennifer gets a lot of bug reports over the weekend, so we’ll evaluate Monday.
VR Is Coming!
The rendering engine work in 11.10 gets the sim “VR-ready”, and Chris has been working on the actual VR features of the app in parallel to the 11.10 release.
The next major patch of X-Plane will be 11.20; it will feature native VR support for the Oculus Rift and Vive on Windows, and the beta is coming very soon.
A few betas went by and I didn’t have a chance to write things up. The short version:
- 11.10b8 just went up – release notes here.
- We’re mostly down to small bug fixes – no more big flight model changes.
- The next build will probably be 11.10rc1.
- We’ll get Steam updated in the next few days – Philipp’s been traveling a lot.
There are no remaining major enhancements that have to go into this beta. Here’s how some of the big technology changes played out:
- The new manipulators are in – I’ll write up a separate post tomorrow on those. They went into beta 6 (hence all of the weirdo bugs) and are now fully working.
- All of the new weapons code is in – dataref access to weapons is restored. Jörg has a few crash bugs to nail down with networking and weapons, but that’s it.
- Audio events had to wait – I’ll write that up in a separate post. They’re something we wanted, but realistically we never had time for them in 11.10.
- The last round of performance enhancements for graphics is going to wait for the next release patch.
The bad news is: AMD users aren’t running 11.10’s fastest path due to problems with our current code and drivers. The good news is: the next round of enhancements do work with AMD cards, so we can get back to treating them normally. That code is now looking reasonably stable, but it wasn’t stable early enough to make it into 11.10. I think it will be available in beta this year though.
Finally, there was an open question of how to use glScissors in a plugin with the new UI features (e.g. floating windows, multi-monitor, 150% UI, etc). As of beta 8 this is fully possible; I just need to get the sample code to Tyler to post.
Two flight model notes for aircraft authors – the executive summary of all of these is pretty much “it should just work and you don’t have to do anything.”
Steering Gear Rate Limiting
X-Plane 11.10 has an option to rate limit how fast gear that steer can turn. This is a good thing – in the real plane you just can’t turn that tiller very fast, but if you have a $20 Microsoft Sidewinder from 2002 with the throttle tab broken off (for example) you can twist it to full deflection almost instantly. When this happens, X-Plane turns the wheels instantly, and since they’re not at a 70 degree angle to your movement path, they skid like Ken Block landing a Baron. Once the wheel is in skid it has pretty much no ability to turn the plane and you just skid.
With rate limiting, the wheel will turn a little bit, and be able to put out side force, helping the plane begin to rotate. As this happens, you can turn more and gradually angularly accelerate the aircraft into a turn.
So … rate limiting is good – you should use it! But the compatibility code in beta 7 was pretty broken – it set the minimum rate to 1.0, which is way too slow for a bunch of aircraft.
Beta 8 fixes this – the minimum rate is 0 (meaning no limiting) and this is the default for 11.05 planes.
Here’s the warning: if you saved your aircraft in an earlier beta, you’ve baked in the long gear deflect time – you’ll have to go into Plane-Maker and turn the value back down again.
Just One Turbo-Prop Model
X-Plane 11.10 had two options for free turbine turbo-prop engine models: the “v10” and “v11” models; all 11.05 planes showed “v10” when loaded in Plane-Maker.
We’ve backed this out – there’s just one model, “turbo-prop (free)” in beta 8, and if you picked the v11 model, we’ll mark it back to v10 for you. (You shouldn’t be shipping aircraft saved in a beta anyway, but we check for this in the sim itself too.)
Here’s the back-story: X-Plane models the compressor turbine speed of a free prop turbine like the PT-6 as “N1” and the prop turbine speed as “N2”. Austin has come to regret this decision, as the prop turbine is a lot more like the turbine that drives a bypass fan in a high-bypass jet engine, and the compressor turbine is a lot like the turbine that drives the core in a high-bypass jet engine.
So Austin cut a new version of the engine model with N1 as the prop and N2 as the compressor, exactly backward from 11.05.
The thing is: while the new model matches Austin’s brain, it doesn’t match any aircraft ever made, and swapping N1 and N2 in an add-on is a pretty expensive update. Realistically we’re not going to ever deprecate the old model for the new one in any time frame if this much rework is needed.
So we’re keeping the new model ‘in the lab’ and not releasing it for now, as it doesn’t have significant changes in how it models the engine itself yet. This frees Austin up to improve it on his own schedule and frees us up from having to maintain another point of version compatibility. Since the new model doesn’t have any enhancements (other than renaming N1 to N2 and vice versa) you’re not losing out as an aircraft developer here.