OpenVR Loader initializes regardless of Unity XR "Initialize XR on Startup" option. #80
Comments
|
Maybe you're running SteamVR related scripts that are triggering Unity XR? Try setting an empty scene as your startup scene and see if you encounter the same issue. |
|
I created an empty scene and changed my build script to reference only that scene. Opening a new instance still causes the first instance to close. I'm trying to get a build going with minimal managed/native plugins to see if it's something in one of those causing it to kick off, but the logs don't make it look like anything, and the close seems "graceful". |
|
I added a script to print out my XRSettings in an |
|
Hmm, and just to check your Player Settings -> Resolution -> Force Single Instance setting is not checked, right? |
|
Affirmative, along with allowing run in background.
|
|
I've set up the scaffolding of an empty project to get a minimum reproducible example. Ran into a small issue with that, but that's okay! I imported the SteamVR Package which brought along the OpenVR plugin, and configured the project like mine: Player Settings
XR Plug-in Management
SteamVR_Resources/Resources/SteamVR_Settings.asset
There is also a small script, I've included a build of the project, as well as the project itself. You can see the issue by running one instance of the build, wait for it to open, then starting a second instance. The first instance will close. Github wasn't a fan of a 100MB zip file, so I've instead uploaded it here. What else should I take a look at? Thanks for the help so far! |
|
Good morning! Alright, I'm back with what seems to be a workaround for my case here at the moment! I'm writing this while my project is building with the full scenes, but this worked for me using the empty scene. In my build script, for my "viewer" side of my application, I'm attempting to set the loaders to an empty list, like so: public static bool BuildViewer()
{
var bpo = GetDefaultBuildOptions();
bpo.scenes = new[] { "Assets/viewer.unity" };
bpo.locationPathName = ModifyLocationPathName(bpo.locationPathName, "PROJECT_viewer", "viewer");
// hold on to current XR settings
bool xrEnabled = XRSettings.enabled;
bool xrInitManagerOnStart = XRGeneralSettings.Instance.InitManagerOnStart;
var managerLoaders = new List<XRLoader>(XRGeneralSettings.Instance.Manager.activeLoaders);
var assignedSettingsLoaders = new List<XRLoader>(XRGeneralSettings.Instance.AssignedSettings.activeLoaders);
// set viewer specific XR settings
XRSettings.enabled = false;
XRGeneralSettings.Instance.InitManagerOnStart = false;
XRGeneralSettings.Instance.Manager.TrySetLoaders(new List<XRLoader>());
XRGeneralSettings.Instance.AssignedSettings.TrySetLoaders(new List<XRLoader>());
// do the build
bool buildResult = Build(bpo);
// return the loaders to their previous configuration
XRSettings.enabled = xrEnabled;
XRGeneralSettings.Instance.InitManagerOnStart = xrInitManagerOnStart;
XRGeneralSettings.Instance.Manager.TrySetLoaders(managerLoaders);
XRGeneralSettings.Instance.AssignedSettings.TrySetLoaders(assignedSettingsLoaders);
return buildResult;
}I'm doing it to both // class XRGeneralSettings
public XRManagerSettings Manager
{
get => this.m_LoaderManagerInstance;
set => this.m_LoaderManagerInstance = value;
}
public XRManagerSettings AssignedSettings
{
get => this.m_LoaderManagerInstance;
set => this.m_LoaderManagerInstance = value;
}But I figure best to just cover my bases. Anyways, now when I run my 'viewer', which is what I don't want to have any XR enabled, the first lines of the output log now look like this: Most notably, I think is this line before the subsystems: So it still even seems to be trying to load XRSDKOpenVR, but because it fails, the behavior is what I wanted! But perhaps that provides a clue as to where the "loading regardless of the init on startup" issue is coming from? One more side note that might help us find the source. I also have the VIU in this project. Once after building with "Initialize XR on Startup" disabled, and "OpenVR Loader" unchecked, it prompted me to turn VR back on like so:
I clicked "Use recommended (True)". It re-enabled the "OpenVR Loader" checkbox in the XR Plug-in Management section, but still left "Initialize XR on Startup" disabled. So it was pleased enough to think Virtual Reality was enabled regardless of that checkbox too! |
|
I second this issue as it's still persistent in 1.1.4. I have a solution and can do a PR but I want to make sure this is the same issue. @nitz does this only happen to you in a build? For me it didn't auto-initialize in-editor but in a build it would always auto-initialize and the SteamVR window would pop up. |
|
I was only testing it in builds. My development machine isn't the same machine I typically use for testing, so I wasn't investigating it in the editor at all. I'm not in this particular project this week but can check sometime next week! |
|
@nitz I posted a PR for this that possibly fixes it. If you have time to test check out that request and if it solves your issue and please leave a comment on your results. Thanks! |
|
@Verex I had this exact same issue and your modifications definitely helped me with it, although now I'm having a critical error whenever I start SteamVR, although that may be completely unrelated, so really appreciate that pull request, you're a savior! |
Hello!
I've been in the process of moving from a much older version of OVR/SteamVR to the new Unity XR Plug-in system. Most things have been pretty straight forward, but with this project I've hit a blocking issue: this application needs to be running two instances.
Currently, regardless of build settings, opening a second instance causes the first to immediately quit, as it has initialized the VR hardware. (I'm using a Vive Pro Eye at the moment, not sure if that matters.)
Previously we were able to work around this issue by building the project twice: once with "VR Enabled" checked and once with "VR Enabled" unchecked. That would allow us to start one of the instance where it was enabled, and then any other number of instances with the disabled one. I've tried scripting the adjustment of
XRGeneralSettings.Instance.InitManagerOnStartto bothtrueandfalsefor building two instances of the player too, but it doesn't seem to make a difference there either.I'm attempting to replicate that now, but it seems the OpenVR Loader plugin completely ignores the "Initialize XR on Startup" option. Regardless of that setting, OpenVR seems to initialize and open the hardware, because opening another instance always causes the first to close.
Ideally I'd like to be able to have just a single build, and then either launch to a "chooser" scene that would allow me to go the VR route or the non-VR route, but it seems no solution is working at the moment, or I'm misunderstanding the systems.
Is there something I'm missing or doing wrong, or is this a defect?
Below are some screenshots of the settings I'm trying.
Here is the tiny build script I use to build two copies of the player build script gist.
The text was updated successfully, but these errors were encountered: