If you haven't already done so, please take a look at the Startup_Sample in the SDKExamples. It shows how to create and implement a small startup scene that transitions to your main scene. You'll most likely be required (or at least really want to) implement something like it. Here are the benefits:
Your app/game will start up fast with a small start up scene.
By including a stereo camera in the start up scene, head tracking will happen almost immediately giving your users a more comfortable experience
By setting the splash screen in the player settings to a nearly-black texture, you get rid of any non-stereo image that is going to be jarring to the user when launched from the Dashboard.
You can use an asynchronous scene load to load a really large scene while still doing head tracking and time warp.
You can present your game and/or logo in a way well suited for VR (and no you don't have to use the Oculus logo in the sample.. although you can if you want!)
You can easily add a progress bar to give the user feedback on the scene load.
I haven't progressed much further than that. As I mentioned, Timewarp still works during the transition, although not perfectly (it freezes up for a few frames here and there).
Can you throw your procedural generation into one or more co-routines so the heavy lifting is done in a number of frame rate friendly methods ( i.e. containing calls to yield )?
So far I've focused on reducing the total loading time (optimizing things, and moving some processes from runtime to build-time), but I'll try something like that next. I'm not sure how much an effect it will have, though, given that it seems most of the time is lost in Instantiate calls, rather than my own code.
One obscure scene load time tip: It seems that prefabs in scenes load slower than non prefabs. (This may be fixed in more recent versions of Unity but I'm not so sure). If you break all prefab connections in the scene you want to load, you may see an load time reduction.
I've tried taking the Startup_Sample scene and hooking up our main scene to load (it is a relatively basic scene meant to load other scenes, but still has about 4-5 seconds of splash screen). The sample from the sdk works on device, and my use of it works in editor, but when I put my version on the device, I get a bunch of GL errors when the second scene load is attempted (but no other unity errors):
08-01 05:53:38.253: W/Adreno-EGL(13752): <qeglDrvAPI_eglMakeCurrent:3031>: EGL_BAD_ACCESS 08-01 05:53:38.253: E/libEGL(13752): eglMakeCurrent:813 error 3002 (EGL_BAD_ACCESS) 08-01 05:53:38.253: E/Unity(13752): eglMakeCurrent(s_EGLDisplay, s_EGLSurface, s_EGLSurface, s_EGLContext): EGL_BAD_ACCESS: EGL cannot access a requested resource (for example a context is bound in another thread). 08-01 05:53:38.253: E/Unity(13752): 08-01 05:53:38.253: E/Unity(13752): (Filename: ./PlatformDependent/AndroidPlayer/Source/ContextGLES.cpp Line: 317) 08-01 05:53:38.253: W/Adreno-EGL(13752): <qeglDrvAPI_eglMakeCurrent:3031>: EGL_BAD_ACCESS 08-01 05:53:38.253: E/libEGL(13752): eglMakeCurrent:813 error 3002 (EGL_BAD_ACCESS) 08-01 05:53:38.253: E/Unity(13752): eglMakeCurrent(s_EGLDisplay, s_EGLSurface, s_EGLSurface, s_EGLContext): EGL_BAD_ACCESS: EGL cannot access a requested resource (for example a context is bound in another thread). 08-01 05:53:38.253: E/Unity(13752): 08-01 05:53:38.253: E/Unity(13752): (Filename: ./PlatformDependent/AndroidPlayer/Source/ContextGLES.cpp Line: 317) 08-01 05:53:38.253: E/libEGL(13752): call to OpenGL ES API with no current context (logged once per thread)
Looks like a threading issue, but not sure if there's anything obvious I should be on the look out for. If I switch off multithreaded rendering it turns into an EGL_BAD_ALLOC and crashes. Anybody seen this?
Is it just me, or does using this startup scene break mouselook in the editor? (Using Oculus' own mouselook scripts). Seems to be getting the mouse move messages ok and applies the offset to the ovr camera, but nothing happens.
Regardless, head tracking still works on the device. It's just running from this start scene in the editor disables the mouse somehow.
What worked best for us for the "mobile splash screen" graphic was to paint over an image of a screenshot we took from the device. This helped is get the camera and stereo correct. Then we go to a very light weight 3d boot scene that loads fast and does configurations before moving onto the experience.
