Search Unity

Question Help with Profiling Performance - Physics Jobs

Discussion in 'Physics for ECS' started by EternalAmbiguity, Jan 14, 2023.

  1. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    I'm not sure if this belongs here or elsewhere because it seems to involve Burst Physics Jobs. If it goes somewhere else, let me know.

    I have a game that uses entities for the enemies. They're on a grid system and they grow in an exponential manner (they don't really move, just individual entities grow). I've noticed some poor performance so I'm trying to profile to see what's wrong. See the two attached images.

    profiler_1.png profiler_2.png

    It looks like these physics jobs (CreateRigidBodies, PrepareStaticBodyDataJob, BuildFirstNLevelsJob, CheckColliderIntegrity, etc.) are taking the most time and I don't really understand what they're doing. When I look them up online I only find vague threads here--nothing explaining what they do and how one might optimize them.

    Currently using 2021.3.16f1. Burst is 1.8.2, Entities (and Physics) is 0.51.1-preview.21, and Jobs is 0.70.0-preview.7.

    Can anyone give any guidance on what these things are and how one might optimize them?
     
  2. KelvinHasAplan

    KelvinHasAplan

    Joined:
    Dec 25, 2018
    Posts:
    1
    I have the same issue. I created 140000 cubes with colliders but without rigidbodies. There's nothing else in the scene, but the CreateRigidBodies function is taking up a lot of performance. Has anyone made any progress on this?
     
  3. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    278
    @EternalAmbiguity : What is taking time here is the rebuilding of the spatial acceleration structure used in the broadphase for static colliders, which is an integral part in the engine's collision detection. Making any modification to static colliders, or adding or removing static colliders requires a complete rebuild of this structure in the current state of the engine.
    This is what's taking so long.

    If you don't touch them, then all is good and this acceleration structure is simply left untouched and the high time consumption you pointed out will simply disappear.
    Note that the same is true for dynamic colliders (aka, dynamically or kinematically moving rigid bodies) but there is a separate acceleration structure tree (the dynamic bounding volume tree) which needs to be rebuilt in this case, and it's separate from the acceleration structure for static colliders. So, if you have many static colliders that you don't manipulate, and you have a reasonable number of dynamic or kinematic rigid bodies that move, the overhead for keeping both acceleration structures up-to-date is very low, which is the ideal case.
    If you have many static colliders and you modify them, then you get the issue you are observing here.

    In this Unite 2022 video, my colleague Sebastian Schoener is talking about exactly this challenge that was also encountered in the development of V-Rising.
     
    Last edited: Apr 22, 2023
    EternalAmbiguity likes this.
  4. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    Okay, it sounds like the problem is occurring because I'm creating lots and lots of colliders in real time. Is that correct?

    I'll take a look at the video when I get the chance, but is there a solution to this issue?
     
  5. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    278
    @EternalAmbiguity : Are these colliders you are creating at run-time static or dynamic?

    In either case, if they are static they cause the static BV tree to be rebuilt from scratch. And if they are dynamic they cause the dynamic BV tree to be rebuilt from scratch.
    As it stands, you could create many upfront instead and then work with collision filters to disable their effect.
     
    EternalAmbiguity likes this.
  6. IsaacsUnity

    IsaacsUnity

    Unity Technologies

    Joined:
    Mar 1, 2022
    Posts:
    94
    Adding to @daniel-holz 's comment, we're also currently investigating ways to incrementally build the BVH tree such a complete rebuild is no longer required, which in theory should improve performance signfiicantly. This investigation is still pretty early in the process but happy to share more information as they become available.
     
  7. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
    I'm having an unrelated issue with 2022 where I can't run my project due to an error in an Entities-related package, but if that ever gets resolved I can take a look at bulk-generating colliders or something until there's a fix. Thanks.
     
    daniel-holz likes this.