cancel
Showing results for 
Search instead for 
Did you mean: 

Need Help on Unity VR Development Challenges

shahzaib.435015
Explorer

I hope this message finds you well 😊. I am currently engaged in Unity VR development and navigating through the intricacies of creating immersive experiences.

Given the dynamic nature of VR technology and Unity's evolving landscape, I'm curious to hear about your experiences and insights. Here are a few specific points I'd love to get your thoughts on:

 

1. What strategies have you found most effective for optimizing Unity VR projects to ensure a seamless and immersive user experience, particularly when it comes to resource-intensive elements like graphics and interactions?

2. Have you faced any specific challenges when integrating Unity VR projects with external hardware or third-party plugins? How did you overcome these hurdles, and are there any cautionary tales or lessons learned you could share?

 

I genuinely appreciate your time and expertise in addressing these questions. Your insights will not only aid me in overcoming current roadblocks but will also contribute to the collective knowledge of our community. Let's collaborate and elevate our Unity VR development endeavors together.

Thank you in advance for your valuable input!

1 ACCEPTED SOLUTION

Accepted Solutions

#1 alone is a huge question! 😁

VR has stricter optimisation requirements but as with all games there are no definite rules. Depends on what's on screen and where you want to spend your frame budget.
 
Most important is learn to profile so that you know where your bottlenecks are. You could be CPU or GPU bound (see: https://blog.unity.com/engine-platform/profiling-in-unity-2021-lts-what-when-and-how). Techniques you use to alleviate one will be conter productive for the other.
 
Some general tips -
 
Forward rendering with baked lighting is pretty common as shadows are expensive. Bake light maps and if you must have real-time shadows have a single directional light. Then turn off shadow casting everywhere you can, especially on smaller objects and particles. Real time reflection probes are expensive too, bake them and reduce the resolution. Avoid realtime global illumination.
 
Screen space post processing effects are expensive in VR (particularly standalone VR because of the tile-based rendering) and are generally avoided if possible. So make you textures look good without the need for colour grading or other post effects. Avoid ambient occlusion, global fog, motion blur etc. but if you must, colour grading is doable. Here's a good article from the developer behind The Last Clockwinder aon doing performant Post Processing on Quest https://johnaustin.io/articles/2022/fast-post-processing-on-the-oculus-quest
 
If you're targeting standalone VR, these headsets are essentially android devices so use mobile game dev best practices. Even on desktop VR aim for the low end of things, so cut down on transparencies and decals and keep shaders optimized. Overdraw is often a performance bottleneck (learn to use RenderDoc to identify this). Use material render order where necessary. Use optimised shaders. Basic shaders where you can get away with it, even legacy ones (but avoid the multipass ones like legacy specular). Or use an uber shader like Better Lit Shaders which can reduce set pass calls
 
Atlas all your textures, share materials and mesh combine to reduce drawcalls. Don't just rely on static batching (which has a performance overhead) Mesh merge sections of your scene - this isn't easy. You need to find the right balance between chunks that are small enough to make the most of baked occlusion culling and frustrum culling, but large enough to give you the benefit of batching. And don't forget to set that Static flag on static objects.
 
For models, good low poly topology is important (properly clean-up things like non-manifold geometry, etc.) That doesn't necessarily mean the faceted "low-poly" style that many people associate with VR, just good game-ready models. These should be using high quality textures if you're aiming for photo-realism. High to low poly texture baking workflows are generally good for VR. Try to avoid lots of texture maps though. I personally usually bake the AO into the diffuse as an optimisation step. There's a bit of a debate over whether normal maps work in VR or not. Generally they don't pop as well as in 2D especially up close (because of the stereoscopic rendering) so are only really useful for details in the middle distance, where it doesn't make sense to model the geometry.
 
Overlapping UVs are an issue as it makes atlasing harder and good lighting UVs are important too.
 
LODs are another area for debate (this is an interesting read on the matter: https://forum.unity.com/threads/psa-a-general-rant-on-model-lods.859201/). Obviously useful for reducing on-screen geometry, but popping can be incredibly immersion breaking. Some devs avoid them altogether while others rely on them to avoid being GPU bound by their vert counts on Standalone VR. Something that's not so often talked about re. LODs is that they're useful to combat aliasing (a big issue in VR) and can also be used to not just reduce mesh complexity but also shader complexity. Lower resolution LOD levels should be well designed and use a fading transition. Imposters are great for more distant objects. 
 
It's really important to understand where the player is likely to move and/or look, split your environment (conceptually) into near field, mid field and far distance. Near field would be for high poly details, mid field should start to have fewer verts and can use normal and displacement maps, then as you get further out into the distance use silhouette geometry, imposters, etc. This video is about old mobile VR but is still applicable (especially on standalone platforms like the Quest) https://www.youtube.com/watch?v=KYYdvtf2DhQ&list=PL4p5NRamFPnitdsEKV8GpY3DllccH-mzl&index=40&t=909s
 
Skinned Meshes (character modelling, if that's also your thing) are hard to get right in VR. Hero models with full facial rigs and complex, expressive blendshapes are expensive in VR. Again, it comes down to your frame budget. As well as keeping poly counts down, keeping materials numbers down, mesh combining etc, make sure you're minimizing the number of joints influencing each vert. A max of 4 bones per vert is an absolute limit.
 
Optimise your code. Obvious things like not using Find, or doing GetComponent in an update loop. For things like AI, run your own update loop at an interval that's lower than frame rate (most behaviour trees don't need to be recalculated at 90Hz) As a bonus, this is an awesome talk about some less talked about strategies https://www.youtube.com/watch?v=NAVbI1HIzCE
 
Physics can be expensive. Use Layers (and the collision matrix) so that calculations are only being made on colliders that need to be included. Disable rigidbody when not needed (perhaps when far from the player), Do this either with lods or through scripting (myRigidbody.detectCollisions = false; myRigidbody.useGravity = false;)
 
And finally, remember that game dev is all about smoke and mirrors. Unless you're specifically building a digital twin simulation, find clever ways to make your player think they're seeing more than they actually are. 
 
Here are a few talks worth starting off with. They're old but the principles still apply even on new hardware:
 

View solution in original post

1 REPLY 1

#1 alone is a huge question! 😁

VR has stricter optimisation requirements but as with all games there are no definite rules. Depends on what's on screen and where you want to spend your frame budget.
 
Most important is learn to profile so that you know where your bottlenecks are. You could be CPU or GPU bound (see: https://blog.unity.com/engine-platform/profiling-in-unity-2021-lts-what-when-and-how). Techniques you use to alleviate one will be conter productive for the other.
 
Some general tips -
 
Forward rendering with baked lighting is pretty common as shadows are expensive. Bake light maps and if you must have real-time shadows have a single directional light. Then turn off shadow casting everywhere you can, especially on smaller objects and particles. Real time reflection probes are expensive too, bake them and reduce the resolution. Avoid realtime global illumination.
 
Screen space post processing effects are expensive in VR (particularly standalone VR because of the tile-based rendering) and are generally avoided if possible. So make you textures look good without the need for colour grading or other post effects. Avoid ambient occlusion, global fog, motion blur etc. but if you must, colour grading is doable. Here's a good article from the developer behind The Last Clockwinder aon doing performant Post Processing on Quest https://johnaustin.io/articles/2022/fast-post-processing-on-the-oculus-quest
 
If you're targeting standalone VR, these headsets are essentially android devices so use mobile game dev best practices. Even on desktop VR aim for the low end of things, so cut down on transparencies and decals and keep shaders optimized. Overdraw is often a performance bottleneck (learn to use RenderDoc to identify this). Use material render order where necessary. Use optimised shaders. Basic shaders where you can get away with it, even legacy ones (but avoid the multipass ones like legacy specular). Or use an uber shader like Better Lit Shaders which can reduce set pass calls
 
Atlas all your textures, share materials and mesh combine to reduce drawcalls. Don't just rely on static batching (which has a performance overhead) Mesh merge sections of your scene - this isn't easy. You need to find the right balance between chunks that are small enough to make the most of baked occlusion culling and frustrum culling, but large enough to give you the benefit of batching. And don't forget to set that Static flag on static objects.
 
For models, good low poly topology is important (properly clean-up things like non-manifold geometry, etc.) That doesn't necessarily mean the faceted "low-poly" style that many people associate with VR, just good game-ready models. These should be using high quality textures if you're aiming for photo-realism. High to low poly texture baking workflows are generally good for VR. Try to avoid lots of texture maps though. I personally usually bake the AO into the diffuse as an optimisation step. There's a bit of a debate over whether normal maps work in VR or not. Generally they don't pop as well as in 2D especially up close (because of the stereoscopic rendering) so are only really useful for details in the middle distance, where it doesn't make sense to model the geometry.
 
Overlapping UVs are an issue as it makes atlasing harder and good lighting UVs are important too.
 
LODs are another area for debate (this is an interesting read on the matter: https://forum.unity.com/threads/psa-a-general-rant-on-model-lods.859201/). Obviously useful for reducing on-screen geometry, but popping can be incredibly immersion breaking. Some devs avoid them altogether while others rely on them to avoid being GPU bound by their vert counts on Standalone VR. Something that's not so often talked about re. LODs is that they're useful to combat aliasing (a big issue in VR) and can also be used to not just reduce mesh complexity but also shader complexity. Lower resolution LOD levels should be well designed and use a fading transition. Imposters are great for more distant objects. 
 
It's really important to understand where the player is likely to move and/or look, split your environment (conceptually) into near field, mid field and far distance. Near field would be for high poly details, mid field should start to have fewer verts and can use normal and displacement maps, then as you get further out into the distance use silhouette geometry, imposters, etc. This video is about old mobile VR but is still applicable (especially on standalone platforms like the Quest) https://www.youtube.com/watch?v=KYYdvtf2DhQ&list=PL4p5NRamFPnitdsEKV8GpY3DllccH-mzl&index=40&t=909s
 
Skinned Meshes (character modelling, if that's also your thing) are hard to get right in VR. Hero models with full facial rigs and complex, expressive blendshapes are expensive in VR. Again, it comes down to your frame budget. As well as keeping poly counts down, keeping materials numbers down, mesh combining etc, make sure you're minimizing the number of joints influencing each vert. A max of 4 bones per vert is an absolute limit.
 
Optimise your code. Obvious things like not using Find, or doing GetComponent in an update loop. For things like AI, run your own update loop at an interval that's lower than frame rate (most behaviour trees don't need to be recalculated at 90Hz) As a bonus, this is an awesome talk about some less talked about strategies https://www.youtube.com/watch?v=NAVbI1HIzCE
 
Physics can be expensive. Use Layers (and the collision matrix) so that calculations are only being made on colliders that need to be included. Disable rigidbody when not needed (perhaps when far from the player), Do this either with lods or through scripting (myRigidbody.detectCollisions = false; myRigidbody.useGravity = false;)
 
And finally, remember that game dev is all about smoke and mirrors. Unless you're specifically building a digital twin simulation, find clever ways to make your player think they're seeing more than they actually are. 
 
Here are a few talks worth starting off with. They're old but the principles still apply even on new hardware: