# 20161104 - Is OpenVR Actually Open?

References,
OpenVR Documentation
As someone who was waiting for an Open VR API, I watched the above linked YouTube presentation from Steam Dev Days, and decided to see if such an API actually has now arrived (as of November 2016). Something which might enable me to continue the work I had to stop a while back when consumer VR got locked down and disabled my ability to do what I needed as a developer. Lets see how the current OpenVR stacks up,

- Ability to Use Vulkan? - Looks like this is in progress based on the YouTube video. Very happy about this.
- Language Agnostic? - OpenVR requires C++, "The API is implemented as a set of C++ interface classes full of pure virtual functions". OpenVR is effectively closed to other languages because it does not support standard C exports.
- Application Ownership of Display? - Specifically open ability for the application (sold directly to the consumer, or sold through Steam) to have full ownership of the HMD display output without being forced to go through an out-of-process compositor, and with ability to do the ultimate in low-latency: front-buffer rendering.
  The ComputeDistortion and other related functions do provide ability to query the image transform required for direct rendering. Unfortunately this function, based on the docs, does not have an obvious return value of if the coordinate can be seen or not. Seems like one has to use GetHiddenAreaMesh instead and then write some complex code to check if the pixel intersects the mesh. This problem seems relatively minor to fix in the OpenVR API.
  The only display interface on the API Documentation Page says, "IVRCompositor - Allows an application to render 3D content through the VR compositor". Which is a very interesting choice of words for an "Open" API. The idea that the application needs to do something to be "allowed" to render 3D content, and only "allowing" such 3D content to go through some non-application VR compositor? I only see a Submit function. So no front-buffer access, and also no back-buffer access (no ability to create your own swap chain). Looking deeper at the openvr.h headers reveals, `EVRSubmitFlags`, which has a comment which confirms that the API only supports the highest overhead path of an extra copy in an out-of-process compositor: "/** Allows the application to control how scene textures are used by the compositor when calling Submit. */". Again the "Allows" wording. Digging deeper there is "Submit_LensDistortionAlreadyApplied = 0x01", which does seem to provide un-WIKI-documented support for submitting a post-warped image.

And the Conclusion Is ...
Not there yet.
Once an application sold on Steam can run VR with Vulkan, and with application-owned HMD display with direct front-buffer access, then it will be time to re-evaluate.