Search Unity

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.

image2016-4-27 16-16-8


image2016-4-27 16-16-0

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.


  • 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”.


  • 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.
  • Tree Colliders don’t highlight individual trees when hovering over terrains.
  • Drag-rectangle-to-select is not supported.

19 replies on “Debug view mode for physics collision geometry”

Was actually going to request for a 2D physics, glad BTSTONE mentioned it. this seems like it will be very useful to understand where certain issues might be happening in terms of collision.

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


Funny story about this getting misinterpreted: When I showed a colleague the video, he said: “Oh my god, look at these triangles.. I didn’t know Capsule collider are that expensive” :-D

Hi guys,

This is useful, yes. But to be truly useful could we have debugging for raycasts as well? It’s a solid pain to try and figure out what your swept shape is doing, or debug a SphereCast :)

Just a nice addition I think.

Seconded, I’d love to be able to check AI and physics helper Raycasts with something like this, especially if each ray can be visually tied to the object that sent it.

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.

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!

Comments are closed.