VRTK_LoadScene

[dantman]

Unity's built-in LoadScene doesn't work well for VR. Some non-VR games use it rather than bothering with the async or additive version of LoadScene because it's a simple call. Unfortunately, in VR the sync nature means that rendering is blocked, FPS on the headset plummets to 0, and while the next scene is loading the user is kicked back to the dashboard. So implementing scene loading correctly is an important issue in VR.

The SteamVR Unity Plugin contains a SteamVR_LoadLevel component and API that offers an alternative for use in SteamVR and appears to do an number of things:

• It creates an progress bar and loading screen display as OpenVR overlays and also renders them to the companion window shown on the desktop
• Allows you to specify a skybox/color to theme the SteamVR dashboard and whether to display the grid
• Automatically fades out to the dashboard and stops rendering
• Handles sync/async/additive loading itself
• Does GC, warms up shaders, fades back out of the dashboard
• And does all this in a coroutine you can easily call without needing to use Unity's poor LoadSceneAsync api directly.

VRTK could use its own VRTK_LoadScene component to simplify scene loading in VR.

There are 2 ways that a VRTK_LoadScene could work.

1. It could be a platform wrapper script:

• If the current VR platform/SDK has its own LoadScene implementation such as SteamVR_LoadLevel implementing a loading screen, it could be used
• If the current platform doesn't it could simply fall back to traditional (async) scene loading

2. If possible, it could be a high-level async loading implementation:

• We could implement base components for handling a floating progress bar / loading screen
• All the LoadSceneAsync handling could be abstracted to a VRTK_LoadScene.Begin (function) or VRTK_LoadScene.Load (coroutine).
• Perhaps something like a fade-to-black blink could be used for the momentary transition between scenes

[bddckr]

I love the idea of having a high-level one in VRTK, so I vote for your second point above.

[dantman]

Realistically we could do both as separate options. Platform fallback wrapper is simple. Configuring a 3d loading area is more complex but looks better.

[wildstyle007]

This would be a great feature to include in VRTK. It would be nice if the fade transitional aspects were optional and / or only kicked in when needed. I'm doing a lot of additive async scene loading in my project and sometimes things can load in totally smooth with no drops.

[dantman]

Sure. I was only thinking of non-additive loading. Forgot that sometimes additive loading can use a loading progress bar.

[thestonefox]

I agree this is something that should be looked at

[thestonefox]

Gonna merge this into here https://github.com/thestonefox/VRTK/issues/72

[dantman]

OculusVR appears to have its own compositor/overlay API. I wonder if there's any way to make it behave similar to the SteamVR api, overriding the view while we load.

https://developer3.oculus.com/documentation/game-engines/latest/concepts/unity-ovroverlay/

[michidk]

Are there any news? Is somebody working on this?

[thestonefox]

No one is working on this feature at the moment afaik

[D3m0n92]

News?

[bddckr]

Guys. If there is any you'll see it because this issue is updated. You could also do it yourself, PRs welcome!

[applus-huggy]

Just adding my experiences with the SteamVR implementation for when you guys look into this more.

Try work it along the lines of just a callback receiver so you can feed in from almost anything, not just scenes. With our project loading large files required the loading screen and had to make an extension method for the SteamVR class because loading them caused massive frame drops. I could see this also being useful for saving games, exporting files or generating procedural stuff too.

[bddckr]

Any implementation should definitely just be about abstracting overlays. The target shouldn't be a specific use case.

With v4 work going on it will be a while until I can have a look at this but it's still on my radar.