Whats the best SDK for the Google Cardboard Headsets?

Hi Guys,

I got a google cardboard Colorcross headset and I was going to start playing a bit with VR.
Can someone recommend me which SDK seems to be the most robust at the moment?

As I have seen, I can either use the official Google Cardboard SDK or the Dive SDK.

If I decide to make a game, I would want it to run on both IOS and Android as both support the Cardboard Headsets.
Some forums said that the official Google SDK handles orientation a bit better than the Dive SDK but I haven't found if the Google SDK supports IOS as well. Does it?

It would be awesome if a demo made for the Google Cardboard Headsets could also be played on the Oculus Rift. But I guess for that I will have to develop a version with the Cardboard SDK and another with the Oculus SDK. Have anyone tried developing just with the Oculus SDK and running the demo on the Cardboard Headset? The Gear VR is pretty much a glorified Cardboard VR as far as I understood so the Oculus Mobile SDK *may* work!?! Have any one tried that?

Can anyone recommend me what SDK or tools you have found the most useful?

Thanks!
Frank

 

Didnt found any SDK that worked fine in Unity5+LG G3 combination.

 

I'm using Dive SDK. haven't tested it on iOS yet but on my android it runs very well.

I was using google's sdk with unity 4.6 but ever since unity 5 was released it stopped working for me (video is garbled). and google noted themselves that the sdk was not QAed on Unity 5 yet.

There is also Fibrum SDK which i have not tested yet. The apps that they make support iOS so i'm assuming their SDK does too. and in their last release about a week ago they sayed they were able to solve the drift problem that all other SDK's have. I plan to try and make the switch sometime soon.

As far as Oculus SDK - you can't use the rift's SDK because its using the rift's sensors and not the phone's sensors.
And in case you ment the Gear VR SDK - as far as i know its "locked" to be used only on Nexus devices that are compatible with Gear VR.

Hope this helps.

 

Using the Dive sdk i have a weird shifting problem with the camera.

However the google SDK works with unity 5. You have to enable the Development Build option in the Build dialog for the moment.
See more info : https://developers.google.com/cardboard/unity/release-notes

Hope this help

 

Good to know google has a new release that fixes things. It wasn't there a few days ago.
But still with no support for iOS they are at a disadvantage

 

Just thought i'd give an update,
Google cardboard still doesnt work on my phone with unity 5 (even with development beuild enabled), and other sdk's mentioned suffer from drifting issues.

I was able to find this Zeiss VR One SDK which seems to work for me & solve the drifting issues almost perfectly.
https://bitbucket.org/vrone/unity3d/downloads

 

Got the google sdk package running fine ... except for the fps that drop to like 40 -20 fps, but maybe that just me phone.

 

Googles current sdk will give you many complaint from LG G3 users, which, with its 2k screen, is perfect for VR. Since googles cardboard sdk is realy jumpy on the g3. For performance, its probably your phone, which one are u using?

 

Samsung Galaxy S4

 

Weird, shouldnt be a problem. How complexe is your scene?

 

That 40 -20 fps is from a completely empty Test scene (Just the sdk camera setup).
Just two cameras has 60 fps +.
I if i have a very mobile optimized scene the fps is most of the time at 20 -27 fps.
The Same Scene two cameras has 60 - 62 fps(Probably capped by the device refreshrate).
Maybe the tracking / distortion correction plugin that the sdk uses cause the slowdown.
Im not sure how to debug that properly on the device, i tried the Adreno Profiler but it did not like to find the adb or the device to that is not use.

 

The official SDK mostly works well for me with the latest U5 on Android, but there may be a bug with deferred rendering I'm trying to track down. It seems to be a work in progress from Google, so hopefully its kinks get ironed out over time.

 

I've been using Dive SDK, VrAse SDK and Google Cardboard SDK. Taking into account the latest update of Google SDK (0.5) with iOS support I find it to be the best right now.

If you have found something better, please let me know!

 

@4ringz, for deferred rendering, try turning off the Direct Render option in the StereoController component.

 

Hi Dolims!
You saved my life! I was having major problems with my cardboard app, it runs on almost all devices but not on a Samsung Galaxy III mini. By turning of the Direct Render option it finally worked Thanks man!
Bart

 

This is a bit late (apx a year) but I am using Google Cardboard SDK and have drifting problem in my app. If I move my head a bit faster, I can see that camera is moving a bit late. I believe this is can be fixed by applying certain configurations/settings like @dolims suggested about Direct Render option. Can anyone tell me what are the settings of GVR Viewer, GVR Head and Stereo Controller to achieve drift-less camera movement with head.

Please help me with this before I jump in from of Virgin Trains out of frustration.

Thanks

 

The latency (lag) issue is different from drift (which is a bias in the gyro sensor). It is related to your app's performance on your particular phone. If you are getting 30fps, for instance, the latency is going to be pretty bad. One of the biggest factors involved is how many pixels are hit. You can lower the resolution of the intermediate framebuffer (StereoScreen), and also avoid using Image Effects. Shadows take a bite too. Scene complexity needs to be kept down -- minimize draw calls, don't let the vertex count get too high, and use fewer textures. Basically everything that would help in a non-VR game, but the penalty is worse in stereo.

In the not too distant future, Unity will have support for Cardboard and Daydream (collectively, "GoogleVR") built in to Unity, and therefore GoogleVR will be using Unity's VR optimizations. So some of these issues may be alleviated a bit when that happens. The above suggestions for performance optimization will still apply -- you'll just have a bit more breathing room.