ニュース
[CEDEC 2006#11]GPUによる物理演算処理の可能性
2006/09/01 22:54
Havok FXの解説を行ったNVIDIAのサイモン・グリーン氏
 物理演算は,オブジェクト同士の相互作用などからオブジェクトの動作を計算していくため,デザイナーが作成した動き以外の多彩なアクションが生まれ,これまでにないゲーム展開が可能になるなど,現在熱い視線を浴びている技術である。
 半面,複雑なシーンで自由度の高い構成を実現しようとすると,必要とされる演算量が膨大になるため,現状ではまだまだ限定的な使い方しかされていない。だが,CPUのマルチコア化や物理演算専用プロセッサの登場,そしてGPUによる物理演算の登場によって状況が変わりつつある。このセッションで解説されているHavok FXは,GPUを使って膨大な演算を行おうという意欲的な試みである。



■GPUでの物理演算処理

 現在,GPUは,非常に高度な並列演算能力を持つようになってきている。描画クオリティは実写に近付きつつあるが,オブジェクトの動作をリアルに保つには,モーションキャプチャの多用くらいしか有効な手がないのが実情だ。この場合,基本的にパターンアニメーションの垂れ流しなので,単調で応用が利かない。例えば,剣を振るっても相手の身体をすり抜けるだけだったりと,リアリティもインタラクティビティも低く,単に「絵が綺麗になっただけ」のゲームができあがることになる。もはや物理演算の本格的な導入は,ゲームを進化させるためには必須項目となっているといってもいいだろう。

 突出して画像品位が上がっているのに,物理演算がなかなか普及しないのは,主にCPUの演算能力に問題があるからだ。



 グラフを見ると一目瞭然だろう。CPUの演算能力として挙げられているPentium 4(デュアルコアPentium 4 Extreme Edition)はグラフを見ると30GFLOPS弱で,1クロックあたり4命令と換算しているようだ。

(4命令/クロック)×(クロック数)×(1命令/2クロック)×(2コア)

で計算していると思われる。この分野では,理論値には積和演算の値が使われることが多いので,その慣習に則ればさらに倍くらいの理論値となるのだが。まあ,いずれにせよあくまでも理論値だ。それに対して,NVIDIA GPUの値は実測値となっている。グラフ上の約10倍の差は,実際にはもっと広がると考えていい。
 とにかく,CPUの演算能力は遅々として向上しない。GPUは半年ごとに飛躍的に演算能力が向上していく。ピクセルシェーダ(Pixel Shader)などで使われる浮動小数点演算は,画像のクオリティを上げるために重要なものではあるが,例えば,その演算能力の1割を割くだけで,PC自体の演算能力は倍増することも分かる。余り気味のGPU演算能力(持て余す主な理由はCPUの演算能力不足によるわけだが)を物理演算に活用しようと考えるのは自然なことであろう。



 では,どのような処理がGPUでの物理演算に向いているのだろうか? 
 NVIDIAによれば,ゲームで多用されるリジッドボディ,すなわち剛体の演算はあまり向いていないという。それぞれさまざまな形があり,判定や挙動が複雑だったり,さらに相互作用が発生したりと処理が複雑になりがちである。それに対して,爆発の破片や爆煙といったパーティクルなどは単純で,流体や布(クロスシミュレーション)などの処理もGPU向きである。

 物理演算は,30日のHavokのセッションのところでも解説したように,

  衝突判定 → 衝突処理 → 積分(移動処理)→

といったループの繰り返しで実現されている。NVIDIAのサイモン・グリーン氏は,物理演算のうち衝突判定までの部分を,
  ブロードフェーズ
  ナローフェーズ

に分け,さらに,
  コリジョン
を加えた3種類に分割して解説していた。曰く,物体のどれとどれが衝突する可能性があるかを判定するブロードフェーズは,GPUでの処理には向いていない。具体的にどのオブジェクトとどのオブジェクトが衝突するかを判定するナローフェーズは,GPUでの処理に向いている。また,実際の衝突処理もGPUでの処理に向いているという。衝突演算は,最終的に2個のオブジェクト間の問題に分解できるので,そこまで分解したあとであれば,並列処理にも向き,GPUでの処理も容易となる。衝突後の物体の移動処理は,並列度が非常に高いので,GPUでの処理に向いている。

■Havok FX

 NVIDIAでは,2005年からHavokと共同で,GPU上での物理演算処理について研究を行っていたという。
 Havok FXは,特殊効果的な部分を担当するHavokのセットということになっているが,機能的には,

・リジッドボディ
 凸状コリジョンボディ
 安定スタッキング

・パーティクル
 コリジョン
 流体・クロス・その他


をサポートしており,通常のHavok Physicsとそう変わりはない。ただ,すべてのPC環境で使用が想定できるわけではないので,なくなったり,処理量が減っても問題のない特殊効果部分を中心に使っていくべきものだということだろう。
 パフォーマンスは圧巻で,CPUだけの処理と比べてちょうど10倍のフレームレートが実現されていた。

 SLI構成にしたところ,シングルGPU時の1.7倍の物理演算処理ができたというレポートもなされていた。NVIDIA的には,SLIで描画を行い,さらに1基グラフィックスカードを追加する構成が最高であるという。確かに,GeForce 7950 GX2とさらに1台のカードが売れれば,いろいろな意味で最高なのであろう(例として出ていた構成は,GeForce 7600を演算専用にするという控えめなものだったが)。
 また,オブジェクトのデータ自体をGPU上に持っていることから,オブジェクトの速度などといった情報を直接取り出せることもメリットの一つになってくるだろう。



流体表現の例。一応,屈折処理なども行っているが,基本的に粒子でできており,リアルな液体にはまだ遠い感じだ
 今後の予定では,壊れやすいものや,リアルな雲,煙,高度な流体処理などが挙げられている。破壊可能なオブジェクトは現在でも実現可能だが,どのように壊れるかなどは前処理で決められているものであり,リアルタイムに壊しているわけではない。これを自動化すれば,文字どおり「なんでも壊せる」ゲームも比較的簡単に作れるようになるだろう。
 一方,雲や煙ではボリューメトリックなレンダリングを導入することが考えられている。流体については,現状でもパーティクルベースのものは可能だが,AGEIAのデモと違って,界面がきちんと作られていない粒子状のものになっていた。これがDirectX 10のジオメトリシェーダが導入されることで,等値面抽出が可能になり,メタボール状の界面生成が可能になる模様(詳しくは別記事を参照)。さらに高度な流体表現についても今後研究が進んでいくことだろう。

 ちなみに,Havoc FXは,OpenGLで駆動されており,デモの描画はDirect3Dで行われていたという。
 少し説明が必要かもしれないが,GPUで演算を行う場合は,仕様上,実際に描画処理の手順を踏まなくてはならない。描画処理と結びついて各部が駆動されるので,GPU内部の演算器に直接データを渡してそこだけ駆動するといったことはできなくなっている。よって,演算に使うデータを渡したりシェーダプログラムをGPUにセットするには,3D描画APIを使うのが手っ取り早いのだが,どのAPIを使うかはあまり重要ではない。たまたまOpenGLが使いやすかったのだろう。

 また,デモでは,滝のように降り注ぐティーポットやチェスの駒の描画で,微妙にオブジェクトがプルプルと振動している場面もあった。これは,CPUでの演算では出ないバグで,GPU版でのチューニングが行われているところだという。GPU特有の問題ということだったので,演算精度の問題かと聞いてみたのだが,現状のHavok FXではFP32バッファを使った演算(32ビット浮動小数点演算)が行われているとのこと。CPUの内部演算でも,3DNow!やSSEなどのSIMD演算で主に使われるのは32ビット精度なので,精度的な問題はない。アルゴリズムはCPUで行う場合と変わらないので,単なるコーディングの問題のようだ。じきに解決されるものと思われる。
 また,精度の必要ない部分ではFP16も使用できるということで,この場合はかなりの速度が期待できそうだ。

 最初に「GPUで物理演算をする」と聞いたときは,ちょっとキワモノ系かとも思ったのだが,CPUの劇的進化が期待できないことや,逆にGPUの劇的進化が続くであろうことを考えると,かなり現実的なソリューションであることが分かる。2枚のグラフィックスカードを使用する環境が一般化することはなくても,GPUの一部で物理演算を行うことは,さほど非現実的ではない。それを考慮したゲームが登場してくるのは時間の問題だろう。今後登場するであろう,さらに進化したGPUでは,パワーの余力もさらに多くなっていくだろう。Windows Vistaの登場により,一般PCへも高性能なGPUが搭載されていくことになるだろう。そう考えると,GPUを使った物理演算の将来はとても明るいように思われる。今後の展開に期待しよう。(aueki)


ミドルウェア/開発ツール
■開発元:各社
■発売元:各社
■発売日:-
■価格:製品による

【この記事へのリンクはこちら】

http://www.4gamer.net/news/history/2006.09/20060901225459detail.html