OpenVR isn't open #8
6 participants
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.
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.
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 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.
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.
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.
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.
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.