OSVR (Open Source Virtual Reality) aims to create an open and universal standard for the discovery, configuration, and operation of VR/AR devices. Created by Sensics and Razer, OSVR includes two independent components: 1) the OSVR software platform and 2) the open-source Hacker Development Kit VR headset.

Guest Author

yuval sensicsYuval Boger joined Sensics in 2006 to help take VR from the lab to the market. Nearly a decade later, he brings his unique technical and market expertise to work with consumer electronics, industrial, and academic leaders to help them shape the art of the possible in VR. He is a key architect of OSVR, the open-source virtual reality initiative, and a frequent presenter at conferences. Yuval shares his thoughts about VR technology and the VR market at VRguy.net.

Since the OSVR launch in January this year, nearly 250 organizations including Intel, NVIDIA, Xilinx, Ubisoft, Leap Motion, and many others have joined the OSVR ecosystem. Concurrent with the expansion of the OSVR community, the capabilities of the software platform have grown by leaps and bounds.

See Also: OSVR Gets NVIDIA ‘Gameworks VR’ Support, Adds 65 New Industry Collaborators

The Sensics team architected the OSVR software platform and is its official maintainer. Below, I describe my personal perspective on the road ahead for the OSVR software along several paths: interfaces and devices, game engines, low-latency rendering, operating systems, utilities, and high-level processing.

The Big Picture

Diagram of current open-source OSVR projects. See latest version at http://osvr.github.io/contributing/

The goal of the OSVR software framework is to make it easy to create compelling, high-performance VR/AR applications that:

  • Work on as many VR/AR displays and peripherals as possible.
  • Support even those devices that were not available at the time the application was created. Just like you don’t need to upgrade your word processor when you buy a new printer, you should not have to upgrade your game when a new HMD becomes available.
  • If desired, can run on a wide range of operating systems and computing platforms.
  • Take advantage of the unique features of individual devices, as opposed to reaching for the ‘lowest common denominator’.
  • Are not locked into a particular device, peripheral, development environment, programming language or app store.

The OSVR framework aims to achieve these goals while open-sourcing the vast majority of the software in order to:

  • Encourage participation from the broader VR/AR community.
  • Provide adopters the security and peace of mind that they desire.
  • Accelerate the pace of development by including a wide community of contributors.
  • Allow adopters to customize the platform to their specific needs.

Last, OSVR leverages existing open-source projects (OpenCV, CMake, VRPN) and is designed with a modular, plugin-based architecture so that:

  • Participants can opt to keep modules closed-sourced so as to protect IP.
  • Adopters can choose a small footprint deployment by choosing only the modules they need.
  • Functionality such as support for new devices can be added after the fact.

Interfaces and Devices


razer hdk vr headset osvr (3)
The OSVR HDK is modular with open-source design plans

In “OSVR speak”, an interface is a pipe for data of a certain type (“interface class”). Devices are said to expose interfaces to the OSVR core, and in turn, to an application. Such interfaces include tracker (provides position, orientation, or full pose), button, analog (axis of a joystick, analog trigger value), eye tracker (gaze direction), gesture, imager (single image or image stream), locomotion (for omnidirectional treadmills), skeleton (bone structure) and display (output device).

A single physical device may provide data in more than one interface class, just like a multi-function printer might look to an operating system as a printer, a scanner, and a fax. For instance, here are some interfaces exposed by popular devices:

osvr table

Imagine that you are developing a viewer for 360 degree videos and you want to allow the users interact with it using gestures. With OSVR, because you work through a universal device-independent gesture interface, you can use any device that has an OSVR plugin. In the above example, these devices would be products from Leap Motion, NOD, YEI and Softkinetic. All these devices would expose gestures to the app in a standardized way. Contrast this approach with the hassle of having to integrate every one of these devices individually. Moreover, when new devices such as the Intel RealSense camera get an OSVR plugin that includes a gesture interface, they work immediately work with your app without having to change a single line of code.

Current Status

To date, the OSVR team has primarily focused on creating the various types of interfaces, connecting popular devices that illustrate that these interfaces work, and creating simulation plugins that allow developers to work with simulated data in lieu of using a real device. Aside from native OSVR plugin, OSVR also inherits support for about 100 devices from VRPN, a popular open-source project.

Future Plans

In the coming months, I believe that the OSVR team, OSVR hardware partners, and other OSVR contributors will significantly expand the number of devices supported by OSVR. Specifically, I am aware of plans and work in progress to support Intel Realsense, Tobii eye trackers, NOD devices, Leap Motion camera, HTC Vive and others.

Game Engines


OSVR performs a very important service for both game engines as well as for hardware devices that wish to be supported by these engines.

The problem is that there are many graphics and game engines (Unity, Unreal, Crytek, VBS, Mongame, OpenVR, Unigine, WebVR, etc.) and numerous hardware devices. If each hardware vendor wants to be supported by each engine, a lot of drivers will need to be written and many person-years will be spent in integration and optimization. Moreover, this “many-to-many” connectivity (seen in Figure 1) puts a lot of stress on engine developers as they need to continuously educate and support hardware developers as well as relentlessly work to keep up with the latest hardware and driver versions.

Figure 1 – Without OSVR: each device needs multiple plugins

In contrast, when using OSVR, a game engine needs to have a single integration with OSVR to support all OSVR-supported hardware. The OSVR game engine integration provides a harmonized, standardized way to connect to all devices that support the relevant OSVR interfaces: whether tracker, gesture, skeleton, eye trackers or others. The OSVR team and community can work with each engine developer to create an optimized integration, so there is no need for hardware developers to learn and re-learn the intricacies of each engine. If a new hardware device comes on the market, the hardware manufacturer (or an interested member of the OSVR community) can create a device plugin for OSVR, thus automatically achieving connectivity into all OSVR-supported game engines. Because OSVR is open-source and plugin-based, the availability of such plugin does not depend on the priorities of Sensics or any other company. A developer can simply start from an existing open-source plugin and quickly modify it for the specific API of the new device. The result is illustrated in Figure 2.

Figure 2 – With OSVR: a single OSVR plugin makes it easy to support many engines

Current Status

OSVR is integrated Unity, Unreal Engine, and Monogame.<

Future Plans

  • A plugin for OpenVR (Valve) is in beta and should be completed soon. This will allow OSVR-supported displays and devices to be used with OpenVR/SteamVR games, though subject to the limitations of the OpenVR API.
  • An OSVR backend for WebVR in Mozilla Firefox has been submitted to the Mozilla project and we expect it will become part of the Firefox WebVR nightly build very soon.
  • A team of students is working on a Blender Game Engine plugin. As part of this effort, they are creating a Python wrapper for the OSVR Core client functionality, which should allow easy integration into other engines such as WorldViz Vizard.
  • Possible integrations into CryEngine, Bohemia VBS3 and others are being discussed.

Due to conscious design decisions made when developing the client (game/application) API, because there are multiple language wrappers available for the native C OSVR API (C++, .Net and soon Python), and because existing integrations are open-sourced, it is easy to integrate OSVR into additional engines, including internal engines and custom applications.

Continue on Page 2


This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. See here for more information.

  • vrguy

    Ben – thanks for publishing. Just as point of clarification – the diagram that appears under the ‘big picture’ heading is the current directory of open source projects. Same diagram appears on the Github site http://osvr.github.io/contributing/ and is updated from time to time.

    Additional devices that are supported by OSVR can be seen as part of VRPN:

    Our vision for OSVR is broader and includes supporting many additional devices, game engines, etc.

  • Don Gateley

    Wow! Awesome article. Thanks. Here’s hoping OSVR can drive the walled garden content systems like those for the Gear VR out of business.

    • vrguy

      Thanks, Don. We’re not trying to drive anyone out of business. We are trying to create choice for end users and opportunity for developers. Would be great to continue to grow the impressive list of partners that want to work together for “VR without borders”

  • augure

    I was dubitative at first and didn’t see a point, but after toying (or trying to) around with the DK2 and GearVR for years, I feel like OSVR will actually be the way to go in order to achieve what consumer VR is supposed to be. Oculus/Vive/PSVR are too expensive, bulky and limited, and mobileVR is too much limited, which is the reason why some people aren’t drinking the Kool Aid and are starting to warn about a scenario in which VR doesn’t take off because of artificial barriers of high-end VR and profit (no hand-tracking is conceptual non-sense for VR for example). If OSVR is accessible and modulable enough while working on most platform/engines, I think it’ll be the preferred platform to go in the coming year for VR development.