Forum Discussion
Solved
Worse performance in Build than in Editor
I've been puzzling over this performance issue for a while now. I'm building a Oculus VR game for the Oculus Quest, everything is going great but the performance specifically in builds really tanks while it's great in the editor. I've looked around and haven't really found any solution to this. I'm using Unity 2020.1.3f1
Profiler in Editor:
Profiler in Build:
Any help would be greatly appreciated as this issue is really killing development. Thank you.
(I sent oculus a ticket, twice actually, and the second time I was just sent here .-. )
That profile is clearly pointing at rendering as being where all the time is spent, and below that it's saying there's about 500,000 vertices being drawn. That's a problem. In your PC sample there are 350,000 vertices, so it's not an exact comparison, but obviously a PC can handle more verts/triangles than a Quest can.
The recommended budget for Quest 1 is 200,000 - 300,000. And this still depends on what shaders you're using. Baked lighting? Realtime shadows? Quest is mobile hardware and you need to design with those limitations in mind.
Looking closer at the PC profile, the app seems to be running below 60fps most of the time with spikes down to 15fps. You have a lot of optimization to do. If you can't hit at least a stable 72fps on PC there are fundamental problems with what you're designing.
10 Replies
Replies have been turned off for this discussion
That profile is clearly pointing at rendering as being where all the time is spent, and below that it's saying there's about 500,000 vertices being drawn. That's a problem. In your PC sample there are 350,000 vertices, so it's not an exact comparison, but obviously a PC can handle more verts/triangles than a Quest can.
The recommended budget for Quest 1 is 200,000 - 300,000. And this still depends on what shaders you're using. Baked lighting? Realtime shadows? Quest is mobile hardware and you need to design with those limitations in mind.
Looking closer at the PC profile, the app seems to be running below 60fps most of the time with spikes down to 15fps. You have a lot of optimization to do. If you can't hit at least a stable 72fps on PC there are fundamental problems with what you're designing.
Thanks for the quick reply!
I have wondered over this and I guess it's maybe just to heavy of a scene, but it's literally just a clearing in the woods with a few trees. It just seems so simple when there are so many more advanced VR games out there, but I guess those may just be better optimized.
The main source of my confusion is that in the build, the largest reason for lagg is the PostLateUpdate.PlayerSendFrameStarted (plus the things under), which don't show up in the editor at all, which led me to believe that something was set upp incorrectly or the like. Maybe the process is just waiting for the gpu to finish rendering and that's why it says it's taking so long, at least that's my best guess.
Would love a response to these inquiries, even a "no you're stupid" would work lol 😄
(Also, I thought the headset was still rendering in the editor considering it still has to display the **bleep**, ya know? I just thought it would be weird if the computer was doing the processing and awkwardly sending it to the headset :/)
Hi - Just wondering if the recommended budget for verts is higher on the Quest II?
Quest 2 has more performance headroom, so yes.
See here: https://developer.oculus.com/documentation/unity/unity-perf/?locale=en_USQuest 1350k-500k trisQuest 2750k-1.0m trisps. problem is depending on how you're releasing your apps, you won't know if your players will have a Quest or Quest 2, so either you develop for the lowest common denominator or you do some clever sniffing out of the device and serve different models depending on the HMD
When you're running in the Editor you're profiling your game running on PC hardware (plus the Editor overhead). A development build running on the actual target hardware (as you have done in the second screenshot) is your real and only benchmark. So it's not that there's "Worse performance in Build than in Editor", it's just that if your target platform is the Quest, then the game's performance on desktop is irrelevant.
As has been suggested, you're pretty obviously vertex bound. You're asking the Quest to render too much geometry. On top of that, 303 set pass calls (drawcalls) is way too high for mobile.Here's how to do proper performance analysis:
https://developer.oculus.com/documentation/unity/unity-perf/
Here's a quick performance cheatsheet:
https://unity3d.com/how-to/optimize-mobile-VR-games
Oculus guidelines:
https://developer.oculus.com/documentation/native/pc/dg-performance-guidelines/
https://developer.oculus.com/documentation/unity/unity-best-practices-intro/
Recommended Unity settings:
https://developer.oculus.com/blog/tech-note-unity-settings-for-mobile-vr/
Hope that helps. performance analysis and iterating through finding bottle necks and working on solutions is half the fun of VR development. Embrace it and enjoy it 🙂
This is the best talk about optimizing content for the Quest that I've seen:
Full Disclosure: The first thing I did when I got my Quest and Unity set up was make a build with this asset and wonder why the frame rate was so bad:
https://assetstore.unity.com/packages/3d/environments/sci-fi/polygon-sci-fi-city-low-poly-3d-art-by-synty-115950It's "low poly" art style, right? Must be mobile friendly. Actually, no. It's a *faceted* art style which has TONS of vertices/polygons because every nook, cranny, ridge and scratch is modeled instead of provided by a normal map. Terrible for mobile.
Very similar journey to what you're on now.
Thanks for the replies, it really helps 😄
I guess I'll get to work optimizing then haha
