What is the timeframe of the technical preview going live with native Daydream Controller API?

I am interested in knowing when the technical preview will be available in 5.5 and when native Daydream controller will be included that does not require the Google Unity SDK package that creates a ton of ancillary problems. Also, excuse my ignorance if it exists, but I cannot find it. Are there any Unity API libraries that are specific to Daydream in the technical preview? Or will a new version of the Google VR SDK package be tailored for use of Daydream features in the native Daydream Unity build?

 

Adding the Google VR Unity Package seems to conflict with GVR9 causing hangs when coming out of 'Game' mode for me (could be GVR9 since I can't even create an Android build now and had fall back to GVR8). I also feel there seems to be crossover in the native Android Daydream GVR9 and the Google VR Unity package that has caused headaches when used together (see other posts) leading to one developer recompiling without the GvrViewer calls.

NOTE: It appears the controller works just fine in GVR8 with not hangs leaving Game mode.

Update: Spoke too soon. The GvrController demo worked once, then when switching to WiFi it would not respond and wouldn't let me leave Game mode. I had to kill the Unity Editor process and reload Unity 3D.

 

I'll add a few details, but first I want to apologize if any of this is a bit confusing. We're in the middle of migrating the plugin and our users from a pre-native to post-native integration world and things are always messy during transitions. Anyway....

The GVR Unity SDK 1.0.1 is intended for use with the native integrations. However, when you are using the Technical Preview, you should only use the Daydream controller related APIs and classes, as things like GvrViewer and StereoController are legacies of the pre-native integration days. These legacy classes should have no effect when the native integration is active, but you can safely remove them if you suspect there are bugs.

It sounds like you are also using the controller emulator in the editor. With that we highly recommend USB connections as the Wifi route can be flakey.

 

Thanks, for some reason two phones using the Daydream emulator is flakey in USB, but work fine in WiFi with the proper IP address used in the script. For whatever reason I can do ADB USB and see the device, and log shows the ADB port opening but being refused. Currently I am okay with something working since I trying to write code to for GVRgraveyard to utilize the Daydream controller by this weekend. By the way if you are interested in trying it here is APK download that will work in both A6 and A7 Cardboard or Daydream using on GVR8, sadly GVR9 (see my other post) errors during build. I have already submitted a version to Google Daydream, and want to show what you can do with the 'Drumpf Troll"

 

Please excuse me if I've overlooked some documentation somewhere, but all of this is *deeply* confusing. Can you define these terms? By "native" do you mean Java on Android as opposed to using Unity? Or do you mean "native to Unity"? Or do you mean native as in unmanaged code like using the NDK on Android?

It's a startling revelation that classes like GvrViewer are already "legacy" since those comprise the entirety of what *appears* to be the official documentation for developers on Daydream at https://developers.google.com/vr/unity/reference/. Is that correct place for us to be reading or is that young site itself already "legacy" as well?

I'm experiencing some magic behavior when I deploy from the Unity technical preview to device right now - there is somehow headtracking already even though I haven't added a GvrViewer component or anything else to the scene. How does this work and what does it assume and what are its limitations?

Is there a better or more comprehensive place for us to learn about what the intended development process for this thing actually is?

Thanks very much and I apologize again if all of this is already laid out somewhere. If that's the case, please direct me to it and I'll share with others.

Thanks!

 

@nathanmartz if you could shine any light on the above questions that would be much appreciated - thanks!

 

GVRArmModel also seems to rely on the existence of GVRViewer. Is there a replacement for the arm model code if GVRViewer is truly considered legacy?

 

Bump; any news about the questions raised above in this topic? Thanks.