2
\$\begingroup\$

So I have this large forest of around 2M tris:

enter image description here

Same chunk selected with view on the whole level:

enter image description here

It's been generated within Blender and exported as fbx into Unity. Exporting each tree as an individual object is very performance expensive so the whole forest is split into 2 Objects: Treetrunks and leaves. The Treetrunks all have meshcolliders on them, the leaves obviously don't. (However I do split the forest into chunks as seen above, each chunk roughly 400k tris)

When the Player gets outside visible range of the forest it is disabled, and enabled when the Player gets within a certain range. When it is enabled sometimes it causes a massive lag. When looking into the Profiler it shows this:

enter image description here

Physics? FixedUpdate? The leaves have absolutely no colliders on them, why does it take up Physics.Processing? So I wanted to search further what part of Physics.Processing takes up so much processing time but the top process already shows nothing:

enter image description here

I have an 8 year old GTX760 but it still manages to render the entire forest at 200fps so no, the 2 million Tris are definitely not overkill for my computer.

I've tried this and that and 3 things managed to stop the issue (as seen in the profile screenshots above, the Physics processing time significantly reduced a few frames later)

  • Pausing & Unpausing the game or simply Alt-Tabbing outside the Unity Player and back (not always effective)
  • Disabling the Player & Reenabling it (almost always effective)
  • Starting the Scene with the Player (including Rigidbody, Camera and raycasting scripts) disabled and enabling him a few seconds later via script. (almost always effective) However this only worked if ALL of the forest was set active (roughly 2M tris). If half the forest was disabled on start, and activated after the Player was enabled: LAG.

The Player is the only thing in the game (at this moment) that has a Rigidbody, Raycasting Scripts and a camera.

Things that didn't work:

  • Waiting a few minutes
  • Disabling & Reenabling the Players Character Controller at any time
  • Disabling & Reenabling the camera on the Player at any time.
  • Disabling & Reenabling the fucking trees

Anyone got an idea? I'm dumbfounded over here.

\$\endgroup\$
5
  • \$\begingroup\$ That much mesh collider sounds like trouble. Are you able to sufficiently approximate some/parts of your tree trunks with simpler colliders like capsules? I don't see the massive lag you're describing in the profiler though — it looks like you're consistently under 10 ms per frame, with the physics step taking less than 3 ms of that time — quite good for a scene of this complexity I'd say! Are you perceiving a stall or stutter beyond the 100 fps framerate shown here? \$\endgroup\$
    – DMGregory ♦
    Commented Aug 6, 2019 at 13:33
  • \$\begingroup\$ I don't know what it is about people saying mesh colliders are expensive. I can slap a mesh collider on an object with millions of polygons and it doesn't change the frames at all. Anyway, it's not the tree trunks that cause trouble. I can disable them and the problem persists. Yes, once the lag stops I am indeed under 10ms, this is because I merge equal materials into a single object whenever I can. All the buildings have been created within Blender on the go and all trees have been generated within existing materials & UV maps \$\endgroup\$
    – AzulShiva
    Commented Aug 6, 2019 at 13:44
  • \$\begingroup\$ @DMGregory I don't know why the Profiler sais I'm at 10ms, the Statistics in the Game view say I'm at 15fps, and it feels like I'm at 5. Once the Orange Physics thing in the Profiler goes down I'm back at 100fps+. Profiler is clearly bugged there \$\endgroup\$
    – AzulShiva
    Commented Aug 6, 2019 at 13:45
  • \$\begingroup\$ Do you experience this in a built executable too? It could be some overhead of updating editor representations somehow. \$\endgroup\$
    – DMGregory ♦
    Commented Aug 6, 2019 at 13:59
  • \$\begingroup\$ Yes it happens too in the executable. In the executable you cannot get rid of it by Alt-tabbing or anything \$\endgroup\$
    – AzulShiva
    Commented Aug 6, 2019 at 14:03

1 Answer 1

Reset to default
1
\$\begingroup\$

I reduced the Polygon count on each object to below 65536 and it removed all issues. Don't know wether 65536 is the magic number here, but it's certainly one of the most common "magic numbers" so I went with it. Maybe someone can explain why.

\$\endgroup\$
1
  • \$\begingroup\$ Interesting result. There are a few possible explanation on the wiki page on 65,536. \$\endgroup\$
    – disc_code22
    Commented Jan 9, 2020 at 14:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .