"Supported Platforms" in readme

[andybak]

The list of supported platforms has a couple of surprising (to me) omissions.

Generally my concern is "how to support all 6DOF headsets". Generally OpenVR will handle everything on PC - but native Oculus support is needed to get in the Oculus Store and I believe native WMR support is needed for the Microsoft stores. I'm generally making stuff for public events so supporting the stores isn't a big priority to me.

What is incredibly useful is being able to build something that will run across PC, 6DOF Android - and hopefully in the next few weeks - the Oculus Quest.

The Lenovo Mirage Solo and the Quest are incredibly well suited to events and exhibitions. I'd be very interested to know if there are any plans for support but at the very least you could add them to your list to make it clear that they currently aren't supported.

(Incidentally - what's the distinction you're making in that list between OpenVR and SteamVR? I'm not aware of one that would effect this framework. They are essentially the same thing in this regard)

[StephenHodgson]

@andybak Hi! thanks for opening this issue.

Yeah, that's something we've been thinking out quite a lot lately.

Thanks for clarifying that OpenVR and SteamVR aren't exactly the same things, and in fact SteamVR is on our roadmap (we should def add it to the list of supported platforms we want to target). We've even had some interest from Valve and Oculus about gaining support for their platforms using the toolkit.

One other thing we're looking at adding a walk-though about adding newer supported devices.

If I can get my hands on a Lenovo Mirage Solo or the Oculus Quest, I'll gladly add support as long as I have enough time. @SimonDarksideJ can help in this area too.

[andybak]

Hiya,

Thanks for clarifying that OpenVR and SteamVR aren't exactly the same things,

Actually, I was rather trying to make the opposite point - that there are the same thing as far as the support needed for your framework is concerned.

[SimonDarksideJ]

From a publishing perspective they aren't.
Openvr is a supported spec for general devices that (for the moment) run on the steamvr platform. But this spec is based on the vive hardware only. So the two extra buttons on the rift touch are not supported and only one of the dual axis controllers on wmr.
If you want to support knuckles or other valve custom hardware, you have to use native steamvr, you also need to incorporate steams auth services to publish to steam.
Oculus has a similar story with its devices and you have to have the Oculus API in your app to publish to epic's store (also recently found out you cannot have steam dlls even in you project to publish to Oculus)

We're in talks with each of these vendors to find the best path for xrtk.

[bddckr]

OpenVR is the API, SteamVR is the runtime.

OpenVR isn't OpenXR. OpenVR may/will be OpenXR-compliant, as such SteamVR as a runtime will most likely be, too.

But this spec is based on the vive hardware only.

This has nothing to do with HTC Vive hardware - SteamVR is a runtime that ships with drivers supporting SteamVR Tracking.

So the two extra buttons on the rift touch are not supported and only one of the dual axis controllers on wmr.

This is also unrelated - this distinction is "just" old OpenVR vs. new OpenVR (thus SteamVR old vs. new, too): The new input system in OpenVR/SteamVR supports anything.
The SteamVR Tracking drivers shipping with the runtime support this fully, but not all other drivers. The WMR driver done by Microsoft themselves for example still doesn't AFAIK.

If you want to support knuckles or other valve custom hardware, you have to use native steamvr, you also need to incorporate steams auth services to publish to steam.

This is isn't correct - you can support Knuckles (Valve Index Controllers) without having to support or publish on Steam. The Knuckles driver is shipped separately from the SteamVR runtime, but all it is is a driver loaded by the SteamVR runtime, then giving support through OpenVR for the Index Controller hardware. Nothing here forces you to interface with Steam in any way.

Since the SteamVR binding UI only comes via Steam you could argue that is what forces you to use it, but AFAIK if your user is running SteamVR this will all still work just fine if you ship bindings for their hardware. They don't need a rebinding UI if they just use your default bindings.

---

My tl;dr is:

• OpenVR is Valve's VR API.
• SteamVR is the runtime the OpenVR API talks to.
• Don't confuse APIs, runtimes or Stores you may want to publish to and please differentiate them: You can build apps for SteamVR using OpenVR and never ship to Steam. You can build for Oculus devices using the Oculus SDKs and engine plugins, but also never ship to their store.
• Users need a runtime for their devices and your software to talk to that hardware. You do so by using an API/SDK. That API/SDK is currently only supporting one runtime, but OpenXR may be changing that (as most vendors have stated to be spec-compliant some day, at least for the Application layer).

[StephenHodgson]

@bddckr thanks for the breakdown! Super useful information here.

[StephenHodgson]

Now that we've updated the front page can we close this?

[andybak]

The table on the home page still makes a strange distinction between Open VR and Steam VR and makes no mention of the Oculus SDK.

[StephenHodgson]

@SimonDarksideJ thoughts on this?

[SimonDarksideJ]

It's in the new one we are releasing in about 10 mins :P
https://github.com/XRTK/XRTK-Core/blob/0885f41fe4e2b7e95fe2834648d11eecc92e985d/README.md

[StephenHodgson]

Looks like it

[andybak]

That's still got OpenVR and SteamVR - even taking into account the info in this ticket I don't understand the distinction.

[SimonDarksideJ]

There, any better now. Added a little more clarity
https://github.com/XRTK/XRTK-Core/blob/19daaf82411e5b432cb6e14599725fd187b32dd6/README.md
(or just removed the sections that were adding confusion

[andybak]

OK. What's the difference between "OpenVR", "Native SteamVR" and "Vive Index"?

I can see how you might implement SteamVR/OpenVR and omit features specific to the Index Controllers but it's not clear that's the intention here - and there's still the distinction between SteamVR and OpenVR that I haven't yet been able to understand.

[SimonDarksideJ]

Well, OpenVR is a basic cross-headset support mechanism for limited controls. 1 button per controller, 1 dual axis input (touchpad or thumbstick), 1 grip and one trigger (anything else won't work)

Native support on any platform, gives you native access to those devices and their full capabilities.

[andybak]

How does that differ from SteamVR pre-Index?

In what sense is it meaningful to talk about 3 levels of API compatibility? (OpenVR, SteamVR, Index)

Surely two of these are the same? I understand the "runtime vs API" distinction but is that anything other than theoretical in relation to XRTK?

[FejZa]

I did some "research" here since I didn't feel I have all info needed, but now I tend to agree we should remove SteamVR as a supported platform in the Readme since it's essentially OpenVR, see ValveSoftware/openvr#291

[FejZa]

So the readme would read

• OpenVR
  -- HTC Vive
  -- Vive Index

Instead of

• Native Steam VR
  -- HTC Vive
  -- Vive INdex

[SimonDarksideJ]

So my issue there is this, you would then need to list:

• OpenVR
  -- HTC Vive
  -- Vive Index
  -- Oculus Rift
  -- Oculus Quest
  -- Windows MR

OpenVR is an open standard for interoperability between headsets, effectively allowing other platforms to run on the Steam VR client.

Valve also provides a native SDK (As a Unity Asset), the same as the other providers, which provides native capabilities in the steam client beyond the realms of OpenVR. This enables controllers such as the Index controller, the new input system, additional headset capabilities such as pass-through and more.

I'm happy to update the page to whatever anyone wants, but I want to avoid confusion when we do integrate the Steam API for native Steam support.

OpenVR like OpenXR is just a standard with a specific set of capabilities. Steam VR supports OpenVR, as does the Oculus Client.

[bddckr]

Valve also provides a native SDK (As a Unity Asset), the same as the other providers, which provides native capabilities in the steam client beyond the realms of OpenVR. This enables controllers such as the Index controller, the new input system, additional headset capabilities such as pass-through and more.

This is all available to anyone using OpenVR API directly. The Unity plugin is nothing more than an engine integration. I'm not sure where this idea of "native" is coming from but normally that would be reserved for managed vs. native code, which isn't the case here - OpenVR's API is actually used via managed code in the SteamVR Unity plugin, same as any user of the API could be doing themselves. Additionally Valve provides language-bindings for the OpenVR API for a lot of languages.

but I want to avoid confusion when we do integrate the Steam API for native Steam support

Steam is a software store and platform, SteamVR and OpenVR are different things. If you are thinking about adding platform-feature support for Steam to this project I don't think anyone would be confused as those are two different things which their names already identify.

OpenVR like OpenXR is just a standard with a specific set of capabilities.

OpenVR isn't a standard, it's the proprietary API to a proprietary runtime called SteamVR. Both are a product of Valve.

Steam VR supports OpenVR

SteamVR is the runtime that makes any application that uses the OpenVR API work with devices. It's not a case of "supports OpenVR" it's a case of "works with OpenVR to form a product of Valve".

, as does the Oculus Client.

The Oculus runtime, as distributed by Oculus (the company) does not support OpenVR. Oculus' Unity plugin (engine integration) allows developers to target both OpenVR and Oculus' API (and thus their runtime). Oculus' runtime does not support running OpenVR titles at all. Their store even prohibits uploading applications that merely reference the OpenVR API libraries.

The Oculus hardware driver that is shipping as part of SteamVR is made by Valve. It is a driver for SteamVR, the runtime, to support Oculus' PC VR devices, i.e. the Rift product line.

---

I think contributors/maintainers of this project need to take a few steps back and understand this as it's really important. As I noted half a year ago you have to understand and differentiate between APIs, runtimes, stores and even engine integration packages. That should allow you to define the scope of this project's support for the various things.

I'm not in the loop of what your goals are, so I'm just listing everything here as supported as an example to show off the various distinctions:

This project aims to work with the following APIs. This means that any runtime that is supporting these APIs will work with your project should you utilize XRTK.
* OpenVR
* Oculus'
* ...

By definition of each vendor this might or might not allow you to release your project on their platforms' stores. Currently we're aware of the following truths, but please check with each vendor's documentation for up-to-date information and details:
* Titles that support the SteamVR runtime (using the OpenVR API) can release on Steam.
* Titles that support the Oculus runtime (using Oculus' API) can release on Oculus Home and their mobile-specific stores (they are separate). Note that Oculus does not allow shipping binaries that reference or include OpenVR API libraries or Steam platform libraries.

If you want to play a game of cat-and-mouse with vendor decisions etc. you could change that text obviously.

[StephenHodgson]

OpenVR isn't a standard, it's the proprietary API to a proprietary runtime called SteamVR.

I thought this was supposed to be some bridge for the VR industry to be able to run any VR devices (on steam of course lol). That doesn't bode well for OpenXR then either.

This whole conversation is confusing to me. Just seems like platform vendor wars and developers are caught in the middle of it.

Our main goal with the XRTK is to be able to write an application once and build/deploy it on any device. (arguably what Unity should do out of the box, but it's a dream for sure)

Their store even prohibits uploading applications that merely reference the OpenVR API libraries.

This is a very good point here, as we want to manage the active libraries being built into the solution.

I think the conversation is really just semantics about how to properly display the supported platforms. FWIW I think we ought to only say we support a specific platform if there's one or more applications that have been published to that platform vendors marketplace/store.

Fair?

[bddckr]

I thought this was supposed to be some bridge for the VR industry to be able to run any VR devices (on steam of course lol). That doesn't bode well for OpenXR then either.

OpenXR is a standard, though 😄 Full working group and standard committee at Khronos behind it! Valve really just fucked things up by naming it "Open" VR. (It's open for extension, but that's about it.)

Supported platforms/devices/APIs with a "sticker of approval" by knowing there are shipped applications is a great idea. There might be a point about differentiating between "works with", "can work with", "is supported by us" and "is successfully used in production". I'm sure that actually is a matrix, as you can use something unsupported, yet still successfully sell on stores using it.

[andybak]

A year on and the readme is still utterly confusing! This is the first thing people will see when investigating XRTK and at first glance it looks as if you don't support the Vive or Index (which I presume isn't true)

I've never had anyone explain to me how "Open VR" support differs from "supports Vive and Index". I know there's plenty of discussion above but it seemed to go round in circles.

[StephenHodgson]

Great feedback, we'll be sure to adjust the wording for our next doc update in #584