Support overlay mode?

[dantman]

Is Valve willing to support using the SteamVR Unity Plugin for creating SteamVR Overlays?

After experimenting a bit and digging into the code. It appears as if nearly everything needed to make overlays is available in the plugin. There's enough here it would likely be more productive to tweak the plugin to support overlays, than to implement overlays from scratch using openvr_api.

From what I can tell, the primary thing stopping overlays built in Unity with this plugin from being viable is that when Unity's XR handling – which initializes itself as a scene renderer – is disabled so you can initialize your app as overlay-only. The SteamVR class decides it cannot function and never creates an instance. And as a result the majority of the plugin just simply fails on SteamVR.instance. Even when the code is just doing something as simple as checking the textureType. Even when the code doesn't need UnityXR's rendering. And even though the plugin already appears to do most of the pose tracking, etc... itself without UnityXR.

[alexbu92]

Any updates on this? We really just need an option under the native openvr support settings to set what kind of EVRApplicationType type we want OpenVR to be initialized as. Right now it seems to be hardcoded as VRApplication_Scene, we just need a dropdown to be able to change that to whatever application type we need.

[zite]

I'll add that to the steamvr settings object.

[zite]

Actually it looks like this is done at the unity level now, we may have to roll this into a unity 2019 xr sdk thing. I'll look into it further.

[dantman]

The initialization is done by Unity, if you have OpenVR turned on in Unity. However the Unity XR stuff does not do overlays and IMHO just about everything that is done in Unity XR is not needed for building overlays.

IMHO building overlays should be done by using the SteamVR Plugin, turning Unity's VR handling off, calling the OpenVR Initialization with an overlay type yourself, and setting a setting that tells the SteamVR Plugin NOT to disable itself when it sees that the Unity XR code is not running.

[dantman]

I'm already building an overlay using the SteamVR Plugin:
https://github.com/dantman/elite-vr-cockpit

I have the Unity XR stuff disabled. I init the overlay stuff myself. And I copy a few parts of the SteamVR plugin like the EventLoop for which the built-in one doesn't run because the StreamVR Plugin disabled itself. The one caveat is there are some places like SteamVR Input that I can't copy things to get working because the references to the SteamVR class assuming that it's running are too hardcoded.

The latter two things should not be required. The plugin already has a built in event loop and APIs like the Input API also seem to work in an overlay. The only problem is that when the SteamVR class that everything depends on starts up and sees that Unity XR is not running (because custom overlay code is running instead) and then shuts down completely and turns very simple calls to non-UnityXR things like getting the SteamVR Plugin's own settings values, into fatal errors. And does not allow things like the event loop to start up (which does not actually rely on Unity XR).

[fragmentvr-dev]

Yeah, same here. The SteamVR Unity Plugin is unusable without heavy modification, and even then only parts can be utilized, not to mention that it becomes impossible to update it when updates come around.

[bddckr]

It looks like some parts of the plugin can be called independently and will then initialize OpenVR if needed (most often as the Utility app type) and calls Shutdown once done.

I would like to see a single place handling the automatic initialization and there being a way to disable it. If the same method it calls to initialize is public API that would be even better - this way users don't have to reinvent the wheel in case they want to delay turning on VR or support non-VR gameplay and want to allow switching at runtime.

[dantman]

I can confirm there is very little in the plugin that actually references the Unity XR runtime. UnityXR is of course relied on to handle rendering scenes, but that functionality is not needed/desired when running an overlay.

• SteamVR.cs just checks XRSettings to see if OpenVR support is setup.
• SteamVR_Behaviour.cs uses XRSettings/XRDevice loading and XRSettings.enabled = true; only when you initialize with forceUnityVRMode = true.
• SteamVR_Camera.cs uses XRSettings to get the eyeTextureResolutionScale/renderScale. However you only use SteamVR_Camera when you are using UnityXR to run a game, not using it for an overlay.

I got SteamVR to startup by adding an extra standalone mode that calls OpenVR.Initialize and disables the XRSettings checks. And of course turning off autoEnableVR, turning off Unity XR, including the OpenVR dll myself. I'll verify how much I have working later.