Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    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. Let us know a bit about your interests, and if you'd like to become more directly involved. Take our survey!
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    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:
    261
    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:
    261
    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:
    23,350
    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