cancel
Showing results for 
Search instead for 
Did you mean: 

Worse performance in Build than in Editor

Klart3333
Level 3

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: WoodsInEditor.PNG

 

Profiler in Build:WoodsInBuild.PNG

 

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 .-. )

1 ACCEPTED SOLUTION

Accepted Solutions

DarkTable
Level 6

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.

View solution in original post

6 REPLIES 6

DarkTable
Level 6

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.

View solution in original post

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 :/)

baroquedub
Level 4

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 🙂

DarkTable
Level 6

This is the best talk about optimizing content for the Quest that I've seen:

https://www.youtube.com/watch?v=JvMQUz0g_Tk

DarkTable
Level 6

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-...

 

syntyscifi.jpg

It'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.

Klart3333
Level 3

Thanks for the replies, it really helps 😄

 

I guess I'll get to work optimizing then haha