Skip to main content
Klart3333
New Participant
May 20, 2021
Solved

Worse performance in Build than in Editor

  • May 20, 2021
  • 10 replies
  • 7476 views

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

    This topic has been closed for replies.
    Best answer by

    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

    Anonymous
    Answer
    May 20, 2021

    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.

      Klart3333Author
      New Participant
      May 20, 2021

      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
      Honored Contributor
      May 20, 2021

      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 🙂

        Anonymous
        May 20, 2021

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

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

        Anonymous
        May 20, 2021

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

         

        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.

        Klart3333Author
        New Participant
        May 20, 2021

        Thanks for the replies, it really helps 😄

         

        I guess I'll get to work optimizing then haha 

        Terms & ConditionsAccessibility statement