Cleaner Scene Switching with RenderManager

[DuFF14]

There are some issues when switching scenes that need to be addressed in Unity, RenderManager, or both. Here are some of the symptoms:

1) When using RenderManager in DirectMode, the Unity-VR-Samples project crashes in the Unity editor when switching scenes.

In a build of the same project, the crash does not occur. There is still a noticeable artifact, usually a vertical line on the display, that shows briefly between switching scenes.

https://github.com/OSVR/Unity-VR-Samples/issues/4

2) When using RenderManager in extended mode, the RenderManager window closes during a scene switch and reopens in a new window. For a short time (less than a second), the desktop is visible in the HMD.

Sounds like there are some issues in CryEngine when using RenderManager in extended mode, which has been tracked down to an issue with repeated init/shutdown in SDL2.dll.

SDL2.dll when we try to use rendermanager with a server configured to run in non-directmode. I investigated this a little bit, and it seems that the cause for the crash is that we are initializing and shutting down the rendermanager several times (the rendermanager gets “refreshed” each time the render resolution changes for example). This causes the rendermanager to call SDL_Init and SDL_Quit each time it gets initialized/shutdown and the SDL doesn’t seem to like this.

https://github.com/CRYTEK-CRYENGINE/CRYENGINE

I'm not sure if that is related to https://github.com/sensics/OSVR-RenderManager/issues/71 @mdutton3 was this issue fixed for you?

I know this is mentioned elsewhere but I wanted to isolate this to the RenderManager path and consolidate the information we have. If there are scene switching issues without RenderManager, such a USB disconnect, that's a different issue. Related: https://github.com/OSVR/OSVR-Unity/issues/127

[russell-taylor]

Aha! It sounds like Unity is destroying the old RenderManager and creating a new one each time the scene switches. On an HDK in DirectMode, closing and reopening is known to cause the display to eventually stop working, which is presumably what is causing the crashes in DirectMode. It sounds like the SDL implementation is not robust to this (restarting within an app has not been one of our regression tests) so I can believe that it needs to be reworked, perhaps using a singleton to do the SDL init/quit only once per app. I'll open a RenderManager issue for this.

Both of these would be resolved in the Unity plug-in can avoid changing RenderManagers when a new scene appears. Can this be handled by keeping a static pointer to the RenderManager that is not destroyed until app quit and which is re-used between scenes? It would also avoid the annoying desktop show-through.

[rpavlik]

My pull request in the rendering plugin already does this (reuses existing render managers if created already)

On Wed, May 25, 2016, 8:53 AM Russell Taylor notifications@github.com wrote:

Aha! It sounds like Unity is destroying the old RenderManager and creating a new one each time the scene switches. On an HDK in DirectMode, closing and reopening is known to cause the display to eventually stop working, which is presumably what is causing the crashes in DirectMode. It sounds like the SDL implementation is not robust to this (restarting within an app has not been one of our regression tests) so I can believe that it needs to be reworked, perhaps using a singleton to do the SDL init/quit only once per app. I'll open a RenderManager issue for this.

Both of these would be resolved in the Unity plug-in can avoid changing RenderManagers when a new scene appears. Can this be handled by keeping a static pointer to the RenderManager that is not destroyed until app quit and which is re-used between scenes? It would also avoid the annoying desktop show-through.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Unity/issues/162#issuecomment-221582844

Ryan A. Pavlik, Ph.D. CTO - OSVR Platform Sensics, Inc. www.sensics.com

Latest news and blog posts (subscribe here http://sensics.com/subscribe-to-our-mailing-list/ go get weekly updates):

25 May: VRguy podcast Episode 12: Bernadette Jiwa on VR in Marketing http://sensics.com/vrguy-podcast-episode-12-bernadette-jiwa-on-vr-in-marketing/

18 May: VRguy podcast Episode 11: Greg Merril, Yost Labs, on full-body sensors> http://sensics.com/vrguy-podcast-episode-11-greg-merril-ceo-yost-labs-on-full-body-sensors/13 May: Forrester recognizes Sensics as one of five Breakout vendors in augmented and virtual reality https://www.forrester.com/report/Breakout+Vendors+Virtual+And+Augmented+Reality/-/E-RES134187

[DuFF14]

In Unity the OsvrRenderManager.cs class could indeed be a persistent singleton that isn't destroyed between scenes, which we currently do with ClientKit. I will test it out and see if there are any issues destroying RenderTextures from scene 1 and assigning new ones in scene 2, as the DisplayController is not persistent (but maybe it should be?). I am testing this with @rpavlik's PR branch in OSVR-Unity-Rendering.

[DuFF14]

The issues described here have been addressed in https://github.com/OSVR/OSVR-Unity/pull/163 @rpavlik's changes have been merged into OSVR-Unity-Rendering master branch.

[rpavlik]

Out of curiosity, is there a particular reason why we're using a custom game object to initiate rendering shutdown, instead of using the unity rendering plugin interface's built-in one? I get that startup, we need to provide the client context so we have partially defer some of that, but (not knowing much about the in unity rationale) it appears from the plugin point of view you could just leave it be and let unity shut it down. My pull request even deals with if your hook for starting it the rest of the way gets called multiple times and avoids multiple initialization (just early out from the init)