Cross-platform VR development: GearVR and Daydream

Unity Engine
21

Oh, thanks,

I assumed that he had already figured out a way to do this.

And as of now I’ve taken the approach suggested by you, I’ve created an Editor Build script and have created two AndroidManifest.xml files(one for daydream and one for GearVR),they are in all aspects similar, just that the ‘activity’ section is modified depending on the platform.These are placed in my own folder (not of type Plugins) and will get swapped and put into the Asets/Plugins/Android folder before the build process.

[if anyone’s wanting to do this, have a look at OVR/Editor/OVRManifestPreprocessor.cs to give you solid start
(comes with the Oculus Plugin)]

To get the starting point for the AndroidManifest.xml (To get the initial basic manifest, just delete the Assets/Plugins/Android/AndroidManifest.xml if present, and let it build for Daydream, create a buiild, then without closeing unity head over to the project root /Temp/StagingArea/AndroidManifest.xml and copy it)

Only pain would be manually changing the Version Code and Number for each update(the change will have to be made in both the custom manifest scripts), wish there was a way to automate this too.

After the manifest files are swapped out I run the Build Player Pipeline as shown here.

Tip: Use this to avoid having to set the scenes in build manually

buildPlayerOptions.scenes = EditorBuildSettingsScene.GetActiveSceneList(EditorBuildSettings.scenes);

Any suggestions for improvements are most welcome.

1 Like
22

Obviously it would take some work but you could via editor script modify the manifest text for version code and number (didn’t do this but you could certainly read/change/update the file). As far as the scenes go you can via script add the scenes as well if you didn’t want it to be the active list.

1 Like
23

Great info @greggtwep16 @vivalavida , I will use methods as you mention, to force correct manifest, when I come to publish. (have bookmarked this thread).

Thinking more about this: there is no reason for Unity to allow multiple VR SDKs to exist in the XR player settings list. I think Unity should only allow one VR SDK to be selected for any one build process. After all: any derived .apk/.exe will only work on one VR platform. And Unity could then produce a good clean build for each specified target.

Thinking of the future:
Will we get a universal XR API with no need to import stuff?

Here’s my wishlist for unity:

  • We code against one Unity API (XR).
  • We are able to read HMD pose through it.
  • We are able to query any VR input device through it, using some superset API.
  • We write one codebase, choose our build target and press “build”.

The API input interface, hypothetical, might be like:
C#

int iDevices = XR.GetNumInputDevices();

XR.InputDevice oDev = XR.GetInputDevice(0);

bool bYes = oDev.HasTrackingRot();
Quaternion qRot = oDev.GetTrackingRot();

bool bYes = oDev.HasTrackingPos();
vector3 vpos = oDev.GetTrackingPos();

int iJoys = oDev.GetNumJoysticks();
XR.InputDevice.Joystick oJoy = oDev.GetJoystick(0);
vector2 vJoy = oJoy.GetJoystickVal();

int iBtns = oDev.GetNumButtons();
XR.InputDevice.Button oBtn = oDev.GetButton(0);
float fPressed = oBtn.GetPressed();//return 0.0f ... 1.0f (digital or analog);
2 Likes
24

Totally agree - but this is essentially Unity’s business model, the kind of abstraction and simplification they talk about at the beginning of each keynote, so I’m sure they’re on it…

What is less obvious is how platform owners (Google and Oculus here) support Unity’s API standardization effort. Unity wouldn’t have to standardize APIs if platforms coordinated themselves more when they define their APIs.

1 Like
25

Yes, you’re right of course, it will no doubt become unified XR API, I’m just impatient, but very grateful for the already great work done by Unity.

Yes, for full XR (augmented reality also) API internal wiring may become complex, and Unity/VRProviders ought to agree to some standard. I can see that taking some years.

But I’m not sure it’s too big an issue if we consider VR only.
Total information flow required for unified VR only API is:

Input:
Controllers
This is the bulk of the work.
A dynamic super-set class that will handle any input controller setup.
All controllers are just combos of these 4 core input types:

  • 1D input device (digital button / analog trigger)
  • 2D input device (touchpad or stick)
  • 3D tracked pos
  • 3D tracked rot

Any further abstraction can and should be built by community (or VR platform owner) on top of unity XR API using c# script/prefab, i.e. prefabs to drop in working controllers that hook into IK rigs etc.
Hypothetical input API

int iDevices = XR.GetNumInputDevices();

XR.InputDevice oDev = XR.GetInputDevice(0);

bool bYes = oDev.HasTrackingRot();
Quaternion qRot = oDev.GetTrackingRot();

bool bYes = oDev.HasTrackingPos();
vector3 vpos = oDev.GetTrackingPos();

int iJoys = oDev.GetNumJoysticks();
XR.InputDevice.Joystick oJoy = oDev.GetJoystick(0);
vector2 vJoy = oJoy.GetJoystickVal();

int iBtns = oDev.GetNumButtons();
XR.InputDevice.Button oBtn = oDev.GetButton(0);
float fPressed = oBtn.GetPressed();//return 0.0f ... 1.0f (digital or analog);

Output:
Rendering:
Unity already wires engine output to platform spec.
No exposure needed via API to Unity user, no extra work on top of what has already been done.
If a synthetic stereo view is needed in the editor then unity can just synthesize it, having simple lookup for any HMD type selected.

Haptics:
Simple: C#

XR.InputDevice oDev = XR.GetInputDevice(0);
if(oDev.hasHapticOutput)
{
    oDev.DoHapticOutput(fAmplitude, fForSeconds);
}
1 Like
What's the plan with VR input?
26

In Unity 2017.2.0f3 I still get the following log warnings twice per frame. I wonder if this is only because I don’t actually have a Gear VR attached?

ovrp_GetAppHasInputFocus return Failure_NotInitialized

27

Yes, using newer oculus scripts you get that in editor mode. you can comment out the line that generates that log warning spam, double click the log inspector bottom pane to jump to said line in vis studio.

1 Like
28

hi guys, I just wanted to know if due to the most recent unity updates (I’m starting to use 2018.1) did you have any improvement in handling various VR platforms in a single project? any improvement regarding the unified API for everything that @SiliconDroid dreams about?

I want to adapt a project that was originally made for PC with mouse/keyboard, I need to make it work for both Cardboard (or Daydream) and Oculus Rift, meaning that I want to reuse the maximum possible and just make a wrapper or switcher between the gvr api and prefabs and the ovr api and prefabs.

Also I’m aware that, unlike the post above, I want to build to android cardboard/daydream and also to windows oculus rift. So I have to manually change the target platform, but I’m not aware of how complex it is to make both platforms live together in the same project, you talk a lot about gearVR and cardboard, but not PC-OculusRift and cardboard so that’s why I’m asking.

thanks for any answer!

1 Like