私は最近、シミュレーションとゲーム開発用のいくつかの物理エンジンを比較しました。無料のものもあれば、オープンソースのものもあれば、商用のものもあります (1 つは非常に商用の $$$$ です)。Havok、Ode、Newton (別名 oxNewton)、Bullet、PhysX、および一部の 3D エンジンの「生の」組み込み物理演算。
ある段階で、結論または質問に至りました: GPU 処理による驚異的なパフォーマンス (必要な場合) を利用できるのに、NVidia PhysX 以外を使用する必要があるのはなぜですか? 将来の NVidia カードでは、通常の CPU 生成手順とは別に、さらなる改善が期待できます。SDK は無料で、Linux でも利用できます。もちろん、これはベンダーロックインであり、オープンソースではありません。
あなたの意見や経験は？今すぐ開発を始めるとしたら、上記に同意しますか?
乾杯
免責事項: 私は PhysX を使用したことがありません。私の専門的な経験は、Bullet、Newton、および ODE に限られています。これら 3 つの中で、ODE は私のお気に入りです。これは数値的に最も安定しており、他の 2 つには成熟度の問題があります (便利なジョイントが実装されていない、合法的なジョイント/モーターの組み合わせが未定義の方法で動作するなど)。
質問でベンダーロックインの問題をほのめかしましたが、繰り返す価値があります: PhysX を唯一の物理ソリューションとして使用すると、AMD カードを使用している人々はゲームを実行できなくなります (はい、そうすることができることはわかっています)。仕事、ただし、公式ではなく、NVIDIA によってサポートされていません)。これを回避する 1 つの方法は、AMD カードを搭載したシステムで ODE などを使用して、フェールオーバー エンジンを定義することです。これは機能しますが、作業負荷が 2 倍になります。共通のインターフェイスの背後にある 2 つのエンジンの違いを隠し、ゲーム物理コードの大部分を一度に記述できると考えるのは魅力的ですが、ゲーム物理に関する困難のほとんどは、特定のエンジンの特異性に対処することです。接触摩擦や反発などの値を決定する物理エンジン。これらの値は、物理エンジン全体で一貫した意味を持たず、(ほとんどの場合) 正式に導出することもできないため、見栄えがよく、再生可能な値を実験で見つけるのに苦労しています。PhysX とフェールオーバーを使用すると、すべてのスカット作業を 2 回行うことになります。
より高いレベルでは、ストリーム処理 API のいずれもまだ完全に完成しているとは思いません。少なくとも、Intel の Larrabee に対する顧客の反応がどのように人々を形作っているかを確認するまでは、API をコミットするのは気が進まないでしょう。デザイン。
これまでのところ、PhysX がハイエンド ゲーム開発の明らかな選択肢であるとは考えていませんが、AMD カードを使用しているユーザーがプレイヤー ベースのかなりの割合を占めていると思わない場合 (可能性は非常に低い)、または2 つの物理エンジンをテストするのに十分なコーディングと QA の人員が必要です (もっともっともらしいですが、あなたの会社がそれほど裕福な場合は、Havok について良いことを聞いたことがあります)。または、ストリーミング物理のみが満足できるパフォーマンス要求が非常に高い物理ゲームを設計した場合は、バンドを立ち上げてムーアの法則に 1 年間任せることをお勧めします。または2つ。
2013 年初頭の更新の回答: Linux、OS X、MS の 3 大 OS と見なされるものを開発しています。また、3 つの物理ライブラリ (PhysX、Havok、Bullet) を使用して開発しています。
PhysX に関しては、私は最近、この記事の執筆時点で最新のバージョン 3.2.2 でいくつかのテストを行いました。私の意見では、nVidia はライブラリの有効性を本当に低下させました。最大の問題は、剛体の加速不足です。lib はパーティクルとクロスのみを加速します。それらでさえ、一般的な剛体とはインターフェースしません。nVidia がこれを行っていることに完全に困惑しています。なぜなら、nVidia は GPU アクセラレーション アプリを推進する巨大なマーケティング活動を行っており、物理シミュレーションを大きな推進力とする科学計算に焦点を当てているからです。
したがって、物理シミュレーションの王様は PhysX、Havok、Bullet の順であるという私の期待は、実際にはその逆に見えます。Bullet は、OpenCL サポートのサンプルを含む lib 2.8.1 をリリースしました。Bullet は、寛大なライセンスを備えた比較的小さなライブラリです。彼らの目標は、OpenCL リジッド ボディ アクセラレーションを完全に統合したリリース 3 を用意することです。
コメントの一部では、複数のコード パスについて説明しています。私の意見では、これは大したことではありません。私はすでに 3 つの OS を最小限のハード コード サポートでサポートしています (ほとんどの部分でスレッド化が行われ、OS 固有のコードは使用せず、C++ と std lib テンプレートを使用します)。物理ライブラリも同様です。共有ライブラリを使用し、共通のインターフェイスを抽象化します。物理はあまり変わらないので、これで問題ありません ;) シミュレーション環境を設定し、オブジェクトを管理し、環境内で反復をレンダリングし、終了したらクリーンアップする必要があります。残りはフラッシュで、余暇に実装されます。
メインストリーム ライブラリに OpenCL が登場すると (nVidia Cuda は非常に近いです。Bullet OpenCL のデモを参照してください)、物理プラグインの作業は縮小されます。
それで、最初から始めて、物理モデリングだけに関心がありますか? Bullet なら間違いありません。小規模で柔軟なライセンス (無料)、本番環境対応の OpenCL に非常に近く、OS と GPU の 3 つのソリューションにわたるクロス プラットフォームになります。
幸運を ！
これは興味深いかもしれません：
http://www.xbitlabs.com/news/video/display/20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html
それは偏っています...基本的にはAMDとのインタビューです...しかし、あなたの場合に検討する価値があると私が思ういくつかの点を示しています.
David Seiler が指摘した問題のため、将来的に物理エンジンを切り替えることは、大きな/克服できない問題になる可能性があります.特にゲームプレイが物理に密接に結びついている場合.
そのため、エンジンでハードウェア アクセラレーションによる物理演算が今すぐ必要な場合は、Physx を選択します。不愉快な選択に直面する：
1) 使用するエンジンを書き直して (新しいクロスプラットフォーム ハードウェア アクセラレーション物理エンジンの名前を挿入)、ゲームのダイナミクスを悪い方法で変更する可能性があります。
2) Physx のみを使用し続け、AMD ユーザーを完全に無視する
3) Physx が AMD GPU で動作するようにします (blech...)
フォールバックとして CPU 物理エンジンを使用するという David のアイデア (2 倍の作業を行い、同じように動作しない 2 つのエンジンを生成する) を除けば、唯一の選択肢は純粋な CPU 物理を使用することです。
ただし、OpenCL のようなものが主流になると、ODE/Bullet/kin がそれを組み込み始めるのを見るかもしれません... IOW ODE/Bullet/kin を使用してコーディングすると、GPU アクセラレーションを「無料」で取得できる可能性があります (おそらく最終的にはそうなるでしょう)。後で (コードに変更はありません)。GPU バージョンでは動作が若干異なります (バタフライ効果と浮動小数点の実装の違いにより避けられない問題です) が、少なくとも ODE/Bullet/kin コミュニティと協力してそのギャップを減らすことができます。 .
これが私の推奨事項です。現在 CPU のみを使用するオープン ソースの物理ライブラリを使用し、それが OpenCL、CUDA、ATI のストリーム言語などを介して GPU を使用するのを待ちます。それが発生すると、パフォーマンスが急速に向上します。頭痛の種を救ってください。
私はODEを使用しており、現在はPhysXを使用しています。PhysXはシーンの構築を容易にし、(私の個人的な意見では) より現実的に見えますが、PhysXに関する適切なドキュメントはありません。実際、ドキュメントはほとんどありません。一方、ODEはオープン ソースであり、多くのドキュメント、チュートリアルなどがあります。PS: GPU アクセラレーションを使用することは、私と私の同僚にとって非常に役立ちます。APEX破壊とPhysXパーティクルを使用しています。
将来のgfxカードの仮想的なメリットはすべて良好ですが、追加のCPUコアによる将来のメリットもあります。将来のgfxカードが常にあなたの物理学のための予備の容量を持っていることを確信できますか？
しかし、この場合は少し曖昧ですが、おそらく最良の理由は、パフォーマンスがすべてではないということです。他のサードパーティライブラリと同様に、今後何年にもわたってそのコードをサポートおよびアップグレードする必要があります。インターフェイスが適切であり、ドキュメントが適切であり、その機能を備えていることを確認する必要があります。必要とする。
より安定した方程式の解法を提供するいくつかのAPIなど、より数学的な懸念もあるかもしれませんが、それについては専門家にコメントを残しておきます。
PhysX は非 nVidia カードで動作しますが、高速化されません。他のエンジンが開始するのと同じ位置に置いておきます。問題は、ハードウェア物理アクセラレーションでのみ機能する物理シミュレーションがある場合です。
すべてのコードが非常に並列化可能である場合は、それを実行してください。
他のすべてについては、GPUはひどく不十分です。