OpenVR isn't open

[comex]

There appears to be no source available for this library. Even though it's nothing but a small wrapper for backend drivers (also closed source?), without source code it is not possible to add support for other HMDs, compile for platforms other those with provided binaries (e.g. Raspberry Pi), or use the library from GPLed applications such as Dolphin (which is already unable to release VR support using the Oculus SDK, despite a working proof of concept, for similar reasons). At best the BSD license on the header ensures the legal right to write a full reimplementation, but this does not seem to be an expected use, unlike in the case of standards such as OpenGL.

Sorry for the semi-troll issue, but I don't see how such a thing can be considered open.

[feilen]

The way this library is intended to work, is it's more of a straight-up API that any company can implement for their HMD. You run the OpenVR supported program, it loads the dll/so for OpenVR, and uses the calls in that to talk to whatever HMD you give it.

This is Valve's implementation, which admittedly doesn't have source available. But basically all this does is connect to SteamVR, which currently has Vive and Oculus connectivity.

If Oculus decides to implement OpenVR support in their driver, they can supply their own libopenvr_api.so/dll which the program can load instead, directly connecting to the ovrd service.

If (third party random HMD manufacturer) decides to implement their own OpenHMD library, they can, and should instantly have support in all OpenHMD titles with zero effort.

I think the 'open' refers to the nonrestrictive license of the API, which is the real 'open' part.

[feilen]

What this means for Dolphin VR (which I contribute to) is that it could ship with OpenVR support, but lacking an OpenVR library, and if the user (or control panel for the HMD, supplied by the manufacturer) tells it to load their own OpenVR implementation, their HMD should work with very little effort, and no effort on our part.

Since the library is so unrestrictive, this might be the push necessary to get Dolphin VR support integrated into the main Dolphin project.

[ellenhp]

The name is really misleading and disingenous. I mean it's not even source-available. It would be really nice to have a GPL-compatible shim that could dynamically load free or nonfree HMD drivers so GPL games could get headset-agnostic VR support but so far it doesn't look like that's possible.

[feilen]

It would be! Someone just has to implement it. I personally somewhat want to go back and add support for pre-2010 HMDs, like the (awful) Vuzix VR920, just for kicks.

On Sun, May 3, 2015 at 8:40 PM, Nolan Poe notifications@github.com wrote:

The name is really misleading and disingenous. It would be really nice to have a GPL-compatible shim that could dynamically load free or nonfree HMD drivers so GPL games could get headset-agnostic VR support but so far it doesn't look like that's possible.

Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/openvr/issues/8#issuecomment-98565278.

[comex]

@feilen The Windows binaries are distributed only as static lib files, the documentation for VR_Init states that it 'finds the active installation of the VR API', and the library is mostly just a wrapper that dlopens 'driver' libraries. Ergo, I believe that this is intended to be redistributed with VR applications, and multiple implementations would exist for the driver libraries.

[JeroMiya]

Kind of wish valve had just embraced OSVR. It's got a much broader scope, and includes position, orientation, pose, analog/button inputs, skeletal tracking (hands and body), and eye tracking. It supports input devices distributed across a network (e.g. using a smartphone or smartwatch as an orientation tracker from your PC), and is based on an already proven industry standard (VRPN) used for many years. It's also extensible and supports "virtual" interfaces in a pipeline - for example, a plugin that takes raw sensor data and smooths it, or combines multiple orientation/position sensors into a skeletal pose tracking interface.

[feilen]

I agree, but on the bright side OpenVR can be implemented as an OSVR module and vice versa. Then any headset supporting either would support both. On Jun 17, 2015 19:27, "Sleepy Daddy Software™" notifications@github.com wrote:

Kind of wish valve had just embraced OSVR. It's got a much broader scope, and includes position, orientation, pose, analog/button inputs, skeletal tracking (hands and body), and eye tracking. It supports input devices distributed across a network (e.g. using a smartphone or smartwatch as an orientation tracker from your PC), and is based on an already proven industry standard (VRPN) used for many years.

— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/openvr/issues/8#issuecomment-112979199.

[JeroMiya]

Yeah, I think an OpenVR plugin is coming to OSVR. I don't suppose an OSVR plugin for OpenVR would be too difficult to make. Just seems like a waste of effort when the two libraries clearly have overlapping goals.

[SiliconSapphire]

I would like to build an ARM 64 Linux box with support for HTC Vive, why is this called OpenVR, what about it is open? compile for linux on ARM 64 somehow.

[KarjamP]

From the way I see it, the wrapper's the intended library. If you were to look at the readme situated in the "src" directry, you can see that it implies this while describing what it does. In fact, this is what's actually getting compiled when you tell Cmake to build the project.

The way this API works is no different than the way OpenGL works as well. Believe it or not, but applications must first load a dynamic library, which acts as a wrapper, before it can even use OpenGL. The usage of OpenVR, therefore, is no different from this concept. There's even differing implementations of that dynamic library, several even closed source, just as what would be intended for OpenVR.

You guys are complaining because the most well-known implementation of the standard, SteamVR, isn't, itself, open source. But, SteamVR is merely an implementation of OpenVR. It's not OpenVR itself.

[ChristophHaag]

because the most well-known implementation of the standard, SteamVR, isn't, itself, open source

As far as I'm aware there is no other and SteamVR is the de-facto implementation of OpenVR.

If anyone would like to actually do something to change that, I started here but could use some help: https://github.com/ChristophHaag/openvr_api-libre