154 SHARES Facebook Twitter Linkedin Reddit

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.

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.

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 targeting.” 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.

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.