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. X-Plane’s “xPad” is an example of UI that’s integrated into the VR world. 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. 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. 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.
XPAD PLUGIN WINDOWS
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.Įventually, 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. This follows straightforwardly from the fact that we don’t support programmatic positioning of windows, but it’s worth noting separately. You can’t restore window positions from prefs This is something we’re looking at supporting in the future, once our own internal format for handling positions gets locked down. 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. 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. And, by allowing the user to position the window thereafter, we sidestep concerns about occlusion, intersection with 3-D objects, etc. 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).
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!
the window fits in the cockpit, but will be occluded by 3-D objects (how much occlusion is too much?).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 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?).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!Ĭonsider 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: You can’t place windows in a specific location in VR There are a few unsolved problems here-most of which are unsolved for both plugin windows and X-Plane’s built-in windows. This mirrors the way the built-in ATC window works right now. 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. 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. XPLMSetWindowPositioningMode(my_window, xplm_WindowVR, 0) With XPLM301 defined for your project, you can use VR as “just another positioning mode,” similar to how we treat pop-out windows: XPLMDataRef vr_dref = XPLMFindDataRef("sim/graphics/VR/enabled") Ĭonst bool vr_is_enabled = XPLMGetDatai(vr_dref) The changes are part of the SDK version 3.0.1 release.
I’m happy to say the initial implementation of this-allowing windows to float in 3-D space, Minority Report-style-is live in VR6. One of the biggest requests we received with the previous VR previews ( 1, 2, 3, 4, 5) is to allow plugin-created windows to join the VR fun.
0 kommentar(er)
