Evaluation of Mobile VR Solutions by John O'Neill
Posted on August 14, 2019
During the evaluation phase of our work with ECU, the development team had to assess and balance the need for portability, quality, and scalability between devices. We evaluated a number of devices that were both tethered (hard line connected to the display port and/or USB on the host computer) as well as untethered solutions that ran the entire VR experience via an onboard Android operating system. To develop for the project needs, we selected Unity due to the cross-platform ease of use as well as the team's experience and comfort level of development. The Oculus Quest has two 1600x1440 OLED screens that run at 72 frames per second. By default, apps render to 1216x1344 eye textures. Like Oculus Go, Quest uses an open-ear audio solution that pipes sound though the straps directly into your ears without covering them. It also supports regular headphones via stereo headphone jacks on each side of the headset. The Snapdragon 835 chipset includes an Adreno 540 GPU, which runs at 710 Mhz. This is a “binning” or “tiled” GPU, which means that it cuts the scene up into a grid of tiles and renders each in sequence. Oculus Quest comes with 4 GB of memory, 2.75 GB of which is available for applications. Quest supports OpenGL ES 3.1 and Vulkan, which is a plus if we need any advanced graphical features (not likely in the first iteration, but future-proof considerations are always good to keep in mind.) The asymmetric warping is free and automatic to Quest apps (we’ve already done the integration with Unity and Unreal).
Our ultimate selection of the Quest over the Go, or other tethered solutions like the Vive or upcoming Reverb, was due to the match to our original needs of portability, quality, and scalability. The portability was a given with the untethered design, and future iterations were more than likely to continue this trend. As a note, we did discover the option to tether with a USB-C connector for improved visual punch by leveraging the computer's onboard GPU, however this is not a feature we identified as being essential for this project. The quality level of what the Quest was capable of achieving was more than adequate given the examples we built and had seen in the Oculus store. Performance tests with multiple realistic scenes and animated characters were also evaluated to maintain a stable 72fps, and alleviate any uncomfort from the end users.
The final consideration was the users of the simulation. Our target audience was not intended to be gamers, and not even experienced VR users. The design and flow of the experience would have to take this into account and balance the training between in-headset tutorials and pre-headset videos or discussions to educate on the basic use of virtual reality.