Physics Profiler module

The Physics Profiler module displays information about the physics that the physics engine has processed in your Scene. This information can help you diagnose and resolve performance issues or unexpected discrepancies related to the physics in your Scene. For more information on debugging physics in your application, see the documentation on the Physics Debug Visualization.

Chart categories and module details pane

The Physics Profiler module’s chart tracks the time your application spends on physics. The timings are divided into seven categories. To change the order of the categories in the chart, you can drag and drop them in the chart’s legend. You can also click a category’s colored legend to toggle its display.

When you click on the chart, you can see the exact numerical values of each chart category in the module details pane below the chart.

The numbers displayed in the Profiler might not correspond to the exact number of GameObjects with physics components in your Scene. This is because Unity processes some physics components at a different rate depending on which other components affect it (for example, an attached Joint component). To calculate the exact number of GameObjects with specific physics components attached, you must write a custom script with the FindObjectsOfType function.

The Physics Profiler module does not show the number of sleeping Rigidbody components. These are components which do not engage with the physics engine, and are therefore not processed by the Profiler. For more information on sleeping Rigidbody components, see the documentation on Rigidbody.

Using the Physics Profiler to understand performance issues

The physics simulation runs on a separate fixed frequency update cycle from the main logic’s update loop, and can only advance time via a Time.fixedDeltaTime per call. This is similar to the difference between Update and FixedUpdate. For more information on this, see the documentation on the Time window.

When a heavy logics or graphics frame takes a long amount of time, the Profiler has to call the physics simulation multiple times per frame. This means that an already resource-intensive frame takes even more time and resources. This might cause the physics simulation to temporarily stop according to the Maximum Allowed Timestep value, which you can set in the Project Settings window (menu: Edit > Project Settings > Time)

To detect this in your Project, select the CPU Usage Profiler module and check the number of calls for Physics.Processing or Physics.Simulate in the Overview section in the Hierarchy view.

In this example image, the value of 1 in the Calls column indicates that the physics simulation was called one time over the last logical frame.

A call count close to 10 might indicate an issue. As a first solution, reduce the frequency of the physics simulation, and if the issue continues, check what might have caused the heavy frame before the physics engine had to use a lot of simulation calls to catch up with the game time. Sometimes, a heavy graphics frame might cause more physics simulation calls later on in a Scene.

For more detailed information about the physics simulation in your Scene, select the search box at the top of the module details pane, search for Physics.Processing, and then select Show Calls from the dropdown at the top right of the pane. This displays the names of the physics engine tasks that run to update your Scene. The two most common names you’re likely to see are:

• Pxs: short for ‘PhysX solver’, which are physics engine tasks that joints require as well as resolving contacts for overlapping Rigidbodies.
• ScScene: used for tasks that update the Scene, run the broad phase and narrow phase, and integrate Rigidbodies (moving them in space due to forces and impulses). For more information, see Steven M. LaValle’s work on Planning Algorithms for a definition on two-phase collision detection phases.