GvrCardboardHelpers.SetViewerProfile

[tedtheodore]

I have been trying for some time to set a certain viewer as the default for an app I'm creating.

I have the raw URL of the viewer profile which I call as soon as the cardboard device is loaded. I understand this wont work if another viewer has already been set up, but I have been testing on devices which haven't had another viewer set, without any luck.

This is testing builds from Unity 2017.2.0f3

I've seen that there is GvrView.updateGvrViewerParams which can be used to change the settings on a per run basis, which would be ok, but doesn't seem to be surfaced in the unity api.

Is there ANY other way around this without hacking the code like mad. It's also hard to TRULY know if there is any issue, as the output doesn't give much back past the boolean, which I can get to actually return false from the internal gvr_set_default_viewer_profile() call. However, i'm not sure of all the reasons that would return false here.

[tedtheodore]

Update:
I'm now getting this to work consistently on iOS by waiting until XRSettings.enabled == true, before trying to call GvrCardboardHelpers.SetViewerProfile.

I also modified GvrCardboardHelpers.cs to use gvr_refresh_viewer_profile from the DLL (as this was causing another bug where the view was using default parameters, even though the settings had the custom viewer set).

Doing these same steps on Android however have not been successful. I've tried on an older device that doesn't come with VR Settings (a Galaxy Note 5) and a newer that does (Samsung Galaxy S8), neither do anything when calling GvrCardboardHelpers.SetViewerProfile. Both devices have been factory reset to ensure no profile previously loaded.

[tedtheodore]

I've tried many attempts over the past week now with no success. This really should be looked at for Android. My app has read/write permissions as does Google VR, and Cardboard app for Daydream phones and still, calling GvrCardboardHelpers.SetViewerProfile does nothing. If I manually put current_device_params into /Cardboard/ onto the device, as soon as my app has read permission, the params are loaded correctly, but this is obviously not plausible in production.

[tedtheodore]

I've just found after a device reset, if the phone DOES NOT yet have Google VR services installed, and an attempt is made to call GvrCardboardHelpers.SetViewerProfile the parameters WILL be set correctly. Then if Google VR Services is installed after this point, the parameters will then be lost

[tedtheodore]

I have narrowed this down to the sole fact that Google VR Services doesnt have storage permissions. If this is manually given, the GvrCardboardHelpers.SetViewerProfile works fine. If Google VR Services prompts to give storage permissions by attempting to open the QR code reader, the call also works.

I attempted to use GvrPermissionsRequester to try to get the permission when I start my app but this fails and seems to be Daydream only?

Would be good to have a way to fire the permission request, or maybe if the params aren't stored on the SDCard?

[Daniel-Dobson]

Would be great to hear more about solutions to this, and any related knowledge.

[tedtheodore]

I've noticed a user had the exact same problem as I'm facing in googlevr/gvr-android-sdk#490 It seemed to go basically unresolved in December but since has been given a feature request tag in March... So fingers crossed!

[Daniel-Dobson]

This is great news!

[jdduke]

Hi @tedtheodore, is there any chance you can add some additional context for the problem you're trying to solve? That is, more about the need to set the default viewer profile? We're looking for additional reasons to continue supporting this API, which we had been planning to deprecate.

Would it be sufficient to simply override the session viewer profile, rather than the global viewer profile?

[tedtheodore]

The context for me is entirely the same as googlevr/gvr-android-sdk#490. We have our own hardware and app, and the intention is for our users to use our hardware without having to pair the viewer themselves, at the same time adhering to the Google standard of not strong arming the user into it, eg, if they have paired a viewer previously, then don't set by default.

For me, a session viewer profile would be fine, as long as the gvr_get_viewer_vendor and gvr_get_viewer_model calls are surfaced for the Unity SDK or some other call so that we can test if the viewer is/isn't a cardboard default. We would like to be flexible so that a VR "power user" can just use their own viewer without our intervention.

[Adam-VisualVocal]

+1. I'm the OP from issue #490 and we have a very similar use case as @tedtheodore. His proposed solution would work for us as well. Thanks.

[Ethan-VisualVocal]

For me, a session viewer profile would be fine, as long as the gvr_get_viewer_vendor and gvr_get_viewer_model calls are surfaced for the Unity SDK or some other call so that we can test if the viewer is/isn't a cardboard default.

@jdduke tedtheodore's proposal above would be great. A lot of our users just take the cardboard viewers we give them and expect them to work with our cross-platform Unity app. The idea that they might need to configure their phone to make VR look correct with the viewer is something that never occurs to them.

We don't need or even want to influence how other apps are configured, just so long as the "session viewer profile" can be reliably queried and set prior to enabling VR in Unity. Our ideal scenario would be this:

1. Reliably query the configured viewer profile prior to enabling VR.
2. Warn user if they don't have our specific VR viewer configured (because 9.99/10 that's what they have) before entering VR and allow them to optionally press a single button to use our VR viewer config (not scan a QR code)
3. Reliably apply a custom viewer configuration profile prior to enabling VR.
4. Ultimately allow a user to view VR with whatever they want configured.

It may also be worth noting that ours is a "hybrid app" where we do a lot of enabling/disabling VR during an app use session, so ideally whatever changes to this API you make, they play nice with the hybrid scenario.

I understand Daydream tries to solve this problem with the auto-configuring, but we're a cross-platform solution. With that in mind, the more consistent the APIs & behavior between Android and iOS in the Unity SDK, the better.

[jdduke]

Thanks for the feedback. We'll look into improving support for this in the next release. I'll share more details as we decide on concrete changes to the API and/or Google VR Services.

[chaosemer]

I believe we fixed this recently. Please reopen if you still have the issue.

[tedtheodore]

Thanks. What approach was taken in the end? I cant see it in the change log anywhere so not sure what calls we would use to do this.