Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback camera does not render to desktop window #41

Closed
scolarod opened this issue Sep 1, 2020 · 5 comments
Closed

Fallback camera does not render to desktop window #41

scolarod opened this issue Sep 1, 2020 · 5 comments
Assignees
Labels
fixed in next version This has been fixed and will need a test when the next version comes out.

Comments

@scolarod
Copy link

scolarod commented Sep 1, 2020

When running Unity game with no HMD, the fallback camera does not render to the main display. I have tested this in my game and the interactions sample in both the editor and standalone build. When selecting the fallback camera in the editor, the camera preview and the WASD key movement look correct.

Unity 2020.1.3f1 (standard render pipeline)
OpenVR XR Plugin 1.0.1
SteamVR Plugin 2.6.1 (also tried 2.6.0.b4)

I realize this is probably a low priority but the 2D fallback view is extremely useful for demoing to clients that may not have access to a HMD.

@1runeberg 1runeberg self-assigned this Sep 1, 2020
@joejo-unity
Copy link

joejo-unity commented Sep 17, 2020

There are 2 problems here:

  1. XR Plug-in Management expect Initialize to succeed or fail and then uses that to fallback. Success in init means management assumes Start will succeed and we don't fallback to anything else after that. You can find relevant information on that here.
  2. If anything fails after creating any subsystems, then the created subsystems should be destroyed. In the case of OpenVR that seem to be a must otherwise the screen stays black.

Here is a diff that should resolve this (sorry for formatting, github didn't like the paste):

index 4ed79eb..943f753 100644
--- a/com.valve.openvr/Runtime/OpenVRLoader.cs
+++ b/com.valve.openvr/Runtime/OpenVRLoader.cs
@@ -185,6 +185,14 @@ namespace Unity.XR.OpenVR
 #endif
             
             CreateSubsystem<XRDisplaySubsystemDescriptor, XRDisplaySubsystem>(s_DisplaySubsystemDescriptors, "OpenVR Display");

+            EVRInitError result = GetInitializationResult();
+            if (result != EVRInitError.None)
+            {
+                DestroySubsystem<XRDisplaySubsystem>();
+                Debug.LogError("<b>[OpenVR]</b> Could not initialize OpenVR. Error code: " + result.ToString());
+                return false;
+            }
+
             CreateSubsystem<XRInputSubsystemDescriptor, XRInputSubsystem>(s_InputSubsystemDescriptors, "OpenVR Input");
 
             OpenVREvents.Initialize();

@@ -223,13 +230,7 @@ namespace Unity.XR.OpenVR
             StartSubsystem<XRDisplaySubsystem>();
             StartSubsystem<XRInputSubsystem>();
 
-            EVRInitError result = GetInitializationResult();
 
-            if (result != EVRInitError.None)
-            {
-                Debug.LogError("<b>[OpenVR]</b> Could not initialize OpenVR. Error code: " + result.ToString());
-                return false;
-            }
 
 #if !UNITY_METRO
             try```

@1runeberg
Copy link
Contributor

Thanks @joejo-unity !

Currently internally testing. But pushed in this branch, the updated latest headers you provided (xx19.4) and fix for this here:
https://github.com/ValveSoftware/unity-xr-plugin/tree/dev/UpdatedHeaders

@joejo-unity
Copy link

joejo-unity commented Sep 19, 2020 via email

@1runeberg 1runeberg added the fixed in next version This has been fixed and will need a test when the next version comes out. label Oct 20, 2020
@zite
Copy link
Collaborator

zite commented Dec 11, 2020

Hi, thanks for reporting the issue. This should be fixed in the latest release. You're welcome to give it a try and let us know if it solves the problem.
https://github.com/ValveSoftware/unity-xr-plugin/releases/tag/v1.1.1b

@kisak-valve
Copy link
Member

Closing per the last comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed in next version This has been fixed and will need a test when the next version comes out.
Projects
None yet
Development

No branches or pull requests

5 participants