[Gear VR] 4.13 engine loading times question

One of the issues we had (that got fixed on 4.13.1, so stay tuned ;) ) is the fact that we had multiple enterVR/leaveVR calls, as VRAPI had a single-thread architecture compared to UE4 multi-thread rendering architecture between async loading (the spinning ring) and the actual renderthread. That got fixed for black screen issues on Adreno-based devices, but the fix should also make loading hopefully a bit faster. Let us know :)

We're also seeing a race condition for the creation of the first frame, which in the logs show that the first frame is actually rendered in non-VR mode. Working on fixing that. 

I'm not an expert on how to optimize levels for loading times though :( Are all your textures ASTC?

@rpalandri

Ah, I see. Can't wait for 4.13.1 ! :)

No, I am still using ETC2 textures. I don't think level optimization has anything to do with initial engine loading time. I am still using same level I used in 4.11 and 4.11 would literally take 4-6 sec to start.

So, I watched Carmack's closing keynote last night and he was stressing about loading times.

I am using 4.13.1 and I didn't notice much difference in loading time between 4.13.0 and 4.13.1.  Definitely not under 10 sec. :(

Is it what it is and UE4 is bound to remain a slowpoke? :(

P.S. So far only tried development build with 4.13.1, but based on my experience with past versions I don't see release build loading any faster.

With UE4 you should be able to show an ATW splash quad within 2s of launching the APK so that head tracking works while loading your first map. The amount of time you spend looking at the splash quad depends on the complexity of the first map. It's up to app developers to make the first map very simple and defer as much loading as possible. Please let me know if you still see >10s loading times after doing that.

vrdaveb said:

With UE4 you should be able to show an ATW splash quad within 2s of launching the APK so that head tracking works while loading your first map. The amount of time you spend looking at the splash quad depends on the complexity of the first map. It's up to app developers to make the first map very simple and defer as much loading as possible. Please let me know if you still see >10s loading times after doing that.

I do get ATW splash in ~2 sec. and I just tested loading with FPS template (small project) and it did load pretty quickly.

I guess I am not using streaming levels functionality correctly :( 

This is my setup:



Persistent Level has Skylight, directional light, Lightmass volume and Sky sphere actor.

InitMap (always loaded method) has black room and player.

FullMap (BP loading method) has everything else (all the geometry, etc.)

So the idea is that InitMap loads up first (super small, should load in a second or two) and while player is hanging out there watching progress bar, FullMap streams in the background and as soon as it's loaded, player either gets teleported to the FullMap level or a menu would be revealed in the InitMap and player go from there.

When I do stat cmd to see how levels are being loaded (in PIE) I can see that InitMap loads first, then FullMap loads second.

However on the device it feels like all assets load first, then InitMap loads and then FullMap loads in the background (and that eats up performance badly as if there is no async streaming available on mobile) and then player gets teleported from black room to the main level.

What am I doing wrong?

Thanks beforehand

@vrdaveb

Sounds like engine's issue https://issues.unrealengine.com/issue/UE-36835

Apparently I had a lot of hidden junk on Persistent level :/ Sorted it all out and now the game loads quite fast.

Thanks. We're investigating UE-36835, but incremental loading and ATW splash screens should help in most cases.