[[物理エンジンの解説]]
*物理エンジンの解説
物理シミュレータQ&A
物理シミュレータについて聞かれて答えたことをまとめてみました．できるだけ，事実を書こうとしていますが，思い入れや思い込みもかなりあります．ご了承ください．
**Springheadについて
***GJKについて
-Q: 接触面を求めるのに、法線による近似をされていますが、精度の上でどこまで正確なのでしょうか?ゲームの場合、物理法則に関しては、アバウトな表現が許されますが表示系は相当シビアな物が要求されます。着地物の接触面などでめり込み等は無いでしょうか?
-A: GJKはある程度正確に(10^{-6}程度の精度で)計算できますが，ペナルティ法は，本質的にめり込みが起こります．めり込みを減らすには，バネ係数を大きくすれば良いですが，時間刻みを短くする必要があります．
GJKの論文： E.G.Gilbert,D.W.Johnson,S.S.Keerthi:“A fast procedure for computing the distance between complex objects in three-dimensional space ”,IEEE Journal ofRobotics and Automation 4(2),pp.193 ‐203,1988
GJKのフリーの実装： SOLID私もこれを参考にして作りました．
衝突判定エンジンのリスト
-Q: 他のエンジンはどの様な方法を取っているのでしょうか? 力技で計算しているだけなのでしょうか?特別なアルゴリズムは存在するのでしょうか?
-A: それほど力技ではありません．いろいろとうまい方法を考えて作っている人がいます．有名なのはUNCのI-CollideとGJKです．これらはどちらも凸多面体の性質を使って高速化しています． SOLID3?やSWIFT++?のように非凸形状をサポートしたエンジンもあります．
面ベースペナルティ法の処理速度
-Q: 面によるペナルティー法を推奨されていますが、点に比べて、処理が重いのでは無いでしょうか?ゲームの場合でも実用的な処理能力が確保できるでしょうか?
-A: Springhead物理エンジンの英語版の論文の最後の方に，処理別の処理時間を示しました．解析はそれほど重くないようです．積分の方に時間を取られていますがここはまだまだ最適化できると思います．
点ベースでの高速化がよいのでは？
-Q: 点に基づくペナルティ法での不安定性の解決方法で体積ベース以外の方法はないか気になりました。(計算量と安定性のトレードオフになるかと思いますが...)
-A: あると思いますが，精度が落ち，コードが複雑になるわりに，高速化しないのではないかと思っています．
シミュレーションの時間ステップ
-Q: フィジックス処理は300Hz〜1kHzで動作させる必要がある様ですが処理間隔が短ければCPU占有率が上がるかと思います。 SpringheadとODEの処理比較をタイムスライス10msで行っていますがフレームレートを下げた場合に双方の精度はどこまで実用に耐えられるでしょうか?
-A: 私の感覚では，Springheadは100Hzです．かなり柔らかくなってしまいますが．ODEは30Hzでも大丈夫だと思います．その場合の計算量はODEの方が少ない場合が多いと思います．ただ，ODEはプリミティブだけなので，メッシュを高速に扱えるかどうかわかりません． Springheadは動きの自然さの方を重視しています．
-Q:フレームレートが高くないと精度が低くなる問題はどの程度の条件で発生するのか? (オブジェクトの侵入が大きいときに精度が下がる場合の発生率)
-A:Springheadの場合，物体同士に力がかかった場合に，お互いに侵入してしまいます．衝突がおき，力が働けば必ず発生します．
ベンチマーク的デモ
-Q: ODEやtokamakと比べて場合 ode の test_crash や tokamak の sample8やsample9の様にゲーム向きのデモが無い為ライブラリー自体の安定性や、どの程度の事が出来てパフォーマンスがあるかが判りません。複数のオブジェクトが発生している、ゲーム向きのデモは無いでしょうか?
-A: デモもWebページに多数置いてあります． デモのパック の，demo/Pachinko.bat は物体数が多めです．もっと沢山の耐久試験的なものはまだありません．（作るべきですね）
**物理エンジン一般について
***ゲームに向いた物理エンジン
-Q:どのエンジンがよいか
-A: Havok，ODE，Springhead でしょうか．ODEは衝突判定にMeshを使えない（機能はあるがまだ安定していない）という問題があります．また，Havok・ODEとも摩擦力や物が止まる寸前の動きの自然さはいまいちです．Springheadは計算量が少し多いです．
私は，将来的には計算量はあまり問題にならなくなって，使いやすいエンジンが求められると思っています．Springheadはペナルティ法なので，他のエンジンとの整合性が良いです．たとえば流体や気体のエンジンとの協調動作も他の方式に比べて簡単だと思います．
物理エンジンがゲームの世界の質感というか味付けというかを左右してしまうこともあると思います．必ずしも1つのエンジンに絞り込むのではなく，ソースがあるものを上手に取り込みながら，独自のエンジンを作っていくのが良いと思います．
ペナルティ法は原理が単純なため，いろいろと応用が利くので，他の方法を取り入れるにしてもベースに持っておくと良いと思います．たとえば Monsters, Inc. は David BaraffというODEやHavokの方式の元を考えた人がかかわって作った映画ですが，服飾や一部の剛体の運動，パーティクルなどにはペナルティ法を使っています．
-Q:で，結局どっちがいいの？解析法？ペナルティ法？
-A:
フリーな剛体を沢山扱いたいたいなら，解析法．
力覚インタフェースと直結するならペナルティ法
静止摩擦・動摩擦を正確に扱いたいなら，ペナルティ法
人体などの関節モデルを沢山扱いたいならFeatherstone法＋ペナルティ法~
けれども研究は止まっていないので，これは今(2004.9)，私が把握している範囲の話です．
-Q:ソースを入手すべきか？
-A:私自身は，ソースを理解して使うか，自分で書くかのどちらかにしています． Springheadの場合は，キーとなるエンジンが，
接触判定 (GJK)
接触体積計算 (quick hull) の2つなのですが，GJKはSOLIDというエンジンのソースをほぼそのまま使いました（といっても100行程度）． QuickHullは当初qhullというエンジンを使用していましたが，処理速度が遅いので，スクラッチで作り直しました．
ライブラリだけというのは良くないと思います．ユーザが物理について学ぶ機会を逸してしまうからです．商用のものであってもソースと，出来ればアルゴリズムの解説も手に入れたほうが良いと思います．
ページ一覧