Search Unity

  1. Unity 2019.1 beta is now available.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We're looking for insight from anyone who has experience with game testing to help us better Unity. Take our survey here. If chosen to participate you'll be entered into a sweepstake to win an Amazon gift card.
    Dismiss Notice
  4. On February 28th the Feedback website will shut down and be redirected to the Unity forums. See the full post for more information.
    Dismiss Notice
  5. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  6. Unity 2018.3 is now released.
    Dismiss Notice
  7. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Profiling - Physics.Processing self time is over 1 millisecond!

Discussion in 'Physics' started by Zergling103, Oct 12, 2018.

  1. Zergling103

    Zergling103

    Joined:
    Aug 16, 2011
    Posts:
    276
    Currently, we're trying to optimize our game. We noticed in the profiler that 1.26 milliseconds is being taken up by the sample named "Physics.Processing". This cost is listed under "Self MS", and distinct from "Total MS", it doesn't include any of its children samples' time. For example, this doesn't include the cost listed under the "PhysX.PxsSap.sapUpdateWork" sample nor any of its sibling samples.

    I'm using Unity 5.6, but this cost may still happen in newer versions of Unity. This is also measured from a build, not in the editor.

    What is happening in the Self MS of Physics.Processing? I really need to get cut down this 1.26 MS.

    The curious thing about our project is, while we have a lot of colliders, virtually all colliders are supposed to be stationary. In fact there are only a handful of non-static, kinematic rigidbody box colliders which we intend to allow to move around. You'd think that PhysX wouldn't really need to process much if virtually all of the colliders in the scene are perfectly still.

    Knowing what happens in this sample could help me narrow down what is causing PhysX to barf.

    It might be worth noting that Physics.Simulate takes almost no time to compute.

    Listed here are the noteworthy Self MS costs associated with physics that we're currently struggling with:

    - 1.26 - Physics.Processing
    - 0.87 - Physics.FetchResults
    - 0.48 - PhysX.PxsSap.sapUpdateWork
    - 0.25 - PhysX.PxsSap.sapPostUpdateWork
    - 0.13 - PhysX.PsxAABBManager.aggregateOverlap
    - 0.11 - Physics.Raycast
    - 0.11 - Mesh.Bake Scaled Mesh PhysX CollisionData
    - 0.10 - PhysX.ScScene.broadPhase

    - 3.31 - Total
     
    Last edited: Oct 12, 2018
  2. Zergling103

    Zergling103

    Joined:
    Aug 16, 2011
    Posts:
    276
    So, we've determined that one of the conditions necessary to produce the slowdown was this:

    A single character controller being activated and deactivated every frame. Without this, the cost from physics per frame dropped to 0.3 ms.

    It might not be the only necessary condition (i.e. it may not be sufficient to produce the slowdown) as we have several thousand colliders in the scene. But nonetheless it is extremely odd that a single character controller activating and deactivating could cause so much damage.

    I'm not sure what to do as this per-frame deactivation and reactivation was necessary to fix a bug with the character controller.
     
  3. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    24,488
    When you enable and disable colliders, the collider is not hidden but destroyed and created. The character controller is not using colliders though, it's a bunch of casts.

    Don't have enough information to help. There's been a few bug fixes over time.

    Also I'd prefer a screenshot of profiler data, you don't list the number of calls and other relevant data either so I'm just guessing.

    Is this relevant?
    https://issuetracker.unity3d.com/is...dot-processframe-causing-degraded-performance