Debug view mode for physics collision geometry

We want to help you quickly inspect the collision geometry in your scene to decide whether collisions should or shouldn’t happen. This is usually an issue when the Render mesh and Collider mesh get out of sync. So we’re making a debug view mode for physics collision geometry, which will allow you to quickly see through Collision Layers to find out where the issues are.

5.4 Update: A new Editor build is available, based on 5.4 beta 23. This is the bleeding edge untested beta, so remember to backup your projects before opening them.

The tool also enables the user to quickly select GameObjects that own the collision geometry, for further inspection or changes. It can also highlight simulating Rigidbodies for debugging physics performance issues.

Please give this Editor build a try, explore your scenes and let us know what you find useful and what needs improving. The build is based on Unity 5.3.4p4, so it should be stable for most users. We don’t know yet when it will be a part of an official Unity release, but once ready, we think we have a good chance of backporting it to older Unity versions as well.

Inspector

Scene View overlay

The view mode can be considered light version of the PhysX Visual Debugger (PVD) with added advantage of being able to select GameObjects and Assets directly inside Unity. Ease-of-use was our primary motivation for making the view mode. PVD can be tricky to work with because it is a separate application with different UI/UX conventions. Some versions of PVD also has performance issues with large terrains, which prohibits responsive navigation.

Here are some ideas for what we want to add to the tool in the future:

Selecting individual Collider components.

User defined colors per Layer.

Show contact points

Show raycasts/overlap tests/sweeps

Show more information, like Layer, when hover over a Collider.

Improve curvature information by doing light-from-viewpoint shading, like in Maya.

Timeline recording and scrubbing.

Network support.

Expose more render control to user scripts.

Show which Colliders a selected Rigidbody collides with.

Show which Trigger/Collide messages will be be sent or received from a selected Collider.

C# API:

The following API can only be used in the Editor, not in Standalone players.

The class name is expected to change from «PhysicsVisualizationSettings» to «Physics.DebugVisualization».

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

publicclassPhysicsVisualizationSettings

{

publicstaticvoidReset();

// properties

publicstaticboolshowCollisionGeometry;

publicstaticboolenableMouseSelect;

publicstaticbooluseSceneCam;

publicstaticfloatviewDistance;

publicstaticintterrainTilesMax;

publicstaticboolforceOverdraw;

publicstaticboolshowStaticColliders;

publicstaticboolshowTriggers;

publicstaticboolshowRigidbodies;

publicstaticColor staticColor;

publicstaticColor rigidbodyColor;

publicstaticColor kinematicColor;

publicstaticfloatbaseAlpha;// (1 - transparency)

publicstaticbooldevOptions;

publicstaticintdirtyCount;

publicstaticboolGetShowCollisionLayer(intlayer);

publicstaticvoidSetShowCollisionLayer(intlayer,boolshow);

publicstaticvoidUpdateMouseHighlight(Vector2 pos);

publicstaticvoidClearMouseHighlight();

publicstaticboolHasMouseHighlight();

}

Limitations:

Cloth, Joints and WheelColliders are not supported yet.

Toggling Enable on a TerrainCollider many times causes random selection raycast failures.

When using multiple Scene Views, only the last Scene View can effectively do picking.

From what I understand, this is a separate mode separate from the usual way of showing colliders. But I’d like it if these ways to show collider geometry are also used on the collider gizmos themselves (on a per gameobject-basis). For example, as it is, colliders are always shown in that green outline kind of thing but sometimes I want to see them with faces and rendered transparent. Sometimes, I want them hidden (whenever I have the gameobject selected) because they make it hard to see the mesh for that gameobject.

Would be nice if boxcolliders (and by extension most other primitive collides) weren’t drawn as triangle meshes — a quick way to visually scan for MeshColliders is critical when you’re performance optimizing

Yes, we can simplify the information we show.
We could also make button for inclusion of Convex Meshes. Since general triangle meshes cannot be used for Rigidbodies in Unity 5, only Convex Meshes would actually contain triangles

I’m always in favor of having more tools at my disposal, and this looks pretty cool. However, from the video it’s not entirely clear to me what the role of this tool is during development how useful it will be over the life of a project. The primary information it provides at the moment is ‘oh, there’s a lot of stuff in my scene, maybe I can remove some of it’. That can be nice, but I can also search for t:collider, change the shading mode, and select all in the Hierarchy to get the majority of that information in a very rudimentary way. (Granted, selecting a large number of objects in Unity is unreasonably chuggy).

On my current project (3 years, 6 people, heavy use of physics) we simply haven’t had many problems with objects colliding or not colliding with each other unexpectedly. The few times it has happened it was o matter of 1) check the layer on object A, 2) check the layer on object B, 3) check the collision matrix, 4) change one of those. Also worth noting is that most of our objects are instantiated at runtime, so any tool is going to have to work at runtime (which I assume this would because of the mentioned scrubbing feature). I’m also concerned about performance at scale. A lot of editor functionality tends to become cripplingly slow in large projects (the profiler, asset server, even basics like selecting objects, duplicating selection, inspecting objects with large chunks of serialized data). If this can’t be used when there are thousands of colliders in the scene (where I would want to be reducing numbers the most), it’s going to be hard to get a lot of mileage out of it.

Personally, I’m much more interested in identifying performance and configuration problems related to physics. Physics is a black box where designers throw in content and we all wonder which of the thousands of props are contributing most heavily to multi-millisecond physics updates. This isn’t a problem I’ve sat down and tried to solve yet, so maybe there are already good tools for this, I don’t know.

I would definitely like to be able to see things such as
— Approximately how much time / relative time is a particular object costing in physics update? Both as an individual object, and across all copies of it.
— Warnings for objects that are configured in a way that makes them unstable or unnecessarily heavy.

My idea was to be as unintrusive as possible. When you need a debugger then you are already invested in achieving something specific. Having to search, manage selections, changing render modes and then interpreting the results would use distract users instead of helping them immediately. A separate view mode also allows us to add more information, like visualizing contacts.

The code in this build already is able to show 30.000 colliders at a decent framerate. If you run into performance issues, please let me know. The code appears in the profiler as «Physics.DrawAllPhysxActors» so you can check if it becomes slow.

Making «perfect» cause-and-effect relationships with physics performance is difficult because almost all systems (scene setup, user code, Unity code and PhysX code) can interact to create unique workload scenarios.
We *can* create a lot of helpful information, like show all the simulating objects in a scene, or show all the contact points generated for the solver, or add a «cooldown glow» to colliders that are added/remove/teleported.

If you encounter scenarios with particular bad performance, please let us know :)

Aside from «Please do it for 2d physics»… what about two features I could imagine would be helpful:

1. dump/restore of binary-snapshots, accessible by script. So a script could have the current physics state dumped to some byte array which then can be File.WriteAllBytes or whatever.. Then this snapshot can be fed back into the editor using some restore function.

2. some editor tooling to do raycasts and overlap tests on the current physics screen. (This can be coded entirely in C# using scene view handles, so its kindof optional if you guys do it or let the community take care of that ;).

Both things just pop up in my mind of what I might found big use in the past — not anything mission critical. ;) Keep up the good work!

I was considering something like 1) for timeline scrubbing. I was wondering how you would deal with Colliders created on-the-fly?
If you want to resume a state loaded from a binary wouldn’t you almost need to serialize the whole scene?