News Microsoft to add SteamVR support to Windows Mixed Reality

Steam VR support was always going to be an essential feature. It'll be interesting to see how inside out tracking works with the games that make the greatest use of motion controllers. For example I can't imaging playing Climbey with a system that requires me to keep both hands in view at all times.

My fear is that MS's platform has the potential to reach more people than Vive/Rift, and if controller tracking ends up being inferior we risk creating a VR standard that's not 'best in class'

 

That's a real surprise, both on Valve deigning to deal with UWP, and Microsoft basically pulling the rug out from under the Windows Holographic platform for anything outside of enterprise applications.

That's definitely a worry: every Windows Holographic HMD unveiled so far has used LCD panels with full-persistence driving at 60Hz (and with non-adjustable lens separation and singlet lenses), so back to DK1 levels of smearing when moving your head and distortion at the edges of the field of view (any anyone outside the average IPD being SOL). That they're not even using pulsed backlights should be embarrassing for those releasing them.
Against the launch prices of the Rift/Vive they made sense as bargain-basement alternatives, but with the current dropped prices? You'd be a fool to 'save' £100 unless you really need access to the Windows Holographic platform.

 

I think it's more a case of Microsoft deciding to support OpenVR than Valve dealing with UWP.

 

As with OVR, for SteamVR to 'support' another API it basically mimics an application and acts as a protocol translation layer. For Windows Holographic, the only API hooks available are through UWP, so for SteamVR to hook into them it must have a UWP shim.

 

SteamVR (OVR) isn't supporting another API, Valve and Microsoft are most likely going to collaborate on a OVR (SteamVR) driver so their headsets work with SteamVR content, much in the same way as Vive and Rift worked with Valve to support their hardware.

 

Over at engadget they've had some hands-on time with the headset and controllers and their first impressions are quite positive. In a nutshell they're kind of a combination of the vive and oculus controllers. Not sure how it works out with the tracking though. Correct me if I'm wrong but I think the $300 headset price doesn't include the controllers either. I'm more interested in the increased resolution and how the visual experience compares to the vive and oculus. Haven't seen much on that yet.

 

... That's exactly what I said, and is exactly how SteamVR 'supports' other devices: SteamVR acts as a single program (no mater what actual program is running) and exposes itself as such to the actual driver, which is what drives the HMD. API calls need to be translated between them, and end up as a subset of what the two are capable of. This is how the OVR support in SteamVR works today.

The rmeotes are tracked optically as long as they are within your field of view. When they leave it, they are tracked for 1-2 seconds inertially, then after that they are locked in position and track orientation-only untill they get back in view and jump to the correct position. Mechanics like 'drawing a bow' or any interactions that 'pull' objects from outside your field of view (e.g. the 'back holster' mechanic) will not work.

Pure angular resolution is increased (as a combination of higher density panels and a smaller field of view), but the tradeoff is that the fill-factor is worse (more 'screen door effect'), and the optics are back to the days of the DK2/DK1 with fixed singlet lenses. Looking off-axis will cause the image to blur, and if you do not happen to have the same IPD as the fixed lens separation distance then it will be impossible for you to get both eyes in focus at the same time.
On top of that, all the HMDs announced so far have used LCD panels rather than OLED, and use full-persistance driving rather than pulsed backlight, so any head movements will cause the view to blur.

 

Must be my mistake then as i thought you said Valve deigning to deal with UWP and SteamVR was going to 'support' another API.

 

That is what they're doing, SteamVR works by translating between APIs, so must support every API they want to talk to. Here's how SteamVR works with the Rift:

Game : OpenVR API -> OpenVR API : SteamVR : OVR API -> OVR API : Oculus Home -> HMD

To work with Windows Holographic, it would still need to do the protocol translation:

Game : OpenVR API -> OpenVR API : SteamVR : WinHolo API -> WinHolo API : Windows Holographic UWP host -> HMD

But the problem is in that highlighted section: the Windows Holographic API hooks are only available as UWP API hooks, they are not available to Win32 applications, so the chain needs to look like this:

Game : OpenVR API -> OpenVR API : SteamVR (Win32): OpenVR -> OpenVR : SteamVR stub (UWP) : WinHolo API -> WinHolo API : Windows Holographic UWP host -> HMD


-------------


As an aside, garbage devices like the PiMax and Deepoon HMDs that 'support' SteamVR don't talk to SteamVR using the OpenVR API, but instead expose themselves as OVR API devices using an old SDK version (0.8.x) without Direct Mode support (i.e. they act as dumb monitors). These devices using a knockoff of the OVR API was the reason the 'HMD check' (that caused a furore when it broke ReVive) was implemented, and so far has prevented further knockoffs and left them stuck on an old version.

 

That's not how OpenVR works.

My emphasis added to highlight that OpenVR doesn't rely on the HMD's software development kit, OpenVR issues its own functions depending on what hardware header is returned.

Using your example it would be... Game -> OpenVR -> HMD or if you were running the game via Oculus Home, UWP, or Steam it would be SteamVR client, Oculus Home client, or Windows Holographic client (UWP): Game -> OpenVR -> HMD.

OpenVR, Oculus SDK, and Visual Studio with the Windows 10 SDK are the application programing interfaces and software development kits, SteamVR, Oculus Home, Windows Holographic (UWP) are the HDM's bespoke clients, just like the Steam client and Windows Store (UWP) are nothing more than glorified launch pads for the actual program.

 

And that only works because SteamVR is doing the protocol translation.

The OpenVR API calls are not translated to OVR (or Windows Holographic, etc) API calls through magic, they require a piece of software in between. That software is SteamVR.


OpenVR basically has two APIs under its name: the API client applications use to talk to SteamVR and the API SteamVR uses to talk to an OpenVR HMD. Currently, the only OpenVR HMD is the Vive. Everything else requires SteamVR to talk to the HMD drivers via the API those drivers expect, be that OVR, Windows Holographic or otherwise. In any case, SteamVR sits in the middle or nothing actually works.

 

SteamVR is a suite of tools and services for VR including OpenVR, Chaperone, Compositor, Lighthouse Tracking, and more., OpenVR is just part of what allows the application and HMD to talk to each other, saying SteamVR is doing the protocol translation is like saying the normal Steam client is translating the display, mouse, keyboard, and sound protocols.

See above, SteamVR is a suite of tools and services for VR, OpenVR is the part of that suite and translates the calls between the HMD and application via the HMD's own driver, but there's no need to take my word for it as you can read what Joe Ludwig said.

 

Open VR is the API. SteamVR is, as well as an umbrella term for a bunch of other stuff (Valve now call Lighthouse 'SteamVR Tracking', for example) the actual program that runs in order for programs usiing the OpenVR API to do anything. It is literally the name of the executable that performs the protocol translation.
In theory, one could implement their own software that accepts both 'ends' of the OpenVR API and remove the requirement for SteamVR, but the same could be said for OVR (or DirectX or any other API with a closed implementation but public API) and thus far if you want to use OpenVR your options are SteamVR, SteamVR, or SteamVR.

 

Just because SteamVR has to be running doesn't mean it's the API, that's like saying because Steam has to be running to play a Steam game using the Steam controller that Steam is the API for your graphics card.

 

As I have said multiple times:
OpenVR is the API
SteamVR is the executable.

Without SteamVR running, you can have a game using the OpenVR API running, and a Vive (or Rift, or WMR HMD, etc) attached, and nothing will happen.

 

So you didn't say "SteamVR works by translating between APIs" or "SteamVR is doing the protocol translation" because it certainly appears you've been saying SteamVR is what's translating between API's and SteamVR is doing the protocol translation, when in fact what you meant to say is that all of that's done by OpenVR and SteamVR is nothing more than client software that's used to launch other applications.

Like i said must be my mistake then as i thought you said Valve deigning to deal with UWP and SteamVR was going to 'support' another API when i fact you're saying OpenVR is going to be doing that, and even then only when it detects a Windows holographic device or application.

 

I'm not sure how I can possible be more clear about this:

OpenVR is the API.
SteamVR is the application that communicates with stuff using this API.

SteamVR also acts as a launcher, but that is secondary to it's actual functionality and you could dike out both the bigscreen-on-a-virtual-screen bit and the new 'Steam Home' bit and it would still do it's core job of allowing applications that communicate with the OpenVR API to actually interface with devices. If you took out that part but left the fancy UIs in, nothing would work because there would be no communication between application and HMD.
It's the exact same situation as with Oculus Home: the core functionality of handling communication between application and HMD (e.g. compositing & warping application output and sending to the HMD, and collating tracking data from the HMD and sending the fused pose to the application) is bundled up into a closed-source blob along with the 3D user interface/environment.

That's what I said, because that's exactly what is happening. To communicate with Windows MR HMDs, you must use the Windows Holographic API, because that is the only API they accept. If you 'talk OpenVR at them' you get the exact same bugger-all as if you'd tried to 'talk Mantle' at a GeForce driver.

OpenVR is not going to be doing squat, because it's an API. It doesn't 'do' anything independently, it's an interface specification.

SteamVR is the executable that talks to applications with one API (OpenVR), and to device drivers with another (OpenVR for the Vive, OVR for the Rift, Windows Holographic for the Windows MR HMDs).

 

The reason your not being clear is because you're wrong, OpenVR is indeed the API but SteamVR is not the application that communicates with stuff using that API.

Don't take my word for it though...



How much clearer do you want it to be than hearing it from Joe Ludwig who says @3:10 that "there's no requirement to ship OpenVR content on Steam"

Have you even looked at the OpenVR github? OpenVR is what allows the application and hardware to talk to each other, you don't need Steam to do that, if you developed an application interface to present the user with the information going and coming from OpenVR then you could do just that.

You could even read this reply on the Steam Forums where another Valve developers says the following...

Obviously you're free to believe whatever you like but if you won't take the word of the actual developers of OpenVR and SteamVR then there's really nothing more i can add that will convince you that Steam (or SteamVR) is not a requirement for being able to use OpenVR.

 

That's a complete non-sequitur. What service an executable is delivered by has nothing whatsoever to do with SteamVR and OpenVR. You can ship an OVR application through a non Oculus Home service too, but that has no relevance on the API or driver.

OpenVR is the API. It is the interface specification. It is not the implementation of the executable that performs tracking (for Lighthouse), protocol translation, etc. It does not compile to SteamVR.

Here's a trivial way to test this: uninstall SteamVR. Start an OpenVR game with the Vive (or any other HMD) attached. Notice how it completely fails to work. Applications using the OpenVR API rely on the presence of SteamVR to work.

SteamVR is not Steam. I have not once stated that Steam is required to use OpenVR, but SteamVR is (Steam is the only delivery mechanism for SteamVR as Ludwig has stated, but SteamVR can run without Steam active).

----------------------------------

It seems you are confusing SteamVR with Steam itself. Steam is the storefront that handles distribution. SteamVR is an application delivered through that storefront. Both can run independently (e.g. you can run Steam without SteamVR, and run SteamVR without steam running). Steam must be installed in order to install SteamVR (only distribution method, relies on some libraries installed with Steam) but steam does to have to actually be running to run SteamVR.