When the $99 GearVR hits the market this year, and as folks learn that they can get a great VR experience I really think that it’s going to take off and build momentum. With the obvious (to consumers) advantage that having Netflix and Hulu and games available on your GearVR, that extra nudge to try VR and get converted to a VR enthusiast isn’t that tough a call. Pretty much *anyone* who’s tried a GearVR with good VR content comes away desiring one. It takes entertainment to a whole other level. Great for consumers. Great for content creators. Bad for VR devs.
Developing for GearVR is a monumental pain. Take the disadvantage of Android programming in general, throw in the fact that you’re testing on a device that you not only have to upload the APK to, but you need to put the device on your face to see if it actually looks right. Plus the fact that you do NOT have a USB connection to get the debug log spew, but you are forced to either suck it off the device after it runs or (better) create a WiFi connection with your device to watch the spew scroll by. You eventually learn a bunch of tricks to ease the pain. But in the end, you’ll still need to strap it on to do final testing.
Don’t get me wrong, I love the VR aspects of GearVR – Samsung and Oculus are pushing out a high-quality consumer VR product and the mobility of it blows me away. When I used to be in Developer Relations for Intel, I had to tell my in-laws that I went to game companies and made the game code better. That’s easier to understand than optimizing rendering pipeline operations, reducing the number of samplers, ruthless culling, optimizing cache line alignment, or multi-threading an rendering engine. Pretty much all my in-laws now know I produce “Virtual Reality Experiences” quickly followed by a GearVR demo. The get it right away. It’s an awesome platform for mobile VR (and regular video entertainment and games as well). Did I mention that developing for it is a real pain?
So one of the inevitable steps of development for GearVR is uploading the APK to the device. Now when we had a huge video file, we were smart and just copied it to the phone and loaded in programmatically, not making it part of the APK till the very end. But eventually you need to turn off all the dev. shortcuts and start testing the entire APK, in the near final form. Building & uploading time becomes critical, especially at 3am.
One thing we did was try to choose the devices that could upload the fastest. It turns out that, while their GPU power was slow, if you were interested in how things behaved and looked, and not how they performed, we could get away with using an S5 “Moonlight” and running it in USB3 mode.
I did some performance testing and here’s a graph of relative performance. Note that prior to S6, there could be some hardware (incl. GPU) variations that would give wildly varying performance, including upload speeds. (Only one variant of the Note 4 was tested) So if you end up in the test-edit-upload-test cycle, you might find you can save yourself some time and frustration by trying to optimize upload speeds to the testing devices.