Search Unity

Unity 2019.3 ベータ版 で、Unity に組み込まれている PhysX にかなり多くの更新が行われます。これにより、現在の Unity 組み込みの PhysX がより正確、高速、そしてよりロバストに動作するようになります。

私たちは PhysX ライブラリを PhysX 3.4 から PhysX 4.1 にアップグレードしました。詳細については、NVIDIA の PhysX 4.1 SDK Guide にある「Migrating from PhysX SDK 3.4 to 4.0」セクションをご覧ください

新しいソルバータイプ

Unity 2019.3 で、Temporal Gauss-Seidel と呼ばれる新しいソルバータイプを公開しました。このソルバーは、Physics カテゴリーの Edit > Project Settings 下でご利用できます。この新しいソルバータイプでは、ジョイントのオーバーストレッチやさまざまな不具合に対する耐性が高まる傾向にあります。

新しいブロードフェーズタイプ

さらに、Automatic Box Pruning と呼ばれる新しいブロードフェーズアルゴリズムを公開しました。これは、しばらくの間利用可能であった Multibox Pruning アルゴリズムに似ていますが、現在ではワールド境界と細分化する量を自動的に計算ができるようになりました。グリッドセルのセットを維持し、通常の Sweep And Prune アプローチを使用して重なる可能性のあるコライダーのペアを見つけ出します。これは、単一の Sweep And Prune が必要以上に多くの誤検出を引き起こすような大きなシーンで役立てることを目的としています。このモードは PhysX 4.1 のデフォルトのブロードフェーズアルゴリズムですが、Unity への導入に際しては保守的なアプローチをとり、デフォルトでは無効にしてあります。お試しになりたい方は、Physics 設定の Broadphase Type を変更して有効にしてください。

新しいミッドフェーズ

ミッドフェーズは、物理クエリを実行したり、コライダーがメッシュの表面に接近したりしたとき、メッシュに交わる可能性がある三角形の小さな集合を選択する一連のデータ構造とアルゴリズムです。メッシュが多数の三角形で構成されており、そのすべての三角形に対して正確なチェックを実行せずに済むようにしたいというアイデアに基づき、アルゴリズムがチェックする価値がある小さなサブセットのみを選択できるような加速構造を構築します。

この加速構造は、物理演算のメッシュベイク処理中に構築されます。これは通常、MeshCollider コンポーネントをインスタンス化し、その sharedMesh プロパティを割り当てるときに発生します。その構造の構築には時間がかかる可能性があり、その時間を最小限に抑えることは一定の価値があります。古い PhysX では、このプロセスで費やされた時間の大部分は R-Trees の構築に費やされていました。

PhysX 4.1 では R-Trees を必要としない新しいアルゴリズムが構築されています。ただし、現時点では、Windows、Mac、および Linux のみでしか実行できないという欠点があります。デスクトッププラットフォームでは新しいアルゴリズムが自動的に使われますが、Cooking OptionsCooking Options ドロップダウンメニューから MeshCollider ごとに無効にすることができます。サポートされていないプラットフォームでは、自動的に古いミッドフェースアルゴリズムにフォールバックします。

メッシュを遅延およびマルチスレッドでベイク処理する

前述したように、新しい MeshCollider のインスタンス化には時間がかかる場合があります。2019.3 の物理演算では Physics.BakeMesh 関数を使用して MeshCollider で使うための Mesh のインスタンスを事前にベイクすることが可能です。ロード待ち画面や、アドベンチャーゲームの会話シーンやカットシーンのような画面遷移シーンの背後で、計算量の大きいメッシュのベイキング処理を行うことができます。

この関数に付随して現れる興味深い現象は、メインスレッドから実際に関数を呼び出すことができ、そのような方法で利用可能なすべてのコアにベイキングの負荷が分散されることです。C# Job System で使用する方法の例については、ドキュメントを確認してください

TerrainCollider の厚みの削除と一本化されたハイトマップ設定

Unity 2018.3 で TerrainCollider のよりロバストな接触生成パスへの切り替えを行い、また接触生成アルゴリズムにも変更を加えました。この新しいアルゴリズムは、接触の計算を行うときにハイトマップのジオメトリを扱う特別なパスを使う代わりに、接触しているハイトマップの一部分をメッシュとして扱い、通常のメッシュとの接触を生成するコードを利用します。ただし、古いコードも当面残され、Enable Unified Heightmaps オプションを有効にすることで引き続き利用可能でした。

Physx 4.1 へのアップデートに伴い、Enable Unified Heightmaps オプションが削除されます。これに基づいて、Terrain コンポーネント内のプロパティで使用可能だった厚さ設定も削除されます。地形の厚みは、高速で移動するオブジェクトが検出されずに地形の表面を通過するトンネリング効果を解決することを目的とします。厚みがなくなったので、代わりに、Continuous Collision Detection を使用することをお勧めします。

Kinematic の再挿入

キネマティックな Rigidbody がキネマティックでない Rigidbody に変わると、物理エンジンは衝突検出のためにその Rigidbody をブロードフェーズの木構造に再挿入します。これにより、追加の OnTriggerEnter イベントが発生します。

 

私たちは Unity における PhysX の統合の完成と安定化に注力してきましたが、このアップデートにより、精度、安定性、およびパフォーマンスを向上させたいと思っています。 Unity 2019.3 ベータ版を入手しましょう。お試しいただいたら、フォーラムでぜひあなたのご意見をお聞かせください!

25 コメント

コメントの配信登録

返信する

これらの HTML タグや属性を使用できます: <a href=""> <b> <code> <pre>

  1. Any news regarding concave objects with rigidbodies and more than 255 polygons like it is at the moment ?
    In my company, since we really need concave objects without approximations, we are currently bypassing this limitation by cutting our objects in sub-objects, which really is a pain.

  2. When will the basic feature of having the contacts BEFORE resolved available? Why would anybody want to get the contacts after they are resolved? Any info (penetration distance, speed, etc) is not useful afterwards. We want to anticipate the resolution stage, just as PhysX lets us, so we can CHANGE what it will do. Add additional impulses, forces, changes, or even avoid the contact by chaning the other collider.

    1. I want to stress that too, I always complained about that, it killed one project

    2. Agreed. This is 100% must-have feature.

  3. Paulo Veríssimo

    10月 24, 2019 5:32 pm 返信

    What’s new or updated in wheel Colliders in the 2019.3 PhysX upgrade?

    1. Anthony Yakovlev

      10月 24, 2019 8:20 pm 返信

      There are plenty of changes in the SDK itself, but we didn’t get any new features exposed, unfortunately. One little thing that will get back-ported soon-ish is that flag that limits the force applied by the wheel to the car body due to spring damping, available since PhysX 4.1.1.

  4. Cool stuff. But, with Havok coming to Unity I’d really like to know what’s the main reason I’d pick one physics engine over the other. Can you guys make an article comparing between PhysX and Havok? Like a pros and cons?

    1. PhysX is the physics engine used for games when the game code is written with GameObjects / MonoBehaviours.
      Havok or Unity.Physics is used when the game code is written in Unity.Entities.

      Generally speaking Havok is significantly faster and has significantly better simulation stability. But of course given that DOTS and the packages surrounding it are in preview, the choice is really less about do you want to use physx vs havok but rather about do you want to use DOTS for your game code or stay with a stable proven game object / monobehaviour based solution.

      1. Christian Brandoni

        10月 25, 2019 11:15 am 返信

        Joachim, will game object / monobehaviour eventually be phased out in the future after DOTS become stable or you will keep advancing both?

        1. I think many Unity developers have this same question. I think it would be really clear to anyone if they would say if Dots will replace GameObjects one day or just be another solution to choose from. I have the same concerns back then when Flash was going to die but everyone was about talking around it. We all know what happened, so I think being more clear about Dots and MonoBehaviour situation would help a lot. =)

  5. Cloth physics continue failing since many versions ago.

  6. Great updates, thanks!

  7. More perf is always welcome, thanks!

  8. Tristan Bellman-Greenwood

    10月 22, 2019 9:01 pm 返信

    Do these changes have any effect on raycast queries?

    1. Anthony Yakovlev

      10月 23, 2019 10:58 am 返信

      As usual with the PhysX upgrades, some portion of the query engine received a bit of a facelift that allowed to return more accurate results when it comes to thin colliders, large meshes, etc. Performance won’t be affected significantly in this area.

  9. The link to https://t.co/vWIQ64yVqG shows a 404.

    1. Anthony Yakovlev

      10月 23, 2019 11:07 am 返信

      Not sure where this link is supposed take you, but I’ve discovered that the code sample I posted externally and linked to has expired. I should have probably put it on github really. However, it’s now available as part of the API docs, here: https://docs.unity3d.com/2019.3/Documentation/ScriptReference/Physics.BakeMesh.html

  10. “This will cause an extra OnTriggerEnter event”

    This is very dirty, was this necessary? I can’t imagine a case where this does not introduce unwanted behaviour.

    1. I agree, it seems like it’ll cause trouble. I’d like to know more about the rationale of this decision.

    2. And you’ll be lucky if you remember having read this blog post to understand where the unwanted behavior is coming from.

    3. Its really not that difficult to catch the first event and ignore the second, it really shouldnt impact you.

      1. Yeah, it is not difficult. It is ugly though. It adds a nice touch of amateurism.

    4. Anthony Yakovlev

      10月 23, 2019 11:09 am 返信

      This is a change in PhysX SDK itself, not sure it’s possible to roll back really. However, we rolled back trigger-trigger events deprecation for now.

  11. Christian Brandoni

    10月 22, 2019 3:35 pm 返信

    By the way what happened to the manual update of the Physics simulation?
    Has it ever be implemented?

  12. Christian Brandoni

    10月 22, 2019 3:34 pm 返信

    Nice Update.
    I’m a bit worried about this:
    “This will cause an extra OnTriggerEnter event.”
    Isn’t this breaking backward compatibility?