Unity 5の高性能物理演算

ANTHONY YAKOVLEV / UNITY TECHNOLOGIESContributor
Jul 8, 2014|8 分
Unity 5の高性能物理演算
このウェブページは、お客様の便宜のために機械翻訳されたものです。翻訳されたコンテンツの正確性や信頼性は保証いたしかねます。翻訳されたコンテンツの正確性について疑問をお持ちの場合は、ウェブページの公式な英語版をご覧ください。
Unity 5.0での3D物理の変更点をいくつか紹介したいと思います。

しばらくPhysX 2.8.3を使用しています。私たちは、純正のPhysXをそのまま使うだけでなく、Unityのエンジニアが何年もかけて作った数多くのパッチで拡張しています。久しぶりです。PhysX 2のおかげで魚がたくさん釣れました。GDC'14で発表されたように、Unity 5.0はPhysX 3.3へのアップグレードを備えています。詳しく見てみよう。

PhysX SDK 3は、旧来のPhysX SDK 2.xを抜本的に再設計したものです。基本的に、PhysXチームは2.xから最良のアイデアと最良のアプローチを取り入れ、SDK全体をゼロから書き直しました。つまり、コードベース全体が異なり、すべてのインターフェイスが異なり、ほとんどの機能が異なるということだ。

それでは、Unity 5.0の物理演算の使用感を味わっていただきましょう。

まずはシンプルに、アダプティブ・フォースをスイッチで切り替えられるようにし、デフォルトではオフにした。アダプティブフォースは、スタックをシミュレートする際の数値誤差を補正するためのPhysXの特別なテクニックです。しかし、Unity開発者からのフィードバックによると、アダプティブフォースはゲームコンテンツ全体の不安定性に大きく寄与しているとのことです。今後、スタック的なものがより良い挙動を示すことを期待したい。

スタティック・コライダーの移動

スタティック・コライダーを移動させれば、コストは大幅に下がる。Static Colliderは、Rigidbodyコンポーネントを持たない、コライダー・コンポーネントを持ったゲームオブジェクトです。以前は、SDKがスタティック・コライダーを移動させないことを前提としていたため、スタティック・コライダーを移動させると高価なAABBツリーの再構築が発生し、全体的なパフォーマンスに大きな影響を及ぼしていました。

Unity 5では、動的コライダーと静的コライダーの両方の動きを処理するために同じデータ構造を使用します。残念ながら、スタティック・コライダーがダイナミック・コライダーよりも少ないメモリー消費で済むという利点は失われる。しかし今現在、Static Collidersの移動に関連するコストは、Unityゲームのパフォーマンス問題のトップ3に入ります。私たちはそれを変えたかった。

衝突検知

連続的な衝突検出は1桁向上した。連続衝突検出は、高速で移動する車体が衝突を検出せずに他の車体を通過するのを防ぐために使用される。紙切れに弾丸を撃ち込んだり、あるボールが他のボールより速く動くビリヤードゲームを想像してみてほしい。

Unity 5.0では、SDKが高速移動の処理に必要なすべてのデータを生成します。連続衝突判定を有効にすればうまくいく。PhysX3には、現在のボディ速度から、高価なCCDシミュレーションが本当に必要なのか、それともデフォルトのディスクリートで十分なのかを検出するアルゴリズムが搭載されています。CCDを有効にすると作動する。

プールテーブル
ブロードフェイズ上のリジッドボディ

PhysX3はブロードフェイズ上でより多くのリジッドボディをサポートしています。実際、デスクトップやデスクトップに似たプラットフォームでは、1つのフレームに数十万のボディを載せることができるだろう。以前は、ボディには64kの固定制限があった。それは、簡単に増やせるような定数ではなく、SDK全体のビットを大幅に節約した結果だった。プレイステーション3など、一部のゲーム機ではこの制限が残っている。この記事を書いている時点では、どのプラットフォームでも64k以上のマテリアルを持つことはできない。

メッシュ・コライダーズのスケーリングは無料です(多かれ少なかれ)。

Unity 5.0では、メッシュコライダのスケーリングコストを削減しました。以前は、メッシュコライダーをスケーリングする場合、頂点にスケールをベイクした新しいメッシュを作成する必要があり、貴重な時間とメモリを必要としていました。PhysX3では、ベーキングなしで非負のスケーリングをサポートすることができます。基本的に無料だ。

次に、Unity 4.xバージョンと大きく異なる2つのサブシステム(布と乗り物モジュール)を見てみましょう。

布製部品

まずは布から。Unity 4の布シミュレーションは、InteractiveClothとSkinnedClothコンポーネントでサポートされています。InteractiveClothは、布のようなメッシュビヘイビア、つまり「物理的な布」を持ち、他の物理ボディと相互作用したり、力を加えたりすることができる。InteractiveClothは計算コストが高いので、Unity 4ではキャラクタの衣服用にSkinnedClothという別のものが用意されています。

SkinnedClothはメインのシミュレーションパイプラインから切り離されているため、InteractiveClothよりも優れたパフォーマンスを発揮できる。布の主な問題は、どちらの部品も非常に不安定で、コストがかかることだった。PhysX3の統合に伴い、私たちはInteractiveClothのサポートをやめ、キャラクターの服装を念頭に置いてデザインされた、シンプルにClothと呼ばれる1つの布コンポーネントのみを用意することにしました。

Unity 5.0では、Clothはシーン内のすべてのコライダに反応しなくなりました。その代わりに、より高速で、マルチスレッドで、より安定したキャラクターウェアのソリューションがある。これを追加すると、新しいClothコンポーネントはいかなるボディにもまったく反応しなくなる。

したがって、手動でワールドからクロス・コンポーネントにコライダーを追加するまで、クロスとワールドはお互いを認識することも見ることもできません。その後でも、シミュレーションはまだ一方通行だ。布はそれらのボディに反応するが、力を戻すことはない。さらに、布には3種類のコライダーしか使用できません。球体、カプセル、円錐形のカプセルのコライダーで、2つの球体コライダーを使って構成します。これらの変更はすべて、パフォーマンスを向上させるために導入されたものだ。

Unity 5.0のオーサリングインターフェースはSkinnedClothのものと似ています。5.xのサイクル中に、Mecanimのアバターとの統合などが追加されることを期待している。

新しいClothコンポーネントは、内部的にCUDA経由でGPUをサポートしていますが、いくつかの理由から、5.xサイクルの後半にリリースすることにしました。まず第一に、CUDAはNVIDIAハードウェア上のWindowsでしか動作しません。第二に、私たちはバグフィックスの努力をまずコアなものに集中させ、その後に派手なものの統合に移したいと考えている。

新しい車両SDK

さて、車について少し。PhysX3には新しいVehicle SDKがあり、それを使ってWheelColliderコンポーネントを実装しました。この新しいコンポーネントは、サスペンションとタイヤのフリクションをよりリアルに再現している。加えて、その他多くの長年の問題も修正されている。

Unity 5.0では、新しいコンポーネントをすぐに使用して、シンプルなビヘイビアを生成できます。デベロッパーがアセットストアのビークル・パッケージを購入するのは、Edyのビークル・パッケージのように、すでに微調整され、リアルで、高度なものが欲しいときだけだと思う。

ウェブからダウンロードした無料のメッシュを使って、2、3時間でセットアップできたものを見てほしい(その時間のほとんどはBlenderでモデルを準備するのに費やした):

そしてこちらはEdy's Vehicle PackageのSUVの1台:

Edyは現在、彼のパッケージの新バージョンに取り組んでいる。詳細は本人に直接問い合わせを

このクルマに関する素晴らしい技術的な詳細については、皆さんにお伝えしたいことがたくさんありますが、今は、新しいWheelColliderのギズモを見てみましょう。これによって、サスペンションがどのように機能するかを知ることができる。

ホイールギズモ

上の図では、ホイールサークルとホイール直径が緑色で、サスペンションのトラベルセグメントがオレンジ色で、力点球が緑色で示されている。サスペンションのトラベルセグメントには、最大圧縮位置、最大下降位置、目標位置のマークがあります。

ご想像の通り、ホイールは最大圧縮位置と最大垂下位置の間を移動することしかできない。目標位置(専門用語ではレストポジションとも呼ばれる)は、バネで吊り上げられた重量がバネ力と釣り合う位置にある。チューニングが難しいように思えるかもしれないが、実は、最大圧縮位置はメッシュの中でホイールが元々位置している場所なのだ。

次に、サスペンションの距離と目標位置をサスペンションの距離の端数で指定する。たった2つの浮き輪がすべてを支配するだけで、大したことはない!新しいホイールギズモは、箱から出してすぐにシミュレーションデータから回転とポジションを更新するようになったことは話したかな?実際のホイールのジオメトリを追加したり、ホイールの位置決めコードを書いたりしなくても、設定をプレビューできる。すべて組み込まれているんだ。

パフォーマンス

PhysX3は、内部計算モデルが異なるコアで実行可能なタスクで構成されているため、マルチコアで動作する準備が整いました。SDKはすべてのマルチスレッド処理を行い、すべての依存関係を自ら管理し、最適なジョブ分解を行う。

これまで見てきたところでは、より優れたコードベースと改善されたマルチスレッドの結果として、一般的にパフォーマンスが2倍になると予想するのが妥当だろう。場合によっては、最大で10倍という劇的な改善もある。

より多くのデータに興味のあるパフォーマンス・ニンジャは、ピエール・テルディマンのブログをご覧いただきたい。彼はPhysX SDKのコア開発者だ。

互換性

新しい関数は見た目も使い勝手もUnityに似ているが、動作が異なるケースやパラメーターの意味が異なるケース、場合によっては古い動作がサポートされなくなったケースもまだある。したがって、Unity 5.0の物理演算はUnity 4.xと100%の互換性がありません。以前のUnityリリースから移行する場合は、古いプロジェクトを再調整し、物理コードの一部を書き直す覚悟が必要です。

Unity 5の物理については、この記事で紹介しきれないほど多くの詳細があります。また、今年のUnite 2014開発者会議に参加される方は、Unity 5.0の物理に関する私の詳細な講演を聞いて、挨拶やおしゃべりをしに来てください。

ユニティ5の詳細