OpenXR Runtime in builds problem when publishing to viveport

[simeon]

I want to publish a VR app at the viveport made with Unity 2020.3.15 + openXR. Today it was rejected. I tested it on three different Headsets (wmr, oculus, htc) and everything worked fine. In the rejection mail they said, that "there's no image in the VR Headset." They also send there player log:

At the beginning of the player.log I see the lines:

[XR] [17744] [17:39:44.530][Info ] ==== OpenXR Support Details ====
[XR] [17744] [17:39:44.530][Info ] OpenXR Runtime:
[XR] [17744] [17:39:44.530][Info ] UNKNOWN COMPANY, which is not a Unity supported partner

We all know, that the third line should be something like:

Valve / Microsoft / Oculus

So it seems, that the system, they use, has not an OpenXR Runtime set. 

On my machines this is not a problem, because I have three runtimes and set it to my prefered. Mostly Steam. But it seams, that a SteamVR installation alone with viveport does not set itself as OpenXR runtime.

In unity there is a dropdown, which runtime the editor should use, but this is not used in the build. I also posted this problem in the unity forum - but I also want to try to get some useful infos here.

I could imagine, that the viveport desktop should check, if there is an active openXR Runtime and if not, should set it to SteamVR. Because they work together and viveport should also support openXR builded apps, right?

[C.T.]

Who was your contact, let me see how to check with them?

[simeon]

Thank you. Clement Lam was my contact.

[simeon]

Any news on this topic?

The story of this app:
This app was developed for the oculus go. Because oculus stopped support in december 2020 and due to corona we didn't manage to release it.

We ported it to the quest. After we submit it to the app lab we waited for 6 weeks or so, before they denied it. The reason: it's a 3dof. (on purpose and usage of stereo renderings)

So we ported to it to openXR to be independent of a headset.

Just to give the background that we're a bit desperate, if we ever can show it to someone...

 

 

[simeon]

Someone in the unity forum wrote:

"The active runtime is just a JSON entry in the registry that the OpenXR loader uses. You could write your own logic to check the registry and make sure steam is set and if not tell the user to set steam active (or set it active yourself if you want to change the registry)."

Maybe this could something the viveport desktop app could check, if a user downloads an app, which uses an app with OpenXR flag and then give the user a button, which changes the runtime to steamVR...

[C.T.]

We've requested developer relation team to take a look, give us a little more time for it. Thanks

[dario]

Hi @simeon

 

For the Vive Cosmos OpenXR runtime you should be ok - for the SteamVR OpenXR runtime you need to have installed SteamVR (preferably the latest version) to get OpenXR support there. For both runtimes, from the SteamVR console or from the Vive console, you can specify which runtime is the default (on Windows it checks a registry setting). For SteamVR you can check which runtime is the default or set SteamVR as the default from the Developer Settings in the Steamvr console.

 

 

 

[simeon]

On 8/20/2021 at 7:42 PM, Dario said:

Hi @simeon

For the Vive Cosmos OpenXR runtime you should be ok - for the SteamVR OpenXR runtime you need to have installed SteamVR (preferably the latest version) to get OpenXR support there. For both runtimes, from the SteamVR console or from the Vive console, you can specify which runtime is the default (on Windows it checks a registry setting). For SteamVR you can check which runtime is the default or set SteamVR as the default from the Developer Settings in the Steamvr console.

We're not talking about my runtime problems, but the users which I can't control (e.g. when pusblishing via viveport) -> See my first post. Thank you for trying to help.

[dario]

Ok got it:  You meant: users e.g. when installing Viveport (users not publishing - but just using Viveport and only when never having installed SteamVR before).

So you're referencing the embedded/bundled Steamvr with Viveport - even though that steamVR should be able to update itself (and set the default openxr as itself).  So potentially the window is small for when a user who doesn't update would see the issue (a subset of a subset).

In anycase now that it's clear, I'll have somone on the Viveport forum look into this issue.

 

[simeon]

4 hours ago, Dario said:

So potentially the window is small for when a user who doesn't update would see the issue (a subset of a subset).

I also hope, that only few people have no active openXR runtime, but in my case (see first post) the viveport app reviewer obviously had no active runtime enabled, can't see an image in VR and rejected the app.

Thank you for caring. You saw, that @C.T. also has this on scope?