Phone-based VR without the Phone

There are two main VR configurations today: PC-based VR (e.g OSVR HDK, HTC VIVE, etc.) and phone-based VR (e.g. Samsung Gear VR, Google Cardboard, etc.). Each approach carries different advantages: PC-based VR allow using high-power graphics cards; Phone-based VR is highly portable and battery-operated.

The rationale behind phone-based VR solutions is two-fold:

1. If you already have a phone, the incremental investment for a VR experience is low. Gear VR is under $100 now, and Cardboard is much cheaper. For casual VR, popping a phone in a carrier is a convenient solution.
2. Today's phones have high-resolution screens, integrated cameras, increasingly better motion sensors and many additional capabilities that are very useful for VR. Because they are mass-produced, they are very cost-effective.

However, upon closer investigation it appears that a user of phone-based VR is paying - both in cost and in weight - for phone components that are not truly necessary for VR. For instance one could argue that the following components are not truly necessary:

• Cellular connectivity
• Phone body. If the phone is permanently integrated into the cradle, one does not need the weight of the body itself.
• Touch screen
• and more...

Now that VR is gaining steam, VR devices are going to have modules and components that are designed specifically for VR instead of settling for parts from other electronics devices. For instance we'll see screens made for VR (small size, higher refresh rate, low persistence). Given this, it would not be surprising to start seeing phone vendors provide pre-integrated VR goggles that are essentially a phone without the unnecessary components coupled with a cradle/head strap. These would be lighter than separate phone + cradle and probably also less expensive than the combination.

What else would you like to see in 2016?

Complex VR installations and "my word processor only works on Epson printers"

No one likes to buy software that only works on one piece of hardware.

Imagine I sold you this wonderful word processor but that it could print only on Epson printers. You might say "That's ok, I have an Epson printer today and I really like it", but then you'd worry: what happens if I get an HP printer next year? Will I need to buy a new version? Will this wonderful word processor support HP in the future? So maybe you'd be reluctant to buy this word processor from me.

Same in VR.

What if you buy a game and it works only on one HMD? Will you need a new version next year when you get a new HMD next year? Will the game support this HMD? What if you buy a shiny new hand sensor next year. Will the game work on it?

and... what if you are building an experience such as a large-scale public VR project for which you need to take 'best of breed' components from various vendors? Maybe your HMD is from one vendor, and the gaming weapon is from another and your wide-area tracking system is from a third. You'd like to find a way to support all of these, while giving you the ability to upgrade them in the future. What if your wide-area tracking system is on order, or on development, but you need to develop with another tracking system in the interim?

That's one problem that the OSVR software platform can solve. OSVR supports over 100 devices today, and allows you to mix and match devices as you please. Changing from one device to another is as simple as changing a configuration file, almost like selecting which printer you want to print the document on.

For instance, we just returned from the I/ITSEC training and simulation show in Orlando. We wanted to show the OSVR HMD (BTW, check out this great video showing multi-user training using the OSVR HDK). We also wanted to show the dSight, a higher-end HMD. These two HMDs are quite different:

• The OSVR HDK has a single HD1080 input, the dSight has inputs.
• The OSVR HDK has a circular field of view of just over 90 degrees. The dSight has a rectangular field of view of about 120x64 degrees.
• The two units use different IMUs: an internal IMU (based on a Bosch chip) for the HDK, a YEI tracker for the dSight.
• They have different distortion functions
• and so forth

Using OSVR, we just had to change the configuration file of the OSVR service, and could run the same demo without changing a single line of code. In fact, if a new combination of HMD and tracking system came out tomorrow, we would not need to bother the application developer. Just get a plugin or a configuration file for OSVR and run with it.

This concept also works for wide-area systems that have multiple players in them. You might have a centralized tracking system (for instance, from ART), that tracks multiple players and objects. Each OSVR client (e.g. the per-user application) can be configured to receive just the particular players of interest and then use this data to render on the HMD of choice. You might even have different HMDs in the same space.

This flexibility is a win for everyone:

• Game developers can develop knowing that their games will work on many different hardware platforms.
• Hardware developers know that as soon as they configure or develop an OSVR plugin, their new hardware will work on pre-existing OSVR-based games
• End-users and integrators have the peace of mind knowing that their investments are future-friendly.

or you can settle for always printing on Epson.