[UE 4.18.1] Map loading breaks with Oculus

Hi,

there seems to be a bug where loading a very simple map in VR mode hangs the program for a very long time.
On the second VR PIE run onwards.
You can easily re-create this yourself or use the project I have attached to this message.

If you use my project do this:

  1. Start up, the map ‘StartMap’ should be open by default. Have your Rift connected and ready.
  2. Click VR Preview.
  3. Press Shift+s on the keyboard. (this is set in the level blueprint) This loads the map named ‘OpenThis’.
  4. Press ESC to shut down the PIE.
  5. Click VR Preview. A Second Time!
  6. Press Shift+s on the keyboard. This should now ‘freeze’ for a long time.
  7. if you want you can ESC, do PlayNewEditorWindow (2D) and then Shift+s to see that it is fast again.

This is affecting me very badly and I hope it can be fixed soon!

Here’s the project,
https://www.dropbox.com/s/ee6ax8no01rj04r/TestOculusMapLoadSlo.7z?dl=0

Let me know if you have any problems re-producing.

Cheers,

Thanks for the report,

Just reproduced this. It’s happening in 4.19 also. I will be investigating this further.

Great thanks!
On a later test I realised that I could do a ‘vr.bEnableStereo 0’ just before loading the map and that would avert the freeze. But as soon as I reversed that command after the load then I got the freeze.
Might be useful to know.

Issue logged at Unreal Engine Issues and Bug Tracker (UE-55031)

vr.bEnableStereo 0 is not working for me…

This also happens in a packaged multiplayer game in which the Oculus machine is a client. I submitted a bug report about it but no new issue was opened.

I’m reposting my solution to this from an identical thread since this is the official issue thread.

Temporary workaround fix:

To fix the issue you can call ShowSplashScreen before you call OpenLevel. Make sure your GameInstance calls SetSplashScreen (and get some nice splash screen texture to use), you’ll probably just do this in its Init function. You can also call EnableAutoLoadingSplashScreen for convenience, but the auto splash screen won’t be enough to fix it on its own because it will turn on too late. Then you’ll need to call HideSplashScreen once the level has loaded (in my case I do it once the local player has possessed a pawn in the level). Make sure you don’t ever miss the HideSplashScreen call or you can end up in a situation where the player just sees the loading splash screen indefinitely.

My debugging comments

I’ve spent a long time debugging this issue and I have some comments that will hopefully help the Epic devs:

This occurs in a freshly created VR template in 4.18 and 4.19 (I haven’t tried an earlier version).I am using an Oculus, I am not sure if this issue is present on the Vive. This issue is not present when using a non-VR PIE mode.

To reproduce add a OpenLevel node to the playercontroller on a keypress to have it open another level from the start level. Start the game in a VR preview and press the key to open the next level. When the load has finished close the PIE VR preview and start it again and repeat the process. The second time (and all subsequent times until the editor is restarted) the load will hang for a very long time and the HMD screen will freeze with a timer icon over it (different from fading to black during a normal load).

The hang is always exactly 30 or 60 seconds (+ 1 or 2 for normal load delays), suggesting to me there’s some hangup that’s only resolved when the garbage collector first kicks in. It seems the game thread is being blocked by the rendering thread which is being blocked from flushing some cached resources from the previous run.

I have another project that doesn’t have this issue, investigating why to hopefully find a solution.

Later…

I figured out why my project doesn’t have the issue. If you have a VR loading splash screen enabled when you start loading the level it’ll prevent the hang from happening. I believe this is because the bug is due to something the HMD is rendering not being unloaded properly when the next map starts loading which locks up the rendering thread (which locks up the game thread in GameThreadWaitForTask) until the GC finally removes the object causing the block (obviously this explanation is missing a lot of technical detail since I haven’t looked at the HMD rendering code but hopefully I’m in the right ballpark). Also, the issue is present in 4.18 but seems relatively new anyway so I’m wondering if there was some recent change in the Rift’s drivers that made this issue pop up suddenly. Just a random guess, it would be helpful to know if you are using a Rift too.

Note that this bug occurs even if you’re loading an empty pawn into an empty map and it only occurs in a VR preview in editor due to this code in UObject::SetLinker

 if (bShouldDetachExisting)
     {
 #if WITH_EDITOR
         PostLinkerChange();
 #else

The UObject is a Texture in this case and PostLinkerChange triggers ReleaseResource on it and that release seems to be where the block is.

I’m guessing this fixes the issue because it stops rendering everything but the splash screen texture, so whatever resource or process would otherwise lock up the rendering thread during loading was already hidden/stopped by the splash screen. I hope this is helpful and hopefully Epic will weigh in soon.

Relevant stack trace:

 FEventWin::Wait
 GameThreadWaitForTask (in RenderingThread.cpp)
 FRenderCommandFence::Wait(bool)
 FlushRenderingCommands()
 UTexture::ReleaseResource()
 UTexture::UpdateResource()
 UObject::SetLinker(FLinkerLoad * LinkerLoad, int LinkerIndex, bool bShouldDetachExisting)
 FLinkerLoad::FindExistingExport(int ExportIndex)
 FLinkerLoad::FindExistingExport(int ExportIndex)
 FLinkerLoad::FindExistingExports()
 FLinkerLoad::Tick(float InTimeLimit, bool bInUseTimeLimit, bool bInUseFullTimeLimit)

I reported this to Oculus and they said,
“We have pushed a fix to our 4.19 branch addressing this issue.”

Not sure if that means the fix should have appeared in 4.19 or in 4.20.

https://developer.oculus.com/bugs/bug/1802567919773499/

If you are using Rift maybe you can comment on the bug page and say it seems unresolved?

The issue is listed as unresolved in 4.20 but that’s great to know, hopefully it’ll be integrated soon.

I’m still on 4.19 and haven’t checked if it’s actually unresolved still. It’s possible the issue is just labeled wrong.

Thanks for all the extra info hdelattre! It was mislabeled (I was originally testing in an old version of 4.20) - I just verified that this is no longer an issue in the latest version of 4.20

Amazing, this totally solved the problem we were having outside of the editor (where the VR player is a client in a multiplayer game). In our case we show the splash screen in FCoreUObjectDelegates::PreLoadMap and hide it in UGameInstance::LoadComplete. This way I can handle it all in the GameInstance and not be dependent on the playercontroller or pawn.
Thanks so much for sharing your findings.