With the release of this public SDK, I would like to share learnings from developing the launch title, theBluVR, within Unity.
* Be on, at least, Unity patch release 4.5.5p3.
* From Oculus, keep on screen triangles under 50k and draw calls under 100. Our shaders are a little more complicated and as a result our average on screen counts are 30-40k triangles and ~50 draw calls.
* Stay away from all alpha. If it can be done without alpha, do it that way.
* Do bulk of setup work when faded to black. Shaders warming up while your experience is running will likely cause a hitch in the head tracking. Instantiation of large objects or groups of objects may also cause hitches.
* Loading large asset bundles will cause hitches in the view. Break up your loading across as many frames as possible. Make sure your textures are compressed with ETC2.
* Use texture atlas's to reduce materials and draw calls.
* Use static batching where possible. Be careful though, because this may bite back. Our texture atlas' are very aggressive and as a result the combined meshes created by the static batcher were too big to efficiently clip when passing through the camera frustum planes. Unchecking static on a couple of problem ground meshes that were close enough to the camera to be clipped by more than 1 frustum plane was the difference between running at frame and not.
* Don't let the garbage collection happen while the experience is running. Clean up resources when faded black.
* Optimize to 60hz. Then optimize again to account for app run length. Our CPU/GPU levels are set to 1 and 3.
I'm sure there are other items that people with launch titles have run into. Please post up items I've missed.
I can't wait to see what everyone creates on this amazing device! I hope you enjoy our title. Exciting times ahead!
Fantastic checklist, thank you! There were a few items in there I wasn't aware of.
I'll add a few of my own off the top of my head:
I use my own skybox so that I can rotate it as needed. One thing to keep an eye on here is to ensure that your cameras aren't needlessly clearing the color buffer if your skybox is already effectively doing that. EDIT: owenwp's reply indicates this may not be a good idea after all.
There's also a very nice list of optimization tips in the docs inside the Mobile SDK download -- an absolute must-read. In that doc, it recommends trilinear filtering, and keeping aniso low as possible. Trilinear does come with a bit of a performance hit that can be noticeable with large textures (4K) so choose wisely. If you're not able to make everything trilinear, then at least be aware that normal maps tend to be very obvious with mipmap transitions so they can be a good candidate for this. Aniso above 1 or 2 also comes with an obvious performance hit, and very rarely is anything going to need anything higher except floors and walls.
I'm also using CPU 1 / GPU 3, which tends to fit well with GPU heavy VR. But keep in mind that Unity can be CPU heavy if you have a ton of gameobjects, and/or a lot of gameobjects that have components with Update(), FixedUpdate(), or LateUpdate() defined. To be clear, simply having an empty Update() function in your script means it will be unnecessarily tracked and called by Unity every frame. This shows up as Overhead in profiler.
If you feel you need to speed up your loading times at app startup, you can increase your CPU clock level temporarily (to CPU 3 / GPU 2, for example), and then switch to a more appropriate setting (like CPU 1 / GPU 3) for the remainder of your app. The switch should probably occur when you've faded out, though as it will flicker the display.
Change your foreach loops to good ole for (unless it's just one-time startup code). Helps a little bit with garbage collection.
Titans of Space PLUS for Quest is now available on DrashVR.com
Not explicitly discarding the back buffer actually causes a bad performance stall on mobile. If you don't clear it, then the GPU has to load the framebuffer back from main memory, whether it is needed or not. Unity's training wheels may clear it even if you don't tell it to for that reason, but be careful with native development.
The reason is that the framebuffer only fits one tile at a time, it does not have enough space to keep the whole image. Basically it does all the rendering for one small square region of the screen, writes that tile to main memory, wipes the framebuffer, and does the next tile. You want to be very careful to avoid adding any extra steps to that process.
