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

Inspector

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.

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

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

19 Comments

Subscribe to comments

Comments are closed.

  1. David Galloway

    June 15, 2016 at 3:26 am

    Can you email me to discuss using this in Unity 5.4? Our project has HG access.

  2. 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.

  3. Anomalous Underdog

    June 10, 2016 at 12:10 pm

    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.

  4. Nicholas Francis

    June 10, 2016 at 11:36 am

    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

    1. Morten Skaaning

      June 10, 2016 at 12:09 pm

      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

    2. +1.

      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

  5. Bryan Livingston

    June 9, 2016 at 8:39 pm

    I can’t see any colliders or gizmos when I’m testing a game in VR.

  6. Robert Cummings

    June 9, 2016 at 8:24 pm

    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.

    1. 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.

    2. Morten Skaaning

      June 10, 2016 at 7:28 am

      it’s on the TODO list ;)

  7. can we have a shader complexity debuger

  8. 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.

    1. Morten Skaaning

      June 10, 2016 at 8:30 am

      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 :)

  9. 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!

    1. Morten Skaaning

      June 10, 2016 at 10:22 am

      hi,

      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?

      2) is planned ;)

      1. “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?”

        I don’t think a complete “resume the game” is what you should aim for. More like one static snapshot to debug in the editor.

        Use case could be to attach this snapshot to a bug (or embed it into a savegame during DEBUG-development) to enable the dev to analyze problems regarding physic setups.

        If a collider is not found in the editor while the snapshot is loaded, I recon you could just create a temporary object with the information needed to display the collider in your debug view..

  10. You can find some debug visualization improvements for 2D physics (and a whole host of other improvements) in the 2D experimental preview build over here: http://forum.unity3d.com/forums/2d-experimental-preview.104/

    I think it’s a good idea to try to bring some of these (3D) ideas across to 2D physics, especially the API!

  11. Please also add this for 2D Physics :)

    1. Morten Skaaning

      June 9, 2016 at 4:45 pm

      I’ll let Melvyn know ;)