Steam VR and loading screens.

Unreal newbie here, so I apologize for any ignorance!

My studio is working on a VR piece with the HTC Vive. We would like a loading screen for when the user changes levels. I’ve followed a couple of tutorials to set up loading screens; however, when I call the “Load Level” function in game, the vive goes to it’s default background while the level loads, ignoring anything else that’s scripted in my blueprints.

Is this a known issue with the Vive, or am I missing something important? Is there any good training out there for VR loading screens?

Hi Brad,

At the moment I don’t have direct access to test on an available HTC Vive, but I will hopefully this afternoon or tomorrow.

I wanted to go ahead and offer some information that is currently out there that you may not have been aware of.These aren’t VR specific, but I wouldn’t expect there to be a significant difference here though, at least not that I can readily think of.

As for the problem you’re having I’ve used the training stream’s project and my own but haven’t noticed an issue with or without my Oculus at my desktop. I’ll be able to test the Vive soon to make sure I’m seeing the same results with that. In the meantime can you clarify the following?

  • Do you see any odd behavior if it’s not in the VR mode?
  • Are you using a level that is streamed in and out called by a BP Load Streaming Level node, a level streaming volume, or just calling the Open Level BP node?
  • If you can share any additional details about your setup for the level stream that may be useful if the links above don’t answer your question.

Some of the scripted events that happen are supposed to happen after the level load may be answered by Alan in the twitch stream I think. He discusses some strategies for handling some events that may help.

Thank you!

Tim

Hey Brad and Steven,

I was able to see this when I loaded a bunch of assets in the streamed level. That helped! I’ve submitted UE-34018 for this to be tracked. You can follow the status in the linked issue above. Also, when there is an update to this ticket I’ll post back here with any fix CL’s or relevant information.

Thank you!

Tim

We’re working hard on VR loading screen support, and it will land soon after 4.13 ships.

The problem you’re seeing, as you suspected, is that when the game misses frames, it drops out to the compositor. If you can’t wait for the official loading screen support, the best way to keep the compositor primed with new frames is to use an FRenderThreadTickable. Those are, as the name implies, ticked on the render thread, and thus won’t be interrupted by the game thread stalling.

The easiest analog to follow would be in OculusRiftSplash.h, which builds on FAsyncLoadingSplash, and primes their compositor with new frames

Hope that helps!

Funny, I was going to post this exact issue today, too. Brad beat me to it!

We’re having the same problem with Vive. When we use the LoadStreamLevel node, the Vive displays its white background for the duration of the load, regardless of whether or not the “Should Block on Load” checkbox is checked.

I assume what’s happening is that during the load process, new frames are not submitted by the engine to the Vive HMD, and so the Vive decides to pop up the white room for safety reasons. In our case, the load is only around 1 second, so the blindingly white Vive screen is annoying and takes you out of the experience. We’d love to find a way to have the engine continue to feed frames to the Vive while we’re loading the next level, so that the Vive screen doesn’t pop up each time.

I’ve been meaning to check out the Loading Screens training stream to see if there’s a solution there.

Hey Tim.

Thanks for the quick response. To answer your questions:

  • All interactions outside of VR mode have been disabled for quite a while. As we did not intend to focus on any other mode, I will need to reconnect a pawn to interact with everything.
  • Before posting this question, I was using the old Open Level BP node. Since then, however, I set up streaming which makes the transition happen much quicker - closer to one second - which is an improvement, but not the ideal.

Before I get ahead of myself, I’d like to try something recommended in the video you linked. Much appreciated by the way!

For what it’s worth, I think that Steven gives a better explanation of what we seem to be experiencing on our end.

Thanks for all the details. I’ll be able to test on the Vive in a short bit. I’ll post back soon.

Hey Brad and Steven,

I had a colleague test on their Vive today and they weren’t seeing the default room in my test project that I setup the level streaming. I’ll be able to look at this more early next week though.

We tested this with 4.12.5. I didn’t initially see that there wasn’t a version listed above from either of you. Are you both using this version or another one?

Tim, we’re on 4.12.5 as well. I’m also seeing this on 4.11.2 FWIW.

For your test project, is the level you’re loading substantial, in that it takes over a second (or so) to perform the load? If the level loads very quickly, it may be that it’s not triggering the Vive’s test screen to be drawn.

We’re on 4.12.5, too.

As we are closing in on the deadline for tier 1 of our project, the loading screen was dropped as a priority until tier 2. I apologize, but I will not be very helpful for about a week. Will still try to help out if possible, though!

Thanks for logging this, Tim. The problem for us is really detracting from our game experience. Would you be able to speak with others there to see if there’s a possible workaround we could try?

Not sure if this is helpful, or even doable, but one of our guys suggested temporarily changing out the .png file being used by the Vive home-screen to something that makes more sense while the experience is active. That might be opening a-whole-nother can of worms.

Looks like one of the engineers responded on the ticket that this is by design. This is what was suggested:

If the game does not send multiple frames in time, the steamvr compositor will send the player back to the lobby for safety reasons. The game needs to use async loading / level streaming or mask with a loading screen that pumps frames to the compositor.

Thanks for the suggestion, and for looking into this!

Hi Tim, we are using level streaming. And reading above, it looks like Brad has also tried level streaming. Specifically, we use the LoadStreamLevel node, but the Vive displays its white background for the duration of the load, regardless of whether or not the “Should Block on Load” checkbox is checked.

Which brings me back to my original question - how can we have UE4 pump frames to the compositor while we’re streaming in a level?

As to your other suggestion of “mask with a loading screen that pumps frames to the compositor”, that would be a good solution, but I still don’t know how to have UE4 pump frames while we’re streaming in the next level, regardless of whether there’s a loading screen being drawn.

Thanks so much, Nick. I couldn’t find FRenderThreadTickable, but did find FTickableObjectRenderThread. Is that the one? I assume this solution can’t be implemented in Blueprint?

The improved loading screen support is dependent on further stereo-layer support. It is multiple changelists, basically you would look at everything chad.taylor did since 4.13, and most of the cls would be this.

My impresssion is that this code is mostly alongside the rest of the vr code, as new functions and classes, rather than heavily modifying existing functions so it is probably not impossible to integrate it, but it will be a fair number of files and changelists.

_4.14 is already in preview of course, and that build has this feature already.

Whoops, apologies, you are correct!

And yes, this would require code support at the moment. Once the generic system is in, you could do it completely in blueprint, however.

Hi Nick, I wanted to check in to see how close we are to getting VR loading screen support, now that 4.13 is out.

Hi Steven, quite close! VR loading screen support is targeted to go out with 4.14.