Google SDK vs Dive SDK

In the previous post I used the Dive plug-in to create a simple VR app for Cardboard.  Shortly after I'd created the test app, I discovered the official Google Cardboard SDK for Unity. Therefore my next step was to try it to see how the two compared.

Although the Google package appeared more cumbersome, I quickly found that it was much more flexible.  One key -- and rather important -- distinction was the ability to detect Cardboard's magnetic trigger switch.

The outer neodymium magnet (countersunk ring shape) is held in place by a ferrite (ceramic) disc magnet, glued inside the headset.  The ring can slide downward and, when released, flicks back into alignment with a pleasing, spring-style motion -- a genius bit of design.  The photo illustrates how the switch affects the phone's compass sensor.
(Source: Ben Lang's "Road to VR" blog)

Certainly the Google-driven app seems to behave itself better on the phone.  I'd found that my Dive apps had a habit of losing track of head position during fast movement, meaning that the 3D landscape would unexpectedly re-orient direction (i.e. yaw) or roll the horizon to a permanent angle.  That's a biggie in bug terms, and undermines it significantly.  I'm guessing that the Dive headset design may use the magnetic sensors to assist with determining alignment -- something that Google eschewed due to Cardboard's magnetic switch.

Every Cardboard app I've seen has used the hardware 'back' button to quit, but my Dive test app ignored this button.  Access to hardware buttons is obstructed by both Cardboard and Dive designs, so the only time most users would press 'back' is after de-coupling their phone from the headset -- so it's not much of an issue.

Another problem I found was that, after mixing the Google and Dive SDKs in the same project, the Dive app started crashing badly when recompiled.  There's obviously some kind of conflict there.

Updated: I'd suffered crashes when mixing Dive & Google SDKs in the same project.  However, the same problem later started to affect Google-SDK-only projects.  It now appears that this is a bug caused by corrupted files within Unity.

The Google SDK is not all roses: in particular, the manual is a bit rubbish.  When testing the Dive app within Unity's game window, the mouse controlled head movement.  It took me three days to discover (by examining the SDK's C# scripts, eventually) that Google's SDK supports mouse control only if you hold the ALT key down.  Most unhelpful.

Updated: ...and another two weeks to discover that the CTRL key allows the head to roll from side-to-side.

As a side note, I understand that the Samsung Gear VR phone-based system is based on Oculus Rift so, presumably, the Oculus Rift official plug-in for Unity may offer some support in this direction.  However, my investigations so far suggest that this will be far from straightforward.

A test environment in Unity using the Dive plug-in

It may sound obvious to conclude that Google's own SDK works best for Google's VR system, but in 33 years of programming I've discovered that presumptions always need to be tested.  It's used-up a fair few hours of my life but I'm satisfied that I'm now working with the right tools for the job.