Search Unity

Game Developers Conference(GDC)2019 で 発表したとおり、Havok Physics が Unity のパッケージマネージャーでプレビューパッケージとして利用できるようになりました。つまり、現代のコンソール機で動く人気作品の半数以上に使用されているものと同じ物理演算ソリューションが、すべての Unity ユーザーにご利用いただけるようになったということです。今後、皆さまが物理シミュレーションを使う場面でさまざまなメリットが期待できます。

データが築いたパートナーシップ

私たちが Data-Oriented Technology Stack(DOTS)に基づいて将来の物理演算ソリューションの姿を定義することに乗り出したとき、私たちはコアとなるコンセプトと価値観を共有するパートナーが現れることを強く願っていました。Havok とのパートナーシップを通じて、私たちは DOTS を活用して、高度に最適化され、ステートレスですべて C# で書かれた、高性能の Unity Physics を実現することができました。しかし、もっと複雑なシミュレーションの要件を満たすために、ステートフルな物理演算システムを必要とするユーザーがいることも知っていました。そのようなハイエンドシミュレーションに対応するために Unity に搭載するソリューションとしては、Havok が最適であろうということがはっきりしてきました。

「分かったよ、でも、なぜ 1 つだけでなく 2 つシステムを作ったの?」と中には疑問に思う人もいると思いますが、ユーザーには多種多様なユースケースがあり、それぞれのニーズに応じてすべてのユーザーに選択肢を提供したいと考えています。Unity Physics で十分な人もいれば、Havok Physics の利点と強化されたワークフローが必要な人もいます。つまるところ、このブログの投稿で後ほど説明するように、正しい選択も間違った選択もありません。すべてのコンテンツを完全に再作成することなく、ソルバーを切り替えることも可能です。

Havok Physics 統合

パフォーマンス

Unity の Havok Physics 統合は、Unity Physics と同じ C# DOTS フレームワークを使用して記述されており、かつ、ネイティブ C++ で記述されたクローズドソースのプロプライエタリエンジン Havok Physics を基盤としています。Havok Physics は、典型的なゲームでのユースケースにかなり寄せた最適化がなされています。コアとなるアルゴリズムは長い年月をかけて改良されており、各種自動キャッシング戦略(非アクティブなオブジェクトのスリープなど)により、必要な場面でのみ CPU リソースが消費されます。

動作

Havok Physics は、物理的なインタラクションが多数組み込まれた緻密なシーンが含まれている、最もダイナミックなゲームのパフォーマンス需要に対応するよう設計された、堅牢な物理演算エンジンです。 20 年以上にわたり、ゲーム業界の幅広いパートナーと連携して仕事をする中で、Havok はリアルタイムの物理シミュレーションにまつわる最も困難な部類の問題に数多く直面し、その解決に向けて繰り返し取り組んできた実績があります。

この取り組みにより、特に最適化されていない衝突ジオメトリを受け取ったときに、物理ボディのスタッキングが安定し、動きの速いボディがあるときのアーティファクトが最小限に抑えられ、一般的に動作をより細かく制御できます。

Havok Physics のスタッキングの安定性を示す例

Havok Physics は、さまざまな状態情報をキャッシュしてインテリジェントな最適化を実行するため、大規模(オープンワールドなど)ゲームで優れたパフォーマンスを実現できます。さらに、Havok Physics では高度な摩擦モデルを使用して、重なっているオブジェクトやエンドレスなスタックを扱うことによって高い安定性も提供します。

Unity Physics(右の例)は重なっている静的/動的なリジッドボディを1フレームで解決することを試みます。一方、Havok Physics(左の例)は数フレームにわたってスムーズに解決します。

可視化とデバッグ

Havok Visual Debugger(VDB)のアプリケーションは、Havok 物理演算シミュレーション向けの堅牢なデバッグツールです。TCP/IP を介してアプリケーションに接続すると、複雑な動作やパフォーマンスの問題、クラッシュなどをリモートで診断できます。接続中、アプリケーションは VDB のユーザーが解決したい問題にあわせてオン/オフを切り替えられる多くの機能を公開します。設定によって、アプリケーションは接続された VDB クライアントに情報を提供するサーバーも作成できます。

Havok Visual Debugger UI

Visual Debugger は、Havok Physics を搭載したゲームを開発するチームとって不可欠なツールです。モジュール化されたビューアーではユーザーの用途にあわせて、以下の機能を自在に組み合わせて利用できます。

  • 一時停止しスクラブして、シミュレーションの以前のインタラクションに戻る
  • グラフィックスと文字情報を併用してパフォーマンスの統計情報を調べる
  • 物理世界でリジッドボディを構成するコライダーを表示する
  • ボディ間のジョイントおよび接触を表示する
  • 経時的にボディのモーションパスを視覚化する
  • 動的ボディの(非)アクティベーションステータスを確認する
  • シミュレーションのヒートマップを確認して、処理負荷が高く、最適化が必要な領域を素早く特定する
  • 物理シミュレーションと直接インタラクションする

VDB クライアントは、レビューのためにシミュレーションの以前のスナップショットを記録、保存、およびロードすることもできます。開発者が複雑な物理シナリオを容易にデバッグするために外部サポートを必要とする場合、これらのスナップショットは非常に貴重なリソースとなります。

2 つの物理エンジン、1 つのデータフォーマット

前述したように、DOTS Physics に取り組み始めたときの主な目標の 1 つは、あらゆるシミュレーションのバックエンドにわたり使用できる単一のデータ表現を持つことでした。統合されたエディターのデータレイアウトを提供することにより、開発者はシミュレーションバックエンドに依存しない形でツールやゲームプレイコードなどを書くことができます。すべてのコンテンツを再作成することなく、ニーズに合ったシミュレーションのバックエンドを使えるようにするために、クリエイターにその制御をお任せするようにしたのです。下記の図は、データレイアウトのモデルを説明しています。

DOTS の物理データのフロー

ご覧のとおり、データはオーサリングからシミュレーションシステムに流れます。ルートレベルで、オーサリングデータをシステムに依存しないように抽象化します。これにより、両方のシミュレーションバックエンドで同じツールとユーザー体験を作成できます。その後、これは Unity の変換パイプラインによって Entity Data に受け渡されます。Entity Data バケットには、PhysicsCollider、PhysicsVelocity、PhysicsMass、PhysicsDamping、PhysicsGravityFactor、PhysicsCustomTags などの実行時コンポーネントがあります。これらは Build Physics World システムに渡されます。このシステムは、連続アクセス用に最適化されたデータをランダムアクセス用に最適化されたデータに変換する 2 番目の変換ステップとして機能します。このシステムは、現在の時間におけるワールドの状態のクエリに使われる Collision World と、現在の時間ステップにおける物理演算をシミュレートするために必要なすべての情報を保持する Dynamics World を生成します。これらの世界を分離することにより、Step Physics World が Dynamics World に保持されているデータを更新すると同時に Collision World でクエリ操作を実行し、スレッドの使用率を最大限に高めることができます。

図に示されているように、Unity Physics と Havok Physics はパイプライン全体を通して同じデータを共有します。そのため、統合されたコンテンツパイプラインだけでなく、システムに依存しないデータプロトコルと API サーフェスの利点も得られます。2 つの異なるバックエンド間を移動するのは簡単なプロセスです。

DOTS Physics の開発の推進にあたって、これらすべての物理演算システムで統合されたオーサリング体験を維持しながら、Unity がさまざまなユースケースに対応する豊富なシミュレーションバックエンドを提供できる未来を構想しています。

再生モードにしたまま物理演算バックエンドを切り替え

Havok Physics を始めよう

ここまで我慢強く読んでいただいた方は、「もう技術的な専門用語はたくさんだよ。それで、どうやったら Havok Physics を入手できるの?」と思っておられる頃だと思います。それならご心配なく、Unity Package Manager(Unity 2019.1以降)から Havok Physics 統合をプレビューパッケージとしてダウンロードすることができます。また、Havok Physics for Unity のドキュメントを読むこともできます。

チームと連絡をとったり、問題を提起したり、Havok Physics で作成したクールな作品を公開したい場合は、新しい DOTS Physics フォーラム を訪問してください!

25 replies on “Unity の Havok Physics”

Regarding the smooth interpenetration in Havok: isn’t it pretty much trivial to implement in Unity physics too? I mean, PhysX has also had it for as long as I can remember…all it takes is to clamp the impulse to a user-defined maximum if the objects start the frame overlapped…

I’d delete the post, but it’s not an option.
So I’m replying to negate the previous post.

Okey, so am I understanding this correctly? Since the built in physics engine is so bad we will now have to pay to get a decent one in our projects, instead of improving the existing one?

This is a huge step in the wrong direction. On top of that, Unity will also become more expensive next year… I am very disappointed.

Hey Lex, when you say built-in are you referring to Unity Physics? PhysX? If you’re referring to Unity Physics are there situations or simulation effects that aren’t meeting your needs with the current functionality? Would be happy to know more about where Unity Physics might be falling short for your needs.

After knowing Havok Physic has a higher quality, better tools and faster performance than Unity Physic, I doubt anyone will use Unity Physic for serious users.

However, there are couple of important questions remains.

1. How much does Havok Physics cost?
2. How does it compare to PhysX, both features and performance-wise.

No one will jump on the wagon without knowing the answers to the questions above. And the answers are…

Hey Chris, great questions. We’re still working out the pricing details and I’ll make sure that gets communicated when they’re finalized. Regarding performance, I do have some breakdown of feature parity between the systems. Performance is another beast entirely since PhysX is not integrated with DOTS it’s a bit of apples vs oranges comparison. Happy to provide more details in the forum though if that would be useful for you.

I think we’d all find that information useful. Would you inform us where to find this thread ?
Thank You Shawn
(I tried to reply a moment ago, but the post isn’t showing.. `in case you see two posts)

Unity development team: having several programming languages for plethora of different use cases is unacceptable, costly and time consuming to maintain, and enforce just one language on everyone (C#). There is no point to keep multiple languages if in the end they do almost the same thing! Every choice of any other language but C# is wrong, period!
Also Unity development team: there is no right or wrong choice, our users have plethora of different use cases, so let’s add multiple physics engines! We have plenty of time and resources to maintain different physics which work mostly the same! Having choices is great!

Can we get some sort of chart or graph comparing the feature and performance differences between Havok, DOTS, and PhysX?

All these things outlined above sound great, but how do they actually compare to PhysX? Why would someone want to move their project from the built-in PhysX to Havok? What limitations of PhysX does Havok overcome, and vice versa?

None of these things are clear in the article.

Hey, these are great questions. Realistically speaking, you wouldn’t move from PhysX to Unity/Havok Physics unless you were also making the transition to our Data Oriented Technology Stack (DOTS). If you’re building a project on DOTS, then Unity/Havok are the currently available physics backends for DOTS-based projects. PhysX continues to exist for current MonoBehaviour based projects. Because of this difference in architecture, it’s more difficult to make an apples to apples comparison between PhysX performance and Unity/Havok. That being said, there are definitely comparisons we can make between Unity/Havok that are part of the first video in the post that outlines some key performance benefits Havok has over Unity Physics.

Pricing is the big question. Right now it seems our options are
* Physics engine that is unusable because it can’t even do stacking and items never come to rest
* An OK physics engine that nobody can afford

Exactly, a step backwards. Pricing should be free – as in paid by part of your subscription package if you use plus/pro. There should be 1 good physics engine.

I was wondering. With the new physics engines, can we have a high frequency physical simulation ? (I’m thinking 250hz to 500hz even 1000Hz maybe) ? I not that’s not usually needed for visual rendering, but for haptics it can be really useful

Hey Flonou, this isn’t currently possible though we are investigating having a system where the physics can simulate at a fixed rate that is independent from the normal update loop.

It would’ve been nice to get a direct comparison between both of the DOTS physics engines and PhysX, because even 6ms for that scene doesn’t sound too optimistic.

Maybe I’m just missing something and Unity Physics always had similar performance to PhysX, but that just reassures me that such a comparison is necessary.

Comments are closed.