Search Unity

今日は、衝突が起こるか起きないか判断するために手早くシーン内の衝突ジオメトリを確認したい時に役立つものをご紹介します。これは、RenderメッシュとColliderメッシュの同期が外れた際によく問題になることです。この状況を改善するために、物理衝突ジオメトリ用のデバッグビューモードを開発中です。これによってCollision Layerを素早く調べ、問題を見つけることができます。

  • 5.4に更新: 5.4 beta 23ベースの新しいエディターのビルドが入手できるようになりました。これは最新のベータ版なので、プロジェクトを開く前にバックアップすることを忘れないようにしてください。

また、このツールによって、衝突ジオメトリを持つGameObjectを詳細な確認・修正のために素早く選択することも可能になります。物理パフォーマンスの問題をデバッグするときにシミュレーション中のRigidbodyをハイライトすることもできます。

是非このエディタービルドをお試しになり、シーン内を見渡してみて、便利だと感じられた部分や改善が必要な部分についてご意見をお聞かせください。このビルドはUnity 5.3.4p4をベースに開発されていますので、ほとんどの皆さんのケースで安定して動くはずです。公式なリリース時期は未定ですが、準備が整えば、旧バージョンのUnityへの移植も行える可能性は高いです。

image2016-4-27 16-16-8

インスペクター

image2016-4-27 16-16-0

シーンビューへのオーバーレイ

このビューモードは、PhysX Visual Debugger (PVD)の軽量版にGameObjectやAssetをUnity上で直接選択できる機能が追加されたものと考えることもできます。簡単に使えるようにすることがこのビューモードを作った最大の目的です。PVDはUnityとは使い勝手の違う独立したアプリケーションなので、扱いが難しい場合があります。一部のバージョンのPVDでは大きなTerrainにおいて、操作が遅くなるというパフォーマンスの問題もありました。

今後も、以下のような機能追加を考えています。

  • 個々のColliderコンポーネントの選択
  • Layerごとにユーザーが色を定義できる
  • 接点の表示
  • レイキャスト、オーバーラップテスト、スイープの表示
  • カーソルをColliderの上に置いた時に、より多くの情報(Layerなど)を表示する
  • Mayaのような視点を光源としたシェーディングによって、曲面をわかりやすくする
  • タイムラインの記録と移動
  • ネットワーク対応
  • より多くのレンダリングの制御をスクリプトから可能にする
  • 選択されたRigidbodyが衝突しているColliderの表示
  • 選択されたコライダーが送受信するTrigger/Collideメッセージの表示

C# API:

  • 下記のAPIはエディタ上でのみ使用でき、プレイヤー上では使用できません。
  • クラス名は”PhysicsVisualizationSettings”から “Physics.DebugVisualization”に変更予定です。

制限事項

  • Cloth、Joint、WheelColliderには未対応です。
  • TerrainCollider で Enable の切り替えを何度も行うと、ランダムに選ばれたレイキャストの失敗が発生します。
  • 複数のシーンビューを使用している場合、効果的に選択を行えるのは最後のシーンビューのみになります。
  • Tree Colliderは、地形上にカーソルがあっても一本一本のツリーをハイライトしません。
  • 矩形選択は未対応です。

19 コメント

コメントの配信登録

コメント受付を終了しました。

  1. David Galloway

    6月 15, 2016 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

    6月 10, 2016 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

    6月 10, 2016 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

      6月 10, 2016 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

    6月 9, 2016 8:39 pm

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

  6. Robert Cummings

    6月 9, 2016 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

      6月 10, 2016 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

      6月 10, 2016 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

      6月 10, 2016 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

      6月 9, 2016 4:45 pm

      I’ll let Melvyn know ;)