Allow SteamVR Unity Plugin to run in "Standalone" mode without Unity XR enabled

[dantman]

Standalone mode is primarily intended for SteamVR overlays where it is undesirable for Unity to initialize itself as a VR application and render a scene.

In order to run standalone:

• autoEnableVR must be disabled in SteamVR_Settings
• "Virtual Reality Supported" must be disabled in Unity's project settings
• To initialize an overlay you must create a behaviour that calls SteamVR.InitializeStandalone(EVRApplicationType.VRApplication_Overlay); to enable SteamVR functionality
• If you use SteamVR scripts that initialize SteamVR on Awake you may get initialization warnings if they run before your initialize behaviour
• Since Unity's XR support is disabled you of course need to interact with the OpenVR.overlay directly in your own scripts

Implements most of the functionality required by #108

[gnarlyman]

Thank you for creating this patch. I tried it and it works.

I hope Valve decides to merge it in. The SteamVR Unity Plugin is too restrictive in its current state.

I'm working on an overlay project as well. I started with basic openvr api calls. I used other overlay projects to help figure things out. OpenVR is great, but its also pretty low level. A higher level api would be nice, and that's what SteamVR is.

But SteamVR is not friendly to overlay developers, or anyone who wants to use SteamVR without Unity's VR Support enabled. When VR support is enabled, Unity takes over and does things I don't want. It kicks out other running VR apps, it hooks up the main camera to the hmd. Sure this is great if you are 90% of developers who just want to make a VR game. What about the rest?

With this patch I was able to get SteamVR Input to work, and I was able to add certain SteamVR components to gameobjects and enable tracking of the contoller and hmd poses. This means I don't need to interface directly with OpenVR, now I can utilize all the SteamVR components that Valve spent so much time working on.

Thank you! And +1 to merging this patch!

[dantman]

Please consider merging this as at least an experimental option. Or review it and let me know what other way I should implement the API or what else should be added.

Currently by leaving this as just a PR, I have to re-merge the standalone tweaks every time a new update I need is released. And because this is just a PR, the rare time that a change to the plugin causes an issue in overlay mode there is no place to report an issue, no easy way to fix it without increasing the likelihood of merge conflicts, and no place to discuss api improvements to help the plugin fit in with overlay usage.

On that topic, while this PR's changes still work for enabling overlays made with the plugin to function. A recent change did create a new quirk in the plugin that causes issues. Version 2.3b (715bba3) added OpenVR.Compositor.SetTrackingSpace to SteamVR_Action_Pose.SetTrackingUniverseOrigin, which SteamVR_Input calls as it initializes. As a result when an overlay starts now the tracking universe changes (you can understand the issue if your overlay is set to seated and you start it in SteamVR Home, then SteamVR Home's tracking space changes from Standing to Seated). So now it's worth considering what method to use for disabling that for overlay applications (right now I'm just commenting it out).

And related but not required, the SteamVR_Action_Pose system seems to work by using an internal universeOrigin variable based on the SteamVR_Settings tracking origin setting; while the OpenVR Input API actually takes an explicit tracking universe when asking for poses, independent of whatever the current tracking universe is. It may be worth adding a way to get the tracking universe an action/inputSource has set so SteamVR_Action_Pose Change events can be written independently of the tracking space setting.

CC: @zite

[bioshazard]

3 years later and still doesn't support overlay as a first class solution?