Four Adventures In React VR — Part I

Pulling the curtains behind the upcoming WebVR revolution.

May 13, 2018

Code & Design

EDIT**** Right as I was about to release this Facebook overhauled the majority of the React VR library to a slightly altered React 360 — I’ll be covering the differences in a follow up shortly.

The official WebVR (Web Virtual Reality) https://webvr.info/ defines WebVR as:

an open specification that makes it possible to experience VR in your browser. The goal is to make it easier for everyone to get into VR experiences, no matter what device you have.

In short, WebVR, as a general browser API, aims to bridge the future of web browsing by providing a beautiful cross-browser API for creating immersive 3D, virtual reality experiences. In web development, it’s common for frontend developers to account for responsiveness across multiple possible screen size. Most web developers account for, at a minimum, the two general sizes: mobile & laptop/desktop.

It’s my personal opinion that in a few short years, every website will have an additional, third, standard layout: a virtual reality layout.

So without further ado, let’s jump into the world of WebVR.

State of Development Libraries

As you can imagine, the options are quite limited when it comes to the development environment. After a few weeks of research, it became clear to me that there are four main front runners when it comes to WebVR frameworks:

  1. Three.JS — low level API built on WebGL
  2. A-Frame — HTML-like Entity Component System built on Three.JS
  3. React VR — React Native-like API built on Three.JS
  4. Babylon.JS — an open source 3D engine based on webGL

To my surprise, both aFrame and React VR are actually written on top of the Three.js framework. So either way you’ll end up leveraging Three.js — the largest difference between it & it’s counterparts lies not in the functionality, but in the functionally abstracted away in order to focus on maximizing developing virtual reality experiences.

Three.JS offers a much lower-level library that’s undoubtedly the best way to learn about WebVR with a deeper understanding; additionally, it’s likely the best candidate performance-wise of the each frameworks. However, for immediately jumping into strictly WebVR development, prototyping with aFrame or React VR is the preferred option as they both simplify the setup process & still offer a rich WebVR framework.

Image for post

So why React VR over aFrame?

Familiarity & comfort zone. I found aFrame to have both cleaner, clearer documentation & a larger support community. The aFrame.io documentation had multiple hands-on tutorial examples & the A-Frame registry contains beautiful VR models shared by a fairly active community.

Yet despite all of that, I found myself turning to React VR for my first foray into the world of WebVR. Again, in retrospect I attribute this to solely to familiarity:

  1. As a weekend hacker, I’ve picked up React web development as my main tool of choice so I figured I’d be easier to debug the non-VR stuff
  2. At SetDev, I could be biased, but we have some pretty kick-ass React developers — which meant I had someone to turn to in worst-case scenarios

Onwards We Go…

For the remainder of this first part, I’ll cover two quick insights I learned by weekend-hacking with React VR.

Experiment One: Worlds Tour

For this kickoff experiment, I followed Mike Mangialardi’s superb Learn React VR series. The idea is really simple: build a single container view with multiple buttons that, once clicked, changes the current panorama/360 image.

Main Lesson: user perspective matters infinitely more than developer convention, especially when you’re trying to mimic their world or bring them into a new one. This might seem obvious, but what was a bit less obvious is how to best implement this ideology in practice. One answer I found is reconsider how you’re used to display 2D content, particularly text:

It’ll feel very counterintuitive at first, but almost always opt for cylindrical surfaces rather than flat surfaces for displaying 2D text.

Experiment Two: BTChainVR

If you’ve stumbled across any of my other posts, it’s likely you know that I’m a huge blockchain & cryptocurrency enthusiast. So it was only natural that for experiment numero dos I explored the possibilities of building a WebVR block explorer. Specifically, I wanted to create a simple WebVR scene with two main visual components & a single API query for the latest Bitcoin block. The visual components I need to render:

  1. Display container with the latest Bitcoin block data
  2. Chain container with multiple children blocks

As you can see from the gif below, I opted to make the last block published a mesh-white, with the rest of the blocks a solid-Bitcoin-gold. The single HUD (heads-up display) shows the latest BTC block’s block height, total satoshis, total fees in satoshis, & the number of transactions confirmed within the block.

Main Lesson: test out what you’re used to! As a product designer, I’m used to visually tweaking any & all visual assets I see. Yet I hesitated to open PhotoShop or Sketch to edit the panoramic image you see in the background — for the astute observer, yes that is Wall Street.

Editing panorama images feels very differently than editing a flat image, the reason is pretty straightforward: it’s hard see the outcome of your edits until the image is warped again.

A quick tip for the uninitiated here is to consider applying any edit effects vertically. For example, in this experiment I wanted the background to have a dark opacity near the eye-level that decreases as the user looks up in order to bring focus to the important elements but still enjoy the background scenery where spatially it’s not competing for the users focus. So in Sketch, I laid out the panoramic image & applied a simple mono-color opacity gradient from top-to-bottom.

Closing Thoughts

For my fellow web developers, make no mistake — as mixed reality headsets become mainstream, users will begin browsing the web through headsets. So it’s best we begin exploring the nascent WebVR community & documentation as soon as possible.

I like keeping a manageable reading time of < 5 mins. so if you found this mini-guide entertaining or useful, make sure to hit that *follow* button so that you don’t miss out on Part II.