REYESレンダリングのリアルタイム実装が実現するか
TIM SWEENEY氏がこう予見するのには、彼ならではの経験則があるからだ。
1998年のUnreal Engine1.0(UE1)は100%のCPUベースのソフトウェアレンダリングが実装されており、ここには現在のレンダリングパイプラインになってやっと実装されたような機能が10年前に既に実装されていた。例として挙げられたのは制限なしのリアルタイムカラーライティング、ボリュームフォグ、タイルレンダリング、遮蔽検出など。1998年当時、こうしたフィーチャーをフル稼動させて、60MHzのPentiumでも320×200ドット、毎秒30コマ(30fps)で1ピクセルあたり16命令程度の処理が行えたとしている。
1998年のUE1は100%のCPUベースのソフトウェアレンダリングが実装されていた |
2012年以降のCPU & GPU統合型プロセッサであればソフトウェアレンダリングであっても現行のGPU以上の表現が可能なはず |
2012年、プロセッサの進化がこのままムーアの法則に則って、CPU & GPU統合型プロセッサが現実のものとなった場合、演算性能は4テラFLOPSに到達し、UE1ベースのレンダリングパイプライン相当をソフトウェア実装したとすると1920×1080ドットのフルHD解像度、60fpsで、1ピクセルあたり16000命令程度の処理が行えるはずだとTIM SWEENEY氏は見積もる。
1ピクセルあたり16000命令が費やせて、しかも現存の固定的レンダリングパイプラインに囚われないレンダリング手法としてはどんなものが考えられるのか。TIM SWEENEY氏は、未来の100%ソフトウェア・レンダリングパイプラインの姿がどうなっていくのか、について語り出す。
第一に、ピクセルシェーダのステージでのレイトレーシングの活用がより進むだろうと予見する。現状のレンダリングパイプラインでも局所的なレイトレーシング(レイキャスティング含む)を実装している例もあるが、ソフトウェアレンダリングであれば、複数のバッファに対して任意にアクセスが可能となるので、現状ではなかなか実装が難しい大局照明や相互反射的な表現の実装も可能となることだろう。
2012年以降のCPU & GPU統合型プロセッサであれば、レイトレーシングをベースにしたソフトウェアレンダリングパイプラインを実装することも可能。実際、ゲーム向けのレイトレーシングをリアルタイム実装する研究は行われている |
第二に、現在は、映画向けCGなどに採用されているオフラインレンダリングのパイプラインのリアルタイム実装を行うというアイディアだ。TIM SWEENEY氏が例として挙げたのは、「TOY STORY」で知られるPIXARが考案したレンダリング・アーキテクチャで、PIXARのRENDERMANの基本システムとして採用されている「REYESレンダリング」モデルだ。
これはシーンで取り扱う全ての3Dモデルを多ポリゴンで取り扱い、レンダリング時には3Dモデル側をレンダリング解像度のピクセル以下のマイクロポリゴンへと分解する。
これは、実質的にはLOD(Level of Detail)システムに相当するのでゲームエンジン側でのLODシステムの実装がいらず、現状レンダリングパイプラインにおける頂点シェーダ・ステージでのディスプレースメントマッピングや、ピクセルシェーダ・ステージの法線マッピングが不要になる。
ライティングとテクスチャリングはこのマイクロポリゴンに対して行われることになる。つまり、この仕組みでは、テクスチャは、その多ポリゴンの3Dモデルに対応したものを用意しておくだけでMIPMAPは必要なくなるので、テクスチャマッピングにおけるブラーやエイリアシングから解放されることになる。
全く新しすぎるレンダリングパイプラインはノウハウの蓄積やツールなどの開発環境整備の問題があるが、REYESレンダリング法はオフラインレンダリングの世界で広く活用されているため、この技法がリアルタイム実装されたときには、トップダウン式に様々な"テクニック"や"支援ツール"が降りてくることだろう。
ポリゴンをラスタライズしてピクセルに変換するのではなく、ピクセル以下にポリゴンを分割するという発送のREYESレンダリングシステム |
REYESレンダリングであれば、LODシステムの実装が不要でさまざまなエリアシングの問題から解放される |
現状のレンダリング・パイプラインでは、実体のないオブジェクトのレンダリングは、一度3Dポリゴンモデルに変換したり、あるいはパーティクル(スプライト)の集合体として近似したり……といった実装が主流となってきた。ソフトウェアレンダリングパイプラインであれば、実体のない煙や雲のようなオブジェクトを直接ボリュームレンダリングするような仕組みを組み込める。CTスキャンの結果のような断面図に密度データを記録したボリュームテクスチャを参照してのボクセルレンダリング、流体的な動きをする火や煙のようなものをマーチングキューブ法などを使って等値面生成するパイプラインを組み込むこともできるだろう。
重要なのは、従来の固定化されたレンダリングパイプラインと違い、ソフトウェアレンダリングパイプラインでは、
- 各レンダリングステージに新しいアイディア(新しいレンダリングステージ)を自在に組み込める
- 様々なレンダリング手法を組み合わせた複合グラフィックスレンダリングパイプラインまでを構成できる
が実現できると言うことだ。場合によってはゲームタイトルごと、あるいはゲームエンジンごとにレンダリング手法を自在に組み替えることで、見た目的に表現手法的にも独特な映像を作り出せるようになるかもしれない。
しかし、こうしたソフトウェアレンダリングパイプラインの設計や構築が、全ての開発者が出来るわけではないのも事実。技術的、あるいはコスト的に難しいというケースが考えられる。
ここには、やはりビジネスチャンスがあるわけで、将来、独自のソフトウェアレンダリングパイプラインを提供するミドルウェアメーカーやゲームエンジンメーカーの台頭をTIM SWEENEY氏は否定しなかった。「次世代のUnreal Engine4.0で独自のソフトウェアレンダリングパイプラインを提供するのか」との筆者の質問には「答えられない」とのことだったが、レンダリングパイプライン革命の次期は刻々と迫ってきているようだ。