Bringing VR Analytics to the Browser

Today we are releasing vrtigo-reactvr, bringing Vrtigo’s 360 video analytics to the browser.

What is Vrtigo?

Vrtigo collects and processes VR-specific data, giving content creators and developers heatmaps, retention summaries, and other ways of analyzing viewing habits. The vrtigo-reactvr package allows developers to integrate Vrtigo into their React VR applications that make use of 360 content.

What is React VR?

React VR is a new library from Facebook that allows developers to construct VR applications in JavaScript using a declarative markup language. Unsurprisingly, it looks and acts a lot like their popular React library. Developers create reusable components that can be initialized with values (props), contain internal representations of their current state, and be rendered to a variety of destinations (like the DOM).

React VR’s familiar approach to developing WebVR applications is less intimidating than diving into a game engine IDE like Unity or Unreal Engine. You can get started with React VR right now. The simplest ‘hello world’ app component looks like this.

class WelcomeToVR extends React.Component {   
  render() {     
    // Displays "hello" text on top of a loaded 360 panorama image.
    // Text is 0.8 meters in size and is centered three meters in
    // front of you.
    
    return (       
      <View>         
        <Pano source={asset('chess-world.jpg')}/>         
        <Text           
          style={{             
            fontSize: 0.8,             
            layoutOrigin: [0.5, 0.5],             
            transform: [{translate: [0, 0, -3]}],           
          }}>           
          hello         
        </Text>       
      </View>     
    );   
  } 
};

But why would someone want to develop a VR application in JavaScript? There are several compelling reasons, including iterating quickly, familiarity with the language, and existing tooling. However, the biggest question is: how will users consume a VR app in a browser?

Browser vendors have recently begun implementing support for the WebVR spec. In fact, Facebook themselves are developing a VR-first browser called Carmel. With Google, Facebook, and Microsoft committed to WebVR, the future of VR in the browser looks secured.

Notes on the JavaScript Implementation

The JavaScript implementation of our SDK is more straightforward than our Unity plugin. There are several reasons for this. First, the Unity implementation was our first SDK, so grew somewhat organically as requirements were being defined and our product matured. With the React VR SDK, we were ‘just’ trying to replicate the same API and data collection patterns as the Unity SDK. In short, we had the benefit of hindsight.

The only part of the Vrtigo SDK that explicitly relies on React VR is obtaining the user’s pose data. The React VR package exposes a VrHeadModel object, which allows us to obtain the current position and rotation of the camera object representing the user’s current point of view within a VR scene.

import {VrHeadModel} from 'react-vr';

const position = VrHeadModel.positionOfHeadMatrix();
const rotation = VrHeadModel.rotationOfHeadMatrix();

In the future, as more VR-related JavaScript libraries and frameworks become available, we can move the core of our SDK to a new npm package that each of our framework-specific packages depends on. For example, it would be trivial to implement an A-Frame version of our JS SDK that uses almost all of the same code base as our React implementation. The only change needed is interacting with APIs that give camera-related data.

The rest of the SDK is fairly straightforward. We make use of the promise-enabled axios package for all async communication with our server. This allows us to return a Promise object from our submit function. This gives developers flexibility with how they integrate Vrtigo into their applications. Since submit may be sending a relatively large data payload across the network, developers can manage this process in a way that makes sense in their application.

JavaScript Tooling is More Mature Than Unity’s

As alluded to above, the JS community, tooling, and ecosystem are all more mature than the counterparts in Unity. For our Unity plugin, we pulled in extensions from the Asset Store or wrote platform-specific native code for tasks such as serializing data to JSON representation, generating valid RFC 4122 Version 1 UUIDs, and even finding the current time zone of a device.

While true that we had to locate similar npm packages for some of those tasks in the JS version, it was much more straightforward to discover candidate packages, evaluate their maturity, add them to our project, and implement and test them.

Networking tasks were also greatly simplified when working in the browser. There are several mature HTTP packages on npm, and the availability of promises simplifies asynchronous networking code. For example, verifying that our health check endpoint is responding with a 200 status code before starting Vrtigo is trivial using promises in JS. In Unity, we resorted to using a coroutine for polling the isDone property to decide when HTTP responses completed.

Final Thoughts

We’re excited by the prospects of quickly iterating on development of VR applications to be consumed in the browser. Developers can get their feet wet with React VR right now, allowing them to use a popular language, familiar tooling, and drawing on the experience of an active community. With Facebook and Google both embracing WebVR, we are hoping to see some interesting browser-based VR applications in the near future.

Vrtigo is the next generation VR analytics platform for content creators, editors, producers, and marketers.