Sunday, April 9, 2017

The Unique Requirements of Public VR

A good treadmill for home use costs around $1000. A treadmill for use in a health club could be ten times more expensive. Why would club owners agree to pay so much more? Because they understand that the home equipment would not withstand the heavy use in a club.

The same is true for VR goggles. Goggles for home use are not suitable for sustained use in arcades and amusement parks. Both VR vendors and attraction operators need to understand and address these differences.

Durability is one key issue. A goggle in an amusement park is subject to both accidental and intentional abuse. A kid might try to see if a lens can pop out. Someone else might wish to take a component as a souvenir.

Hygiene is also important. VR experiences can be intense, and parks can be in hot and humid areas. Whether it is sweat, suntan lotion or something else, a guest does not wish to wear a soaked or dirty goggle. This is true not only for the face mask, but for any built-in headphones.

Sweat and humidity might also cause fogging on the lenses. If a guest has to take off the goggles to defog them, the break in VR immersion degrades the experience.

Depending on the attraction, visitors can be of all ages. Good physical fit is important, regardless if the visitor is a small kit or a large man. Goggles must accommodate a wide range of head sizes, and eye separation. Eyeglasses also present a design challenge. Visitors prefer to keep them on, so goggle vendors try to make room for them.

Beyond the customer-facing experience, there are important operational considerations. Attractions make money by providing a unique experience to a large number of visitors. Every minute spent by a guest adjusting straps in a roller-coaster, is a minute lost. Some have reported a 30% decrease in guest throughput after upgrading a roller coaster to VR. A larger park crew assisting guests or maintaining headsets means larger operational costs.

There are several different types of public VR experiences, each with unique challenge. A free-roam experience (e.g. Zero Latency) needs to address backpack PCs and controllers. Themed experiences such as The Void have accessories that supplant the story. These accessories have many of the same challenges. A small attraction in a shopping mall cannot afford a large operating crew. A VR roller coaster might need a chin strap to keep the goggles on the head. If a VR roller coaster relies on standard phones, they might overheat or need to recharge often.

Often, the first instinct of those building VR attractions is to do everything. They might try to build their own goggles, create content, or even a tracking system. Over time, they focus on their core competencies, bringing external vendors for everything else.

The first generation of these solutions show the immense promise of public VR. VR Coaster, for instance, has deployed GearVR-based roller coaster experiences in over 20 parks. These use a special tracking system to determine the position of each car at any time. The Void and Zero Latency use backpack PCs to allow guests to explore unique spaces. Talon Simulations provides flight and driving simulations in malls. IMAX opened a VR center where guests can try a variety of 10-minute VR experiences. Most of these first-generation solutions use consumer-grade hardware. Operators realize that many problems still need solutions. At the same time, consumers learn what they like and dislike in current solutions.

HMD vendors are also rising to the challenge. ImmersiON-VRelia has developed phone-based goggles that feature a reinforced plastic construction. Sensics released goggles with detachable face mask to address both hygiene and operational efficiency.

What's missing? Low-latency wireless video solutions to get rid of cables. Faster ways to adjust goggles for guest. Better methods to clean goggles between guests. Phones the don't overheat. Multi-user experiences with a stronger social aspect. The passage of time to see what works and what doesn't. VR standards to help integrate new devices into compelling experiences.

I am excited what public VR experiences could be. My excitement comes both from a user standpoint - these experiences are fun! - but also from a problem-solver view - the problems are challenging.

Try these experiences next time you can. Going to a movie theater provides a different experience than watching at home. Going through a good public VR experience is beyond what VR at home provides.

Monday, April 3, 2017

Suffering, Art and VR Standards


Think about a great work of art: a classic book, a timeless painting, a symphonic masterpiece. What's common to many of these creations?

They were all the result of great suffering.

Tolstoy, Van Gogh, Mozart - they did not have easy lives. Many of the greats suffered from oppression, mental or physical illness, or hunger.


If you don't have drama in your life, how could you summon drama for your art?

People ask me "what made you want to work on VR standards?" My answer: it's the suffering.

No, not my personal suffering. I'm no Amaedus or have never considered cutting off my earlobe to express love.

But in many years of working with customers on their VR systems, I saw a lot of technical suffering:

The suffering of integrators that need to chase the latest API again and again. That don't know if the equipment they design for today will be available to buy in a year.

The suffering of device manufacturers that need just one more driver to support them.

The suffering of end-users that wonder if today's software will work on tomorrow's devices.

That's why we need efforts like OSVR or OpenXR to make it easy for everyone to work together. It wouldn't be as timeless or profound as "War and Peace", but it will help a lot of people.

Saturday, April 1, 2017

Unholy Alliance

A few weeks ago, we were approached by a VR porn site seeking a partnership.

It is no secret that adult entertainment is an early adopter of many new technologies and virtual reality is no exception.

We respectfully declined as we decided a long time ago that we won't participate in this market.

Besides, I'm no longer as good looking as I used to be.

Monday, March 27, 2017

Virtual Reality Standards: too early or long overdue?

This article originally appeared on Mar 22nd at ReadWrite
You bought a new printer for the office. You unpack and connect it to your PC. You install its demonstration software and see the printer works well. Then, an unfortunate surprise: your word processor cannot work with this printer. You'll need to wait until the maker of the word processor releases a new version. When will this version be available? Should you return the printer? Should you change to a different word processor?

If this sounds like the 1980's, it's not too far from where VR is today. VR programs are often hard-coded to one set of hardware devices. Only a particular HMD, coupled with its tracking system and controller will work. Every device manufacturer has a different API. If you want to use this VR experience with a different set of hardware, you might not be in luck. At best, you'll need another version. Worst case, you just won't be able to do it. The problem of different vendors having different APIs is often called 'API fragmentation'

VR standards can help solve this fragmentation problem. In the PC world there are a few basic device types: keyboard, mouse, printer, scanner, and so forth. Likewise, basic VR device types include an HMD, tracker, controller, and a few others. A standard way for a program to interface with these VR devices would help solve this problem.

If software could work across different hardware combinations, almost everyone would benefit:
  • Consumers could mix and match devices to their liking. I may have a Dell computer but I don't always want a Dell printer to go with it. Furthermore, consumers would be confident that their investments are future-proof. A 2017 game would likely work with 2018 or 2019 hardware. 
  • Game publishers and other experience creators would have a larger addressable market. Today, they hard-code their game to a particular set of hardware devices. Tomorrow, they would support any device that has a conforming 'driver'. 
  • Manufacturers that support a standard would have their devices work with lots of content. This would allow even small players to enter the market, and promote innovation. 
Some claim it is too early for a VR standard. VR is new, they say. Let a couple of years pass and then we will know what to standardize. Yet while consumer VR is new, VR has been in academia and industry for decades. Labs and factories deployed HMDs, head and eye trackers, and controllers for many years. Such devices were expensive and perhaps more clunky, but still performed the same functions. Software frameworks like UNC's VRPN (http://www.vrpn.org) provided device independent access for many years.

The resistance to a standard sometimes stems from the competitive strategy of a company. A vendor relying on a 'walled garden' approach often wishes to control the entire stack. The ability to swap out hardware, or use a different app store might be not what they had in mind.

In VR, there are often two standard interfaces that need to defined. The first is the device interface. This defines how to configure devices of particular type and how to extract data from them. Printers have different capabilities but share the same basic functions. The same is true for VR devices. The second standard interface is the application interface. It describes how an application or a game engine renders its content and get data. Inbetween the applications and devices there is often a middleware layer. That middleware is the software intermediary between applications and devices.

One effort that adapts this approach is OSVR. Started by Sensics and Razer, it is an open-source software platform for VR. OSVR implements both a device interface layer as well as an application layer. OSVR supports over 200 devices, and most of the OSVR code is free and open-source.

Another effort is OpenVR which is an open API (though not open source) from Valve. Building on the success of SteamVR, OpenVR allows HMDs to work with SteamVR content. There is some compatibility between these efforts. An OSVR plugin for OpenVR, allowing OSVr devices to work with SteamVR content.

In January, the Khronos group (known for OpenGL standards) launched a new VR initiative. The initiative, called OpenXR, brings together a wide range of companies. Industry leaders including Google, Oculus, Valve, Sensics and Samsung are part of this effort. OpenXR aims to combine lessons learned from building OSVR, OpenVR and proprietary APIs. It aims to create both a device interface as well as application interface. It is unclear how soon this effort will mature. Khronos standards take an average of 18 months. It is also unclear what capabilities will be part of the first standard. What is clear is that these companies felt enough pain to want to work on standards.

I am encouraged that so many participants are coming together to work on a standard. Other interested parties are also invited to contribute. Standards are sometimes boring, but they are important. They will make the consumer experience better and promote innovation.
This article originally appeared on Mar 22nd at ReadWrite