With multiple proprietary VR systems on their way to retail, development fragmentation in the VR market has recently become a hot topic in the VR community. In this guest article, a veteran developer who goes by the name of ‘Phr00t’ shares his recent significant advancements using Valve’s OpenVR, which in theory offers a single development target for VR creators.


Phr00t started game development over 10 years ago, and now holds titles on Steam (3079, 3089, 4089, and Spermination). Spermination & 4089 were developed for virtual reality, and the upcoming 5089, an action RPG, will be supported in a VR environment too!


Virtual reality is just now becoming a reality, and the development environment for it is still forming. It has always been my goal to support free and open ideals, and I want nothing less for virtual reality. I want you to buy into virtual reality and experience everything it has to offer, without worrying if you bought into the ‘wrong’ ecosystem.

social-vr-featured-chris

In a perfect world, we’d have the freedom to choose what virtual reality system to buy among a long list of great, interchangeable options. Every headset would work with every input device, and every piece of software would be compatible with excellent support. Of course, the reality is much different. Companies are using different tracking methods, shipping with varying input devices and touting exclusive deals with software developers. This leaves consumers with the choice of picking what ecosystem they want to buy into, or having to pay the large price of buying into more than one. Developers also have to worry about who to target and who to potentially leave out.

When the Oculus Rift was the only big virtual reality player in town, it was an easy decision to target that hardware. I purchased a development kit and had a ton of fun experimenting with it. Then, HTC and Valve announced the Vive. Suddenly, there was another viable option out there that my games built for the Oculus Rift wouldn’t work on. Other headsets were being announced too, like OSVR’s HDK, FOVE and StarVR. Continuing to develop with the Oculus SDK meant not supporting these other devices, which went against my inclusive nature.

SEE ALSO
Oculus Mum on Rift Support for MacOS as Apple and Valve Forge Ahead

Then I found Valve’s OpenVR, which is described as “an API and runtime that allows access to VR hardware from multiple vendors without requiring that applications have specific knowledge of the hardware they are steamvr_logotargeting.” Sounds perfect, doesn’t it? Implementing such a lofty goal is a little easier said than done.

OpenVR is tied to SteamVR, which I soon found out had poor support for the Oculus Rift out of the box. Even the ‘hello world’ VR demo ran very poorly when I strapped on my Rift. I knew I had to do my best to make this work, though, because I shared the same goal as OpenVR: open and universal VR gaming and development. I loaded up my favorite 3D engine, jMonkeyEngine.

jMonkeyEngine is a free, open-source and fully featured 3D engine. You can develop on any operating system, for any operating system. Imagine that working, side by side, with OpenVR? A match made in heaven: VR gaming, with any supported headset, on any operating system. Software and hardware could compete and grow with no artificial borders. Sound too good to be true? Maybe… or maybe not.

After some tinkering with the OpenVR system, I quickly realized difficulties using the ‘VR Compositor’, which is an optional tool to automate a bunch of virtual reality features. That tool is used by default on SteamVR applications, which appears to be the source of the compatibility problems. The VR Compositor isn’t available on Linux either, so I set out a way to work around it. I had to forgo the much desired ‘Direct mode’, which allows easy virtual reality operation by displaying a game just on your headset. Fortunately, I discovered a way to bring many of the benefits of Direct mode to the backup mode, called Extended mode, where a headset acts like a second monitor.

SEE ALSO
Windows VR Support on Steam Leaves Early Access, Claims Significant Improvement Since Launch
jmonkeyengine-phr00t-screen
Phr00t’s demo application running through OpenVR

Using jMonkeyEngine and OpenVR, I finally had a breakthrough: smooth, accurate & fast Oculus Rift support. My tools would find the Rift (configured as a second monitor), automatically display a game fullscreen and without any additional configuration that haunted previous ‘Extended mode’ applications. The best part is, I knew I wasn’t just getting the Oculus Rift to work. Vive, FOVE, StarVR, OSVR… should now all work with this ‘Easy Extended Mode’ on Linux, Mac, and Windows.

With all of that said, this universal library solution does support the VR Compositor. So, when Valve improves it, developers can enable it with a flip of a switch. That should enable Direct mode, where supported, too.

My goal of open and free development is becoming a reality, and I want to share it with you. There are free, open-source and cross-platform tools out there to make a game that every VR fan should be able to play, no matter what VR headset they buy or operating system they run. If you want to experiment with platform-agnostic development and deployment through OpenVR, you can experiment with the tools I’ve created here.

Phr00t’s Universal OpenVR Library Demo

Requirements:

  • Requires Java 8 (which can be bundled for formal distribution) and SteamVR via the Steam client
  • Tested on Windows 8.1 with Oculus SDK v0.6.0.1 & Linux with Oculus SDK v0.5.0.1

I also need to mention OSVR which is partnering with OpenVR. OSVR is working on some interesting developments themselves and all of their source is open (compared to OpenVR, which isn’t).


Our thanks to Phr00t for taking the time to compile this guess piece for us. You can find out more about his work over at his official Facebook page. His github VR library for jMonkeyEngine can be found here and his custom jMonkeyEngine source repo here.

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

    Phr00t – thanks for the OSVR shoutout and good work on your part. We should talk about how to connect jMoneykeyEngine to OSVR because OSVR gives you a lot of what you are seeking:
    – Multi-HMD support (including Oculus)
    – Direct mode support (coming very shortly)
    – A device-independent model
    – Support for dozens of input devices
    – Android and Windows compatibility with the same API
    – Distortion measurement and correction
    – Latency measurement
    – and yes, SteamVR connectivity very soon.

    and much more.

    @OSVRguy

  • ttakala

    Indeed, open-source and cross-platform tools are needed. Right now it’s bothersome to add support for all the different HMDs and input devices, and OpenVR and OSVR are welcome initiatives that hopefully alleviate this.
    Low level hardware support is one thing, and creating high-level 3D User Interface building blocks that can be used with a variety of devices is another issue. We are developing RUIS toolkit for Unity, which offers different 3DUI building blocks and currently supports Oculus Rift DK1 & DK2, Kinect 1 & 2, Razer Hydra, and PlayStation Move:
    http://ruisystem.net/
    In the future we hope to add support to more input devices and HMDs like HTC Vive, CV1, etc. I’ll be keeping my eyes on OpenVR and OSVR, they might prove to be very useful.

  • vrguy

    @ttakala – even if you build your own Unity environment instead of the OSVR Unity plugin, you should consider using OSVR as your layer to:
    – Get the characteristics of various HMDs from field of view to distortion matrix
    – Get a standardized interface to input devices, trackers, eye trackers, gesture cameras, etc.

    You could still add value at the Unity layer but why re-invent the wheel on the lower layers? OSVR already supports more than 100 different devices

    You can use the open-source OSVR Unity plugin as a reference wrt how to read OSVR data into Unity.

    • ttakala

      vrguy,
      Yup, I’ve been considering this for the reasons that you listed. Earlier I thought of supporting VRPN but right now OSVR seems like the way to go as it also includes VRPN.

  • Renato Wisocki Junior

    just use Unity3D

    • phr00t

      A very valid option, although the library in this article is more universal & free. You can develop on Linux, for example. This library & jMonkeyEngine will allow you to develop for free without a splash screen that says “Personal Edition”, like Unity3D. Finally, the “easy Extended” mode isn’t available in Unity3D & if Unity3D just uses the SteamVR Compositor for Direct mode, it just doesn’t work on the Rift (currently).

  • Badelhas

    Very nice article indeed, thanks. I am not a developer but I’m convinced that HTC Vive will be the winner since Valve is backing them