vr headsets

With multiple consumer VR headsets now on the horizon, many users will soon be choosing to go with one over others. Will it be difficult for developers to support multiple VR headsets from a single application, rather than creating custom distributables for each individual headset?

This guest article is written by Yuval Boger, CEO of Sensics, a Maryland-based company specializing in professional-level head mounted displays since 2003. Boger also blogs about VR on his personal blog, VRguy.net.

Let’s assume that you wrote a game that runs on the Oculus Rift. You are starting to see hear about other VR headsets, such as Sony’s Project Morpheus, and ask yourself: how difficult would it be to modify my game to support these other HMDs? The good news, for developers and users, is that it shouldn’t be very hard.

Porting a game to work in VR for the first time probably took some work: creating two separate and non-overlapping view frustums, understanding the optical distortion function and how to implement it, positioning the camera correctly, remapping the location of the menu items to a visible spot, changing the interaction model to suit an immersive display and more. Adding support for another VR headsets on a similar computing platform (e.g. PC) would likely include the following:

  • Change the optical parameters: address a somewhat different field of view and likely a different optical distortion correction function (or no correction required at all)
  • Change the display parameters: potentially different resolution and screen orientation
  • Accept tracking data in a different format: while the API may be different, head trackers ultimately return quaternion or yaw/pitch/roll data, so the application needs to deal with them regardless of the particular format. Hand position trackers (such as the PlayStation Move) fundamentally provide XYZ coordinates and other position trackers would do the same.
  • If a VR headset has built-in speakers: Modify the model for directional audio to take into account that the position of the headphones moves with the head, as opposed to static speakers on a desktop.

Application developers would be well-served to create or use a hardware abstraction layer that separates the what (e.g. positional data) from the how (the specific API by which that data is obtained). I’ve previously written about the need for such abstraction layer, similar to VRPN for motion tracking. It would be great to have some kind of open-format descriptor for each VR headset, to be either read by the application, the game engine or the operating system. Valve’s VR SDK, for instance, is an excellent step in the direction of supporting multiple VR platforms.

How should we prepare for the forthcoming wave of VR headsets?

  • If you are a game developer, prepare your code to support multiple VR headsets and, if applicable, publish the descriptor that would allow this to happen. By doing so, you are likely enlarging the market for your product.
  • If you are a gamer, make your opinion known so that engine and game developers will work towards a multi-platform experience.
  • If you make VR headsets, publish their characteristics so that those who write descriptors for them have all the data that they need.

After all, why limit the market potential to a single type or vendor?

Newsletter graphic

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. More information.

  • Brad Hawthorne

    Could always send a set of validation hardware to us at Nthusim to ensure it’s 100% compatible with our universal driver.

  • spyro

    I thought, that’s exactly what the open Steamworks VR API (https://github.com/ValveSoftware/steamworks-vr-api) provides for developers (which works outside of steam, too?)?

  • Steveparker

    These head mount technology is going viral these days. Gaming industry uses this technology or headsets a lot. Adjusting and mounting should be done while doing proper reading.


  • markhenry03

    Software quality and testing is core and last part which software must be gone through. The deployment should only be done after making sure that software is working fine as required. I completely agree with your post that customers will complain if there is a functionality issue in software but you do your best.