Game Developers Conference 2005現地レポート

会場：Moscone West Convention Center

　CryTekが開発した「FarCry」は、ゲームそのものの面白さもさることながら、今世代のPC3Dゲームグラフィックスにおけるベンチマーク(新基準)として、事あるごとに取りあげられてきた経緯がある。

　特にマーケティング面において、NVIDIAのGeForce6シリーズとのタイアップは強力で、今世代のGPUではGeForce6エクスクルーシブ仕様となったプログラマブルシェーダ3.0(Shader Model3.0)にいち早く最適化されたゲームソフトとしてNVIDIAが強く前面に押し出していた。

　GDC2005のセッション「Advanced Visual Effects with Direct3D」では、この「FarCry」開発元のCRYTEKのCRYエンジン技術スタッフのCarsten Wenzel氏が壇上に立ち、今まで、謎の部分が多かった「FarCry」のプログラマブルシェーダ3.0最適化の詳細が語られたので、解説したいと思う。

セッション名は「FarCry and DirectX」。壇上に立ったのはCRYTEKのCasten Wenzel氏	遙か遠方までが描画境界無しで美しいエピックスケールで描かれる地形描画もFarCryの見所であった

■ FarCryのプログラマブルシェーダ3.0対応度は限定的であることを激白

VTFとピクセルシェーダの動的分岐/反復はプログラマブルシェーダ3.0仕様の目玉機能であったはずなのだが、意外や意外、「FarCry」では実は未対応であった

　「FarCry」は2004年の初期リリース時ではプログラマブルシェーダ2.0ベースであり、3.0には対応していなかった。

　2004年夏に試験的に提供されたプログラマブルシェーダ3.0対応化パッチを適用することで3.0対応化がなされたわけだが、何をどのように対応したのかは明らかにされていなかった(技術的な問題があることが発見され、短期間で提供を停止したが、2004年秋に再度リリースされた)。

　発表によれば、FarCryでは、「SM3.0の頂点シェーダのテクスチャアクセス機能(VTF;Vertex Texture Fetching)とピクセルシェーダの動的分岐/反復制御」“以外”のフィーチャーに対応しているのだという。

　CRYエンジンのピクセル単位のライティング処理において、開発当初は、複数の光源処理や質感処理を単一パスのピクセルシェーダプログラムに統合し、処理するポリゴン単位で適切な処理を施していくようなスタイルを目指したのだという。たとえば、このポリゴンは法線マップを適用するが、鏡面反射はなし、でも拡散反射はちょっと適用する……のような感じの、1つのシェーダが属性に駆動されて適宜必要な動作をしていくようなスタイルを目指していた……というわけだ。これには処理系として実装するには動的な条件分岐が必要になる。

　ところが、詳細は省略するが、現行のSM3.0のピクセルシェーダ3.0における動的な条件分岐は非常にパフォーマンスインパクトが大きいのと、高度な構造プログラミングを実現するにはまだ制限が大きい(入出力レジスタに関連した制約がある)ため、その優位性を十分に発揮できないと判断。このことから、CRYTEKでは、この実装を断念したのだという。

　その代案として、動的な分岐は静的な分岐へと置き換え、動的な反復は、そのループを展開する(同じ命令列を繰り返し展開する)アプローチを選択したのだという。 　これは命令スロット数(≒個数)にして軽く160は超えてしまい、プログラマブルピクセルシェーダ2.0仕様の規定を軽く超えてしまうが、プログラマブルピクセルシェーダ2.0a(GeForceFX以降)/2.0b(RADEONX800以降)では問題ないため、実装に踏み切ったのだそうだ。

　反復展開は実行速度の面で動的分岐よりも大幅な高速化に結びついたが、シェーダ長が長くなり、SM3.0に対応したFarCry 1.3パッチでは、なんとシェーダの総容量だけで約430MBになったとのこと(圧縮して約23MB)。

　それにしてもSM3.0の代表格ソフトがSM3.0の特徴的機能を使っていなかったことの告白にやや衝撃を隠せない。このタイミングでこの衝撃の告白は、2004年末にATIがRADEON X850シリーズ(SM2.0ベース)を発表時、CRYTEKが手のひらを返したように、今度はATIとのパートナーシップを強調したことと無縁ではないかもしれない。

「現実世界へようこそ(→“理想通りにはいかないよ”の意)」とSM3.0仕様にがっかりしたようなメッセージ。動的分岐を用いた構造的なピクセルシェーダプログラムはSM3.0をもってしてもまだまだ実現への道は遠い? これはNVIDIAへの皮肉というよりも、次なるシェーダモデルの登場の予告を意味している?	動的分岐は断念して、多彩なマテリアル表現は、従来通りの個別シェーダの切り替えで対応。反復はループ展開で対応。結局、力業だった

FarCryは影生成にも凝っていた。顎下や耳の後ろのセルフシャドウに注目。技法はシーンによって適宜使い分ける方式で、この場面ではステンシルシャドウボリューム技法が使われている

　FarCryのシェーダ管理は意外にも原始的であることも告白された。

　まず、シェーダがビデオメモリにあればそれを直接使う(最速ケース)。なければハードディスクから読み出す。ハードディスクになければシェーダをリアルタイムにコンパイルしてハードディスクに出力する(最遅ケース)。

　あまりスマートなやり方ではないが、高い互換性を保つことに配慮すると、これが一番のやり方だったという。

　最遅ケースではゲームがカクつくことになり、これを回避するにはビデオメモリに載せるシェーダの組み合わせをシーンごとに最適化する作業が必要になるが、FarCryではそこまでは取り組んでいないという。まぁ、そんな面倒な最適化をしたところで、有効なのはSM3.0+の登場までであろうから、ここを責め立てるユーザーも多くはないはずだ。

■ ジオメトリインスタンシングで最大40%のパフォーマンスアップを達成

大量の植物描画は見るからに重そうだ。これを高速化できるのがジオメトリ・インスタンシング

　DirectX 9.0cより対応が始まった新テクノロジーに、ジオメトリ・インスタンシング(Geometry Instancing)というものがあるが、FarCryはこれについては積極的な対応を行なった 　ジオメトリ・インスタンシングとは何か、をここで簡単に整理しておこう。たとえば、3Dオブジェクトを100個、描画する際、その3Dモデルが全く同一形状であっても、GPUに100回そのジオメトリデータを転送する必要があった。これは非常に冗長な工程だと言える。簡単に言えばジオメトリ・インスタンシングは、この冗長性を低減する機構だ。

　具体的には、同一形状の3Dモデルの描画に限り、3Dモデルの形状情報をGPUに転送後、その付随属性情報をGPUに更新してやるだけで、シーン内に複数個描画できるという仕組みになる。つまり同一形状の3Dモデルの描画の際、理論上は形状データ転送が1回で済むわけで、圧倒的なバス消費の削減になり、描画パフォーマンスの向上に結びつけられるわけだ。

　実際の3Dゲームにおいて、何十、何百、何千という、同一形状の描画は、意外に頻繁に起こっている。たとえば、シーン内の植物モデルだ。草木は同一形状のモデルを向きを変えたり、若干曲げたり、あるいは回転させたり、はたまた色味を変えたりして配置することが多い。ジャングルに覆われた南海の孤島での死闘を描いた「FarCry」では、まさに喉から手が出るほど欲しかった新技術だったというところではないだろうか。余談になるが、リアルタイムストラテジー(RTS)ゲームのように同一兵ユニットが無数に登場するゲームでもこのジオメトリ・インスタンシングの効果が期待されている。

　さて、「FarCry」では、植物モデルの形状データをGPUに転送後、それ以降は、その「位置座標」、「拡大縮小率」、「折り曲げパラメータ」、「回転/傾き」といったインスタンスデータで、複数のバリエーションを描画している。このジオメトリインスタンシング導入により、FarCry 1.3では、植物描画の多いシーンではなんと最大40%のパフォーマンス向上が達成できたという。

　さて、ジオメトリ・インスタンシングは、プログラマブルシェーダ3.0仕様固有の機能のようにMicrosoftやNVIDIAがアナウンスしてきたが、実際にはプログラマブルシェーダ3.0仕様でなくても利用できる。

　筆者のATIのR&Dに対する取材によれば、RADEON X800/X850シリーズにおいても、ドライバレベルでマイクロコードアップデートを行なうことにより対応が済んでいるという。ただ、パフォーマンス的にはNVIDIAのものには及ばないという情報も別から得ている。いずれにせよ、RADEON系ユーザーでも、ドライバを最新にすることによってジオメトリ・インスタンシングが利用できる可能性があることは覚えておくといいだろう。

たとえばこのような植物が密集しているシーン	同一形状モデルであるものを色分けして見せたのがこの画面。この画面で同一色になっている植物モデル群は、ジオメトリ・インスタンシングにて1個の描画コールで一気に描画されていることを意味している

■ 「FarCry」におけるハイダイナミックレンジレンダリングは?

FarCry1.3では疑似ではなくて本当のHDRレンダリングを行なっている

　ハイダイナミックレンジ(HDR)レンダリングは、昨今の3Dゲームグラフィックスにおけるトレンドだ。HDRレンダリングとは、定義としては、シーンのレンダリングを32ビットカラーに限定せず、現実世界に近い、膨大な表現幅でレンダリングしようとするアプローチ。最終的には表示可能な32ビットカラーのディスプレイ色空間に変換するが、シーンの平均輝度から適切な露出補正を行なうことで、フォトリアリスティックなビジュアルにしたり、シーン内の高輝度部分にポストプロセスを施して、アーティスティックな表現にしたりできる。広義にはここまでをHDRレンダリングと呼ぶことが多い。

　さて、「FarCry」のHDRレンダリングでは、A16R16G16B16FのOpenEXRベースのFP16×4の64ビットバッファをレンダーターゲットとしており、HDR光源を設定してのHDRレンダリングを実際に行なっている。レンダリング結果にポストプロセスで光筋やライトブリーディングを書き込む際には、FP16バッファのフィルタリングやアルファブレンディングが欠かせないが、この機能を持っているのは現時点でGeForce 6600シリーズ以上しかない(6200は未対応)。

　冒頭の激白は、かなり親ATIを感じさせたが、HDRレンダリングにおいては、依然と親NVIDIA的な立場をとっているような印象だ。

　FarCry 1.3におけるHDRレンダリングのポストプロセスは2つ。

　シーン内の高輝度部分に光があふれ出す効果を付加するライトブルーム効果は、HDRレンダリングの第1人者であり、Xox用ゲームソフト「DOUBLE.S.T.E.A.L」のシェーダ設計を担当した川瀬氏式のブルームフィルタを採用している。そしてHDRレンダリングを表示可能な32ビットカラーに丸め込むトーンマッピング処理にはReinhard式を用いている。

　1つ興味深かったのは、ポストプロセスによる特殊効果付加工程において、A16R16G16B16Fの64ビットバッファ1枚でなく、G16R16Fの2チャンネルの32ビット長FPバッファの2枚に対してマルチレンダーターゲット(MRT)で分けて処理した方が、ある特定のGPUにおいてパフォーマンスが向上するという報告だ(おそらくGeForce6を差している)。CRYTEKのCasten Wenzel氏によれば、この方がGPUのキャッシュシステムがより効果的に働くのだという。

低解像度でHDRレンダリングしたフレームの高輝度部に対し、ブラーフィルタを、そのサイズを拡大しながら反復的に適用していく。これにより、外郭にいくにつれて光の溢れ出しが柔らかくなり、アーティスティックな光の溢れ出し効果が得られる

　FarCry 1.3におけるHDRレンダリングは現行技術を活用した模範例であり、そのビジュアルは大変美しいのだが、現在のGPUの仕様や技術限界などによる制約がまだ残されており、改善の必要性をCRYTEKは訴える。

　1つは、FP16バッファに対してFSAAを適用していないという点。ピクセルシェーダでマルチサンプルの処理系を組めばできなくはないが、パフォーマンス的にまだ現実的ではないようだ。いずれにせよ、FarCry 1.3をHDRレンダリングモードで楽しむ場合には解像度を上げないと、ジャギーが目立ちやすくなるわけだ。

　2つ目は、FP16バッファでは1ピクセルに付き64ビットが必要になり、これは従来の32ビットカラーの2倍であるため、非常にバス消費が激しくなるという点。彼らはこの状況を「Fill Rate Hungry」と称していた。

　3つ目は全てをHDRパスに組み込めていないという点。実験段階では、ライトマップ(光の強度を表したテクスチャで、スポットライト的な簡易ライティングが行なえる)やスカイボックス(天空)はHDRデータになっていない(→FP16バッファではない)という。これは、現在ではHDRテクスチャを圧縮する術がないという点、「Fill Rate Hungry」に一層の拍車が掛かるという問題に配慮したためだとのこと。

　CRYTEKのこのセッションは、ややネガティヴな内容も含まれてはいたが、GPUメーカーが盛大に強調する最新技術キーワードに対し、冷静な反応を示すゲームスタジオ側の意見として、存在意義は高かったと思う。

HDRなしのレンダリング結果	HDRありのレンダリング結果

(2005年3月13日)

[Reported by トライゼット西川善司]

GAME Watchホームページ

Q&A、ゲームの攻略などに関する質問はお受けしておりません
また、弊誌に掲載された写真、文章の無許諾での転載、使用に関しましては一切お断わりいたします