So, here’s how to fake VR in X-Plane:

• For starters, you’ll want to bind a key combination to the “Toggle the 3-d mouse cursor in VR” command. This can be done in Settings -> Keyboard, and will allow you to switch between using the mouse in VR, and in the normal window to exit VR mode. It can by quite hard to get out of VR mode without this shortcut.
• Start X-Plane with the --fake_vr command line argument (see “Using the Command Line Options” if unsure how to do that).
• In the Settings menu, the VR options should now be enabled. When checking the “Enable VR Hardware” checkbox, the left-eye view will be rendered in the X-Plane window.

There are a couple of noteworthy things to keep in mind when using this. Let me start with the good news: this also works on Mac! On to the bad news… this is very much in the category of “nasty hacks”, which means:

• Quite a number of rendering artifacts when faking VR, but it should be good enough for testing out things like user interfaces and the like.
• No support for VR controllers
• …or even for actually moving the fake headset about

The post Faking VR for fun and profit appeared first on X-Plane Developer.

XPLMDataRef vr_dref =XPLMFindDataRef("sim/graphics/VR/enabled");
const bool vr_is_enabled = XPLMGetDatai(vr_dref);
if(vr_is_enabled)
{
    XPLMSetWindowPositioningMode(my_window, xplm_WindowVR, 0);
}

When a window is added to VR space, it will be attached to the user’s head-mounted display (HMD)—as they move their head, the window will move with it. The user can then move the window into a fixed position (relative to the aircraft) by grabbing the window with their controller (or the mouse, in 3-D mouse cursor mode) and dragging it around. This mirrors the way the built-in ATC window works right now.

Limitations of VR windows

There are a few unsolved problems here—most of which are unsolved for both plugin windows and X-Plane’s built-in windows.

You can’t place windows in a specific location in VR

This is, admittedly, possible for X-Plane code, but we don’t use it, nor expose it to the plugin system for one major reason: it’s really hard to reason about the visibility of a window in the 3-D cockpit!

Consider the case of the F-4, which has a small cockpit cluttered with lots of 3-D “stuff.” If you wanted to position a window programmatically within that cockpit, you’ll have to contend with lots of possibilities:

• the window is too large to fit anywhere in the cockpit (how do you choose which part of it will be cut off by the cockpit geometry?)
• the window is too large to fit anywhere but 1 cm in front of the user’s face (how do you weigh the annoyance of this against the problem of having part of the window cut off?)
• the window fits in the cockpit, but will be occluded by 3-D objects (how much occlusion is too much?)

These concerns are not just academic—without taking careful account of the cockpit geometry, it’s very easy to position a window in a way that it’s just not visible at all in some cockpits!

Thus, our current implementation represents the most straightforward solution we can come up with: by attaching to the HMD initially, we guarantee the window will be visible (given some amount of head movement). And, by allowing the user to position the window thereafter, we sidestep concerns about occlusion, intersection with 3-D objects, etc. Users can’t position a window such that they can never see it or interact with it again, and we leave it up to them to decide how much of the window really needs to be visible.

Of course, there are scenarios where you can absolutely reason about the best place for a window—e.g., if you’re shipping an aircraft-specific plugin. This is something we’re looking at supporting in the future, once our own internal format for handling positions gets locked down.

You can’t restore window positions from prefs

This follows straightforwardly from the fact that we don’t support programmatic positioning of windows, but it’s worth noting separately. The unfortunate consequence of this is that if you get 10 windows popped open at sim start, they will all be right in front of your face, and you’ll have to move them before getting to your flight.

Eventually, we’d like to have an API for saving and restoring VR window positions on a per-aircraft basis—that is, your prefs for where a given window is located would be dependent on the aircraft you’re flying. In the C172, your prefs might have the window in the top left of the cockpit, while in the 737, it might be in the copilot’s seat.

You can’t lock the location of a window

On a 2-D monitor, we’re used to “flight overlays” that sit along some fixed edge of the screen and are always visible, waiting for interaction. There’s not a good VR equivalent for this, though—locking UI to, say, a fixed position relative to the HMD is kind of annoying as a user.

You can’t bind a window to a 3-D object

X-Plane’s “xPad” is an example of UI that’s integrated into the VR world. In essence, we have a 2-D window “stuck” to a 3-D tablet object, giving the illusion that you just have an interactive object. This isn’t possible in the current version of the SDK, but it may be someday.

The post VR Support for Plugins is Here! appeared first on X-Plane Developer.

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

The post We Are Now Just Like Star Trek appeared first on X-Plane Developer.

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

The post X-Plane 11.20 VR4 Is Live appeared first on X-Plane Developer.

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.

New Features

3D Mouse is now a thing in X-Plane with VR! This had to be the single most requested feature from VR1 and we heard you loud and clear. Starting in VR2, the 3D mouse is now available. This is really helpful if you prefer not to use your VR controllers or if you are trying to fly a legacy aircraft that does not have good/any VR support. With the mouse, you should be no worse off in VR than you were with flying the plane on a 2D monitor.

The mouse can be enabled or disabled by using the new “VR Settings” tab in the preferences screen, or by binding the toggle-3d-mouse command to a keyboard key, joystick button or even a VR controller button to enable or disable it!

Laser Manipulation support has been added. In VR1, if you wanted to interact with something in the cockpit, you needed to place the tip of the controller on the manipulator such as the throttle and then click and physically push as if your hand was on the real throttle levers. This was and still is the preferred way of interacting with the cockpit elements because you are doing the exact things that a real pilot would be doing. It offers the highest level of immersion.

However, for some of you, this is not always possible because of ‘permanent’ physical limitations in your surroundings. I’m willing to bet, many of you have knocked cups of coffee off of your desks trying to get to that Cessna throttle! To help with this, we have created Laser Manipulation. This allows you to interact with manipulators using the controller from a distance. It’s always available, all you need to do is lightly and partially squeeze the trigger and you’ll see a green laser appear. Now aim that laser at the thing you want to interact with and ‘grab it’ by squeezing the trigger the whole way just like you would as if you could reach it. Once you’ve ‘grabbed’ the manipulator, interact with it intuitively. If it’s a throttle, just push your hand like you would. If it’s a knob, just twist your wrist. If it’s a switch, just flick your wrist. Laser Manipulation essentially just takes traditional manipulation and lets you operate at any distance or angle that is convenient for you.

Yoke Modes/Settings. One common complaint about Yoke interaction is that unlike the rest of the cockpit, the yoke behaved differently. Starting in VR2, there are TWO Yoke modes. The new default is ‘Realistic’ mode. In realistic mode, you interact with the Yoke/Stick the way you would expect. If it’s a Cessna yoke, pull/push it for pitch, or rotate your arm around the center of it to roll. If it’s the cyclic on the S-76 or the stick on the ASK21, just slide your hand forward/back and left/right and the stick will track you perfectly.

The other mode is ‘Ergonomic’ mode, which forces all yokes to behave the same. In Ergonomic mode, your wrist is used to control pitch and roll. The position of your hand means nothing so you can just rest your arm on an armrest and fly comfortably. In addition to the yoke modes, we’ve also added the ability to adjust the sensitivity of the Ergonomic mode so you can adjust it for greater control or responsiveness.

Lastly, you can enable or disable latching of the yoke. By default, when you click on a yoke manipulator, your controller will stay attached to it until you click again so you don’t have to hold down the trigger. If you disable latching, however, the yoke will behave like all other manipulators that end their interaction when you release the trigger. Yoke Modes, sensitivity, and latching options are all set in the new VR Settings tab on the settings screen.

VR Controller Customization is now possible, starting in VR2. Go to the Joystick tab of the settings screen and you should see any VR controllers that are currently powered on. You can configure them just like any joystick and add any X-Plane commands or axis to them.

There are some caveats: there are certain reserved VR axis and commands that must exist SOMEWHERE between your two controllers. Touchpad-X, Touchpad-Y, Trigger, and VR Menu for example. These do not need to be replicated across controllers (though they can be if you’d like) but they must exist on at least one. This allows you to use one controller to do VR specific operations like teleport and manipulator interaction, while you can use your other controller to control the rudder, brakes, weapons etc. You can also configure a free button to run VR commands like resetting your VR view which is incredibly useful to get back in the cockpit facing in the proper direction. You can also enable/disable the 3D mouse cursor or ZOOM.

VR Quick-Zoom has been added as a command that you can bind to your controller. When you press the button, it currently zooms your head in so you can read things in the distance a bit clearer. When you release the button, your zoom resets.

Windows Mixed Reality support has been added! Be sure to check out the VR docs as you’ll need to also install “Windows Mixed Reality for SteamVR” to get it up and running.

In addition to all of these features, a lot of work has been done behind the scenes to improve the stability of the VR system but I must remind you that VR is still a PREVIEW. This is more like an Alpha test than a Beta test which means major pieces are still being added and improved rapidly. We’re listening to your feedback and doing what we can to create an amazingly immersive X-Plane world for you but there are still some rough edges to get cut on so it’s still wise and recommended to run VR2 on a dedicated install of X-Plane.

The one big usability bug we did not get to: the xPad will still float around when you teleport around the runway area. This will be fixed in a future preview or beta.

Oculus Judder – A workaround, at least for now.

We do acknowledge that there is an inherent judder in the Oculus Rift that we do not see with the Vive or WMR. We do plan on investigating whether using SteamVR is impacting Oculus’ performance – it’s next on our todo list. The rearchitecting to be able to run this comparison has been done in VR2 but we don’t have data to make decisions yet.

We do suspect that this judder is made worse by the default use of Oculus’s Asynchronous SpaceWarp (ASW). If you don’t know what that means, I’ll give you a very brief explanation with some hand waving. The VR headsets want new rendered data fed to them 90 times per second. Games that cannot render their scenes at that rate would normally have a continuous perceivable stutter.

To solve this, all major headset drivers have created software algorithms that make predictions based on your head’s orientation (tilt/rotate) to predict what the missing frames would look like. For Oculus, this is called Asynchronous TimeWarp (ATW). Since we tend to rotate our heads faster and more frequently than we reposition our heads, ATW solves a big portion of the errors that would otherwise exist in predicting intermediate frame data, but not ALL.

Next comes ASW. ASW’s job is to solve prediction errors caused by repositioning your head quickly (sliding it forward/back or side to side rapidly). This works well (supposedly) but it has its limitations. ASW works well above 45fps, but below 45fps it tends to create more problems than it solves. These problems are surfacing in a lot of cases as the perceived judder Oculus users are experiencing. It is because of this that we recommend disabling ASW.

As I said before ASW is nice, but not necessary for an enjoyable flight since we tend to not make rapid position movements with our heads…unless you are head-banging to some good rock. There are several ways to disable ASW but this one is pretty straightforward:

After launching X-Plane with VR Enabled, go to C:\Program Files\Oculus\Support\oculus-diagnostics and run OculusDebugTool.exe and set Asynchronous Spaceward to “Disabled”. Resist the urge to touch other settings!

Important Note: This has to be done each time X-Plane is launched as ASW reenables itself by default.

The post X-Plane Desktop VR2 Preview Released! appeared first on X-Plane Developer.

A lot of the discussion has been about how you interact with the virtual world; Chris and I have spent literally hours discussing this since VR1. In this post, I want to share our thinking and what we’re working on for VR2.

We can view VR interaction in terms of four use cases: fully virtual, virtual with touch and hardware, no touch controllers, and HOTAS. Let’s look at them in detail.

Fully Virtual

The case that works best in VR1 is a “fully virtual” work-flow – take two touch controllers and sit in your room and you can operate the entire aircraft. There are some rough edges that we are looking at.

• Lots of users complained that the yoke movement in VR is always a joystick motion (rotation controls pitch and roll), even if the aircraft has a yoke you pull toward you to climb. Chris’s always-a-joystick choice was based on ergonomics: since it’s fully based on angle, you can move your hand to rest on something while flying without changing your pitch. This reduces the fatigue that would come with having to hover your hand over the exact position if you were using the yoke in a realistic way. With that said,  we’re looking at providing both a “realistic” mode (where motion tracks the virtual yoke, matching our other manipulators) and an “ergonomic” mode, where the control is always a joystick and you can fly from any virtual hand position.
• There’s no way to input rudder right now if you don’t own physical pedals. Tyler is working on making the touch controllers configurable as joystick devices. With this, you can map rudder onto your joystick or D-pad, and also use some of those buttons for common functions. (This capability is useful for two-controller use cases; users with one controller and physical hardware will probably want to keep most of the VR controller buttons mapped to VR-specific functions, as some of these cannot be moved to a conventional joystick.)

Controllers and Hardware

We heard about this case in the private beta: users with touch controllers and physical hardware have a problem when the virtual control is located inside the physical control in the real world. This happens if you are flying the Cessna and have a CH Products Yoke, for example.

To solve this, we’re adding the ability to “touch” cockpit elements from a distance via the controller lasers. It’s a little harder to use than grabbing the controls directly (because small wrist motions are amplified by distance) but it lets you get at controls that would otherwise be blocked.

Laser grabbing also turns out to be really handy for airliners – the gear handle is a stretch from the captain’s chair in the 737; now you can grab it by laser.

Laser grabbing should work seamlessly with conventional direct manipulation of controls, so for users who are happy with the direct interaction in the default fleet, there should be no loss here, and no need to revert to a mouse because some of the controls are physically blocked.

Mouse Control to Major Tom

Some users don’t have touch controllers, just an HMD, a mouse and real flight hardware (E.g. a USB yoke or something). For these users, we’re working on 3-d mouse interaction with the sim. I am not sure how capable it will be, but if you used to fly with a monitor, stick, and mouse, now you can fly with an HMD, stick, and mouse; anything you would have done with the mouse before (UI clicking, 3-d cockpit interaction) stays on the mouse.

HOTAS

Some users fly with only physical hardware (E.g. a Warthog or some other HOTAS setup). This is the group of users that Chris and I are, frankly, kind of perplexed by. If you flew X-Plane HOTAS before VR, X-Plane is, right now, just as capable in VR; anything mapped to your USB hardware still works on your USB hardware, and if you have to go pick up a touch controller, you would have had to pick up the mouse anyway.  Once we have mouse support, the mouse can be “the thing you get for UI” instead of the touch controller.

We are looking at HMD-mounted UI selection, e.g. look at the UI and click a button – Rift users may be familiar with this from the “look at this warning message for 2 seconds” notice at startup.

My personal opinion here is: having used half-written mouse code, touch controllers and HMD-aimed selection, personally I thought HMD-aimed selection was not only the worst of the three ways to interact, but it was not in the same league as mouse or controllers in terms of precision. But it does provide a way (not possible right now without VR) to stay HOTAS for the entire use of X-Plane, which could be valuable.

When

I’m not sure how soon we’ll cut VR preview 2 – I wanted to get it done this week, but I think it’s going to be some time next week; we’re working on these issues now, but it’s hard to say when it’s “done” – we might try all of our “really good ideas” and realize they need more work. That’s how user-interface is…you have to try it to know whether the idea works.

The post Interacting With X-Plane in VR appeared first on X-Plane Developer.

A Long Time Ago…

Old-timers like me will remember that when the 3-d cockpit first came out, almost all of the “brains” of it were powered by clicking on the 2-d panel, which was “mapped” to the 3-d cockpit.  X-Plane would find out where your mouse click intersected the 3-d cockpit, find the texture location on that triangle, and map that back to the 2-d panel.

This seemed pretty cool when it came out 15 years ago, but as authors started making more sophisticated 3-d cockpits, it became clear that we needed a way to specify how the mouse worked directly with the 3-d cockpit shape, because the mapping back to the 2-d wouldn’t allow the user to do basic things like dragging a throttle.

Thus in X-Plane 9 we added the first set of manipulators – tags on the 3-d mesh of a cockpit specifying what happens when the user clicks on it. The manipulator could specify a dataref to modify, a command to actuate, and some data about what kind of mouse click operation was happening.

The key words here are mouse click. The original manipulators were designed entirely in terms of a mouse on a 2-d screen; they were designed to be exactly as powerful as a 2-d panel system, which was of coarse also totally mouse-centric. The relationship between the generic instruments and the original manipulators is pretty tight.

Moving to Mechanisms

The good part of the original manipulator system was that it was very flexible – mouse-centric handlers were a low level tool around which authors could do whatever they wanted.

The down-side of this design was that mouse-centric handlers were a low level tool around which authors could do whatever we want. We examined our own default fleet of a dozen or so aircraft and found that no two aircraft’s cockpits operated the same way, and almost all of them had at least some aspect that was hard to use – a poor manipulator choice for the job.

Knobs were, in particular, quite difficult – the original 2-d panel system used click-and-hold over a knob to actuate it, but authors working in 3-d had often used drag actions to do knobs, and the drag actions would respond differently depending on camera angle. We received approximately 8,452,124 bug reports that the knobs in the 747 were hard to use specifically because of this.

So during X-Plane 10, we added some new manipulators to X-Plane, and they had a very different philosophy: the manipulator described what was happening in the simulated aircraft, and X-Plane picked a mouse behavior to make that work. The new manipulators described knobs that turned and switches that either flipped left-right or up-down.  These manipulators reacted to the scroll wheel automatically because X-Plane knows what the knob is and therefore what a reasonable scroll-wheel interaction should be. (By comparison, with the old-style manipulators, the author has to specify what a reasonable scroll-wheel action is.)

Real Interaction Things Before It Was Cool

As it turns out, mechanism-centric manipulators are a lot better for VR than mouse-centric ones. Consider two cases:

• The 2-d axis manipulator (ATTR_manip_drag_xy) specifies what happens when the mouse moves up-down and left-right, relative to the screen. What on earth does that mean in VR? Even if we made something that tracks up-down and left-right relative to the screens of the HMD, the results would be completely weird because the “thing” in the cockpit would not move the way your hand was moving. With a mouse, a mis-match between mouse and aircraft isn’t surprising, but in VR, it’s weird to reach out and touch something and have it behave the wrong way.
• The knob manipulator. It describes a knob that does things when turned clockwise or counter-clockwise.  This is pretty easy to deal with – you click it with your controller and turn your wrist clock-wise or counter-clockwise and it turns.  Because we know what the mechanism is (and not just what the mouse should do) we can make a good decision about how to handle this manipulator in VR.

As it turns out, we ran into this problem of not doing what to do with the mouse, and needing to know what the mechanism was before we even started looking at VR. The exact same problem (“I want to touch the 3-d cockpit as if it was a thing and have it respond in the expected way”) exists in VR and on X-Plane Mobile!

Because X-Plane mobile runs on a touch screen and you have your physical finger on a switch, there are a lot of cases where the switch has to track really well and work the right way.  If the switch goes up and down, you want to flick your finger up to turn the switch on; if it goes left-right you want to flick left and right, and anything else is astonishing.

So X-Plane mobile set us on this path toward mechanism-based manipulators, and VR further drove us in that direction, since both have the same physical, non-mouse environment where a user directly interacts with the 3-d cockpit.

Guidance For Authors

So as an author, what should you do when working on a 3-d cockpit? My answer is: use some of the manipulators, but not others, to model the way things work in 3-d.

Use these manipulators ALWAYS

These manipulators are the best way to create certain physical mechanisms – use them every time this case applies to your aircraft.

ATTR_manip_drag_axis. Use this for a physical mechanism that slides along a linear path, like the throttle handle of a Cessna.

ATTR_manip_drag_rotate. Use this for a physical mechanism that rotates around a fixed point, like the throttle handles of a 737, or a trim wheel.  (Prefer this to the old technique of putting a drag axis along the edge of the throttle handles.)

ATTR_manip_noop. Use this to make a manipulator that blocks the mechanism behind it from being touched, e.g. the safety guard plate over a switch.

ATTR_manip_command. Use this for push buttons that actuate momentarily while a button is held down, like a button to motor a starter that you push in and hold down.

ATTR_manip_command_knob, ATTR_manip_command_switch_up_down, ATTR_manip_command_switch_left_right. Use these for knobs and switches with 3 or more positions that rotate or move. Pick the right manipulator for the mechanism!

ATTR_manip_axis_knob, ATTR_manip_axis_switch_up_down, ATTR_manip_axis_switch_left_right. These provide an alternative to the above manipulators when you must use a dataref. We recommend commands over datarefs any time you have a choice; the command system provides better interoperability between custom plugins, custom aircraft, and custom hardware.

ATTR_manip_command_switch_left_right2, ATTR_manip_command_switch_up_down2, ATTR_manip_command_knob2. Use these for knobs and switches with exactly two positions. You can use these to get a simple click-to-toggle with the mouse (quicker and easier for mouse users) while getting real 3-d movement in VR.

Use These Manipulators Sometimes

These manipulators are not perfect fits with physical motions and may require tweaking for VR, but they’re the best options we have now for certain problems. Try to use something from the always list instead if you can. Do not use these manipulators if the mechanism you are simulating matches something from the list above.

ATTR_manip_drag_xy. This is the only 2-axis drag we have, and is the best choice for eye-ball vents and the yoke. The yoke is special-cased in VR and should be based off of a 2-d xy manipulator. We are looking into more powerful multi-dimensional manipulation in VR, but this work won’t be complete for 10.20.

ATTR_manip_command_axis. This manipulator runs a command once based on moving a lever down or up. You should probably use a drag axis or command up-down switch, but there may be some odd mechanisms in aircraft where this manipulator is a good fit. It should not be your first-choice go-to manipulator.

ATTR_manip_push, ATTR_manip_radio, ATTR_manip_toggle. These manipulators can serve as alternatives for push-button style controls when you absolutely have to write to a dataref and not use a command.  WARNING: Do not ever use these manipulators for things that move, e.g. don’t use these for banana switches, spinning knobs, or things like that.

Do not use these manipulators

These manipulators were for mouse-centric movement and should be replaced with knob or switch manipulators.

ATTR_manip_delta, ATTR_manip_wrap. These were designed to simulate knobs by click-and-hold – use the knob manipulators instead.

ATTR_manip_drag_axis_pix. This was designed to simulate a knob by click-and-drag – use the knob manipulators instead.

We Love Commands

As you may have noticed from this list and the ever-growing size of X-Plane’s built-in command list, we love commands – they have become our go-to mechanism for our aircraft. Commands have a few advantages over data-refs:

1. There is a clear design in the plugin system for changing a command’s behavior. So a third party aircraft can easily “take over” the existing engine start command.  This is very, very difficult to accomplish via datarefs.
2. Commands can be mapped directly to joystick and keyboard hardware. There is no way to bind a joystick to a dataref.*
3. Commands can be mapped to sound to capture the act of the user “doing” the thing, regardless of whether it works. For example, if you want the click of the starter switch regardless of whether the starter motor engages (maybe the battery is dead), commands make this easy to do. Often there is no dataref for ‘the user is trying but it’s not working’.

In X-Plane 11 we’ve been moving to commands to get our planes ready for VR, the new manipulators, and FMOD sound all at once.

In the next post I’ll cover some of the issues specific to VR and the 3-d cockpit.

* Developers who write plugins that provide external interfaces to X-Plane: make sure you have a way to provide access to commands and not just datarefs!  There are things you can do only with commands and not datarefs.

The post Manipulators and VR Part 1: From Mouse to Mechanism appeared first on X-Plane Developer.

You will be able to use VR directly in X-Plane 11 with any distribution of our sim:

• An X-Plane 11 digital download from Laminar Research (or any other reseller) if you have a 24-digit product key.
• An X-Plane 11 DVD set from Laminar Research (or any other reseller) if you have DVDs.
• X-Plane 11 on Steam if you bought X-Plane on Steam.

VR will work for X-Plane 11 no matter how you bought it. You do not have to have bought X-Plane from Steam to use VR.

(This post does not contain any guidance on supported hardware – I’d like to wait until we get further into beta and get some feedback on how system requirements affect actual users. This is just a reassurance that you didn’t buy X-Plane “the wrong way” for VR.)

What Is SteamVR

SteamVR is a free download from Steam’s app store that X-Plane (and many other games) use to talk to your VR hardware. We use SteamVR for both the HTC Vive and the Oculus Rift – X-Plane’s native VR support requires that you have both the Oculus drivers and SteamVR.

The good news is: SteamVR is free, and it works with the non-Steam editions of X-Plane as well as the Steam one.  If you are a Steam user, you just pick the app and download it; if you are a non-Steam user, you’ll need to create a free Steam account to get it.

(If you have the HTC Vive you almost certainly have done this already, as SteamVR is the only thing that lets you play games on the Vive.  If you have the Oculus Rift you can get apps directly from Oculus’ own app store, but SteamVR lets you get at a wider array of content.)

Why SteamVR on the Oculus Rift?

When using the Oculus Rift with X-Plane’s native VR, we have a bit of a game of telephone: we talk to SteamVR, which talks to the Oculus Rift drivers, which talk to the hardware. Why not talk to the Oculus drivers directly via their SDK?

The short answer is development time: we like SteamVR for the same reason we like OpenGL: we can write our app once and support a wide range of hardware from multiple vendors.  We don’t have to write our rendering engine twice for NVidia and AMD, and we don’t have to write our VR implementation twice for the Vive and Oculus Rift.

Our hope is that by using SteamVR, support for future headsets will be a relatively painless affair; SteamVR’s OpenVR API looks like the closest thing to a common API for VR.

(X-Plane is not locked into OpenVR – X-Plane has an abstraction layer and we could code to a second API if necessary.  But I’d rather have the dev team work on making X-Plane better than have them code the same feature over and over for multiple vendors.)

What Will We Support?

Recently I’ve received a bunch of questions about supported hardware, e.g. will we support Windows Mixed Reality (WMR) Headsets, or any of the software bridges to phones, or some of the proposed 8K headsets that are on Kickstarter.

I think we’ll end up in a very similar situation with VR as we are in with graphics cards and joysticks – we’ll have three levels for headsets.

• Supported. Right now this list contains only the Oculus Rift (CV1) and HTC Vive. Supported devices will be ones where we’ve spent testing and dev time making sure they work, and where we expect a great VR experience. We’ll add more to this list based on development time, but this category is only going to be for major selling headsets.  E.g. PSVR (e.g. Morpheus) might be a reasonable candidate here but (from what I can tell) OSVR is not.
• Unsupported. Even if a device is unsupported, we may still let you use it. If you want to try one of the new mixed reality headsets before we support them, go ahead and try – it might work. We’re not going to tell people “go get this”, but we’re not going to close the door to tinkering.
• Banned. If a device is really, really, really bad and awful, we won’t allow it at all, and we’ll take active measures to keep it from being used accidentally.

SteamVR will hopefully* let us easily put important devices in the supported column without too much dev time lost, and have wide support for unsupported (but not outright banned) devices.

* I say hopefully because the VR ecosystem is still very young.  We think SteamVR is a good choice for our implementation, but it’s too soon to say unequivocally “hardware vendors can just develop for this ecosystem and it works”.

The post You Can Use VR With Any Edition of X-Plane 11 appeared first on X-Plane Developer.

What Do I Need?

In order to use VR with X-Plane 11, you need an Oculus Rift CV1 (with Touch Controllers) or an HTC Vive. At this time, these are the only two headsets to have official support. It is, of course, our goal to maintain support with all mainstream and common headsets in the future but at this moment, these are the only two officially supported systems. In addition, you’ll need a Windows PC* with modern hardware and an installation of Steam and SteamVR. You do NOT need to purchase X-Plane through Steam even though the Steam App is a requirement. The Steam App is free to download.

What is This Release?

This is a preview of our VR support. This is not the final product. This does not contain the final set of features. The purpose of this is to let you all play around with it. It’s very usable. It’s very fun. It works very well but it does have limitations and artifacts like you’d expect from an early release. Aircraft authors should begin getting their aircraft ready to support VR headsets (documentation coming soon!). We will continue to add features and make adjustments based on user feedback.

Things To Try!

1. I know many of you have very elaborate and expensive hardware setups. I encourage you to abandon them…cut the cords man!!!!….move your chair away from your desk….just for a little while…and try flying the aircraft with JUST the VR controllers. I think it’s important to see how usable things are without the need for any hardware at all. Of course, we expect many of you will return to your hardware devices, I think it’s still a good idea to leave your comfort zone and just have a little fun too!
2. All of our default aircraft (with the exception of the F-4, CirrusJet, and SR-71) are completely VR-ready. PLEASE TRY THESE AIRCRAFT. You should be able to interact with any switch/knob/lever etc that you would have expected. The default aircraft have the minimum level of detail and usability that we expect to offer. Essentially, you should be able to do everything with the VR controllers and not need the keyboard or the mouse. They all have hotspots in the pilot and copilot seats. Many have hotspots in the passenger seats as well so you can put on the autopilot and watch the flight from there (we know you want to!). They all have a full set of working manipulators.
3. GRAB THE YOKE! The yoke is a SPECIAL manipulator. It is different than all of the others. The yoke is latching which means you click it once, and then you are attached to it until you click again. While attached, you can move your VR controller anywhere because the location of the controller does NOTHING. I recommend comfortably placing your hand on your lap or on an armrest. To control the aircraft’s roll, turn your wrist left/right as if you were turning a doorknob. To control the aircraft’s pitch, tilt your WRIST up/down. Your first instinct will be to move the yoke like a real yoke…pulling toward you…pushing away from you….we still may add the ability to do this but trust me it will fatigue you to have to hover your arm in the perfect position for a long flight. All of the rest of the manipulators in the aircraft should behave how they would in real life. Knobs get twisted…switching get flipped, levers get dragged etc.
4. Try the detented throttles on the KingAir. You have to pull UP on the throttles to get over the notch into Beta and Reverse. Try the detented flap handle on the 737 and 747. Like the Throttles, you have to pull up on the handle!
5. Scroll down the Aircraft list and try the Aerolite 103. This is a special aircraft designed just for VR to give you the sense of REALLY flying. There’s no walls, no floor…just you and the wing. It’s a beautifully detailed aircraft!
6. You have an xPad with a moving map on it! You can pick it up and put it down where you like. Each Default Aircraft has a ‘magnetic’ mount on the yoke so you can stick it there. Aim the laser pointer at it and use the trackpad/thumbstick to zoom in and out on the map. Use the laser pointer and trigger to move the map around.
7. Teleport around! You can do a walk around your aircraft and inspect it from outside and then teleport back into the aircraft. Get under the wing and up close with the wheels.
8. Press the Menu button on the controller to bring up a quick-menu. One of the most useful features is “Get back in the pilot seat” which will always put you back in the left seat no matter what view or location you are in. This is also incredibly useful for “adjusting your seat”. Let’s say for example you moved your office chair and now you’re straddling the throttle quadrant (ouch) in your view. Press the button to get back in the pilot seat and you’ll be repositioned. You can also bind this command to a key or joystick button for quick access.
9. Try Opening the Ground Services menu! You’ll get a 3D window popup that you can position/resize in 3D. Stick it somewhere in your aircraft and use the laser pointer to interact with it. When you’re done, move the controller to the red quit box and click on it. More 3D windows will be added soon!

Caveats and Known Limitations…

Aircraft

While the manipulators in some 3rd party aircraft may work at least partially, most will probably not at all. VR will require updates from the aircraft authors to really take full advantage of the manipulator system. We have been working on VR manipulator support for the 3-d exporters, and support for them is already shipping in X-Plane 11.10. We’ll get more info posted about VR and cockpit manipulators shortly.

Hardware setups

Right now, if you fly with your yoke bolted to your desk and have limited room to flail your arms about without knocking things over, you will find VR very limiting. This is why I suggested you ditch the hardware temporarily in “Things to Try #1” above. We DO plan on adding features that will make things easier if you do want to continue staying attached to your desk. Early tester feedback has made it clear that features such as mouse-pointer interaction as well as Headset Mounted Device (HMD) pointers are useful features to have. This will allow users to take advantage of the visuals of the VR headset without having to use the controllers to click on things.

Another limitation of being tied to your desk is positioning/teleporting. We plan on adding the ability to create VR quicklooks to position yourself around and customize the hotspots so that you can sit properly in your seat(s) without having to actually move your real seat. Currently, you can use the arrow keys as well as ‘<‘ and ‘>’ to slew yourself around and adjust your position. You can also bind the general up/down/left/right commands to a hat switch and use those.

External Apps and Windows

We currently do not support external apps and windows. Sorry, you cannot watch The Patent Scam while flying your 737 in VR. We do realize how useful it would be to have external windows but this will require more investigation.

Plugin Support

We currently do not support 3rd party plugin windows. We will open the VR system up to developers to allow them to do so in the future however.

How Do I Get It?

“BLAH BLAH BLAH…Just tell me how to get it already!”

Alright alright! The first thing you should do is tune your system to get your FPS up first! VR is very CPU intensive. If you cannot sustain ~45FPS without VR, you should adjust your rendering settings until you can. Turn down Reflection Quality, Scenery Shadows and maybe even Autogen. Once you’ve gotten stable performance around 45fps, then proceed.

Next you just install and setup the drivers for your headset as well as the software for your headset. Run their demo, set up your room config etc. Then install Steam and SteamVR and run through its setup and tutorial.

Now update X-Plane with “Check for Beta Versions” enabled. (Steam users – we love you too – the 11.20 VR preview is available as a public beta on Steam.)  Once you’re in X-Plane 11.20, go to your Graphics Settings and enable the “Enable VR Hardware” checkbox. Detailed instructions can be found here.

* Support for Linux will depend on the future development of SteamVR on that platform. Support for Mac will be coming in 2018 as it requires X-Plane moving to Metal.

The post X-Plane Public VR Preview Released! appeared first on X-Plane Developer.