Cevat Yerli氏 (CEO and President, CRYTEK、写真左端)

会場：サンフランシスコ Moscone Convention Center

　何かと話題作りが上手なドイツのCRYTEK。ヨーロッパではもっとも実力があるゲームスタジオとして認知されており、彼らの送り出す技術は業界に常に一定の影響を与えてきた。2007年11月に発売されたCRYTEKの最新作「CRYSIS」は、発売時点で最高スペックのPCでも、全てのグラフィックス要素を最高位に設定するとパフォーマンスが足りないことがあるという“激”重なPC用3Dゲームであった。しかし、確かに、再現しようとしているゲームグラフィックスは志の高いものであり、ユーザーの間では単純に「重いから悪い」という判断は下されなかった。きっと近い将来、これが高速に動くGPUが出てくるのだろう、という夢すら感じる人も少なくなかったのではないか。

　2月18日よりサンフランシスコで開催されたGDC 2008では、このCRYTEKの「CRYSIS」、その3Dゲームエンジンである「CRY ENGINE2」(CE2) に関連したセッションがいくつか行なわれた。

　このうち、最も興味深かった「CRYSIS IN THE MAKING」と「CRYSIS NEXT GEN EFFECTS」について、まとめて報告しよう。

■ 「CRYSIS」開発秘話～“技術”のCRYTEKから“ゲームスタジオ”CRYTEKを目指して

「Far Cry」の良かったところと反省点

　まずは「CRYSIS」がどのようにして生まれたのか……この点について見ていこう。

　2004年3月、CRYTEKはデビュー作にも相当する「Far Cry」を発売。彼らは「Far Cry」について良かった点と悪かった点をいくつか挙げている。

　良かった点としてはプログラマブルシェーダー・グラフィックスを本格活用したグラフィックスの凄さをユーザーに認知させたこと、そして新興スタジオであるCRYTEKの技術力の高さを全世界に知らしめたことを挙げている。

　当時の競合ゲームとしては「Half-Life 2」や「DOOM3」があるが、CRYTEKの技術的な挑戦として他を圧倒していたのは超広大なオープンフィールド表現力と、(ある程度) 自律的に行動してプレイヤーを追い詰めるAIシステムだった。これらについては一定の結果を残せたとCevat Yerli氏 (CEO and President, CRYTEK) も当時を振り返っている。

　しかし、ストーリーがどこかで見て聞いたことがあるようなB級映画のようだったこと、QUICKSAVEが遅すぎて全然QUICKじゃなかったこと、ゲームが難しすぎたこと、AIがコンピュータ的で「人間ぽく」なかったこと、などを反省点に挙げている。

　次回作についてアイディアを練っていたYerli氏は、それらの反省点を念頭におきつつ、次回作は「凍り付いた楽園」という方向性で行くことを決意する。そしてゲーム体験を「Fare Cry」からさらに上級なものを目指すと共に、ストーリーには「説得力のあるSF要素」を盛り込みたいと感じたという。

次回作制作に向けてのイメージイラスト。これは「Far Cry」のスクリーンショットをアーティストにレタッチで凍り付いた世界っぽく修正させたもの。これをイメージとして初期制作が始まった

お手本のプリレンダームービーはジャングル、凍り付いた世界、エイリアン基地内の3シーンが制作された

　2005年にはオフラインレンダリングのコンセプトムービーを妥協なしで制作。これをお手本として制作を進めていくことになったとしている。この頃までに、「地球外生命体 (エイリアン) の遺跡が南国で発見されるものの、これが北朝鮮軍に奪われること」、そして「エイリアンが凍り付いた世界を好む」という設定などが固まっていたようだ。それにしても「説得力のあるSF要素」の選択に「宇宙人の侵略」と「北朝鮮軍の介入」の2要素を選択するあたりは、CRYTEKらしいユーモア溢れるセンスだといえる。ちょっと日本では思いつきにくい (いや……思いついても具現化しにくい) ネタのコンビネーションで、「さすが“ドイツ”のスタジオ」という感じもする。

　「Far Cry」も南国をテーマにしていたが、制作時は誰も南国を旅したことがなかったとのことで、次の「CRYSIS」ではリアリティを求めたかったことから、実際にタヒチに取材旅行をしたという。まぁ、これは筆者個人の意見だが、講演時に公開された取材映像はとても楽しそうで、どうみても「『Far Cry』完成のご褒美旅行」のような風情であったが、行って見てきた経験は「CRYSIS」の制作に大いに役立った……とYerli氏は笑顔で振り返っている。

「CRYSIS」のための取材旅行はタヒチへ

　この後、プロトタイプの開発は順調に進み、2006年のE3では、EA/CRYTEKスタッフがプレイする形で見せるプレイアブル出展を果たし、「プレーヤーに超人的なスキルを与えるナノスーツ」、「破壊可能な植物」、「AI」などのコンセプトを一般公開し、好評を博する。

　AIについては、リアルだがプレーヤーが遊んで楽しい戦闘となること、そして完璧な人間はいないので雑魚敵キャラクタにはドジな要素を付加したり……といったユニークな試みを盛り込んだことを打ち明けている。例えば敵もこちらに向かってくるときに障害物を乗り越えてくるが、敵の中にはつまづいて転んだりするやつもいるのだ。

E3 2006で初公開となった「CRYSIS」	「CRYSIS」のAIは「完璧なAI」ではなく「人間ぽいAI」の再現にこだわったという

　プレーヤーの行動を補助/強化するナノスーツについては、多機能、そしてカスタマイズ自由度を高く設定したが故に、そのインターフェイスの設計には試行錯誤がなされたことをYerli氏は打ち明けた。

最初期のインターフェイス。ゲーム画面がよく見えない	続いて採用したフルカスタマイズ可能なアナログインターフェイス。操作が面倒くさくてスピーディな戦闘に対応できない	最終的にはアイコンベースのシンプルなスイッチングインターフェイスが採用された

　ゲームデザインに関しては、「Far Cry」では自由度を高くしすぎた分、プレーヤーを何をしたらよいのか迷わせてしまうようなことがあったが、「CRYSIS」ではシナリオの進行の都合と、プレーヤーの自由度をほどよくバランスさせることを心がけたという。つまり、自由度の高いことをプレーヤーに感じさせつつ、大局的にはゲーム進行通りに流れを持って行くようなステージデザインを心がけたということだ。これはテクノロジー重視型の「Far Cry」時のCRYTEKと比べると、ゲームプレイの楽しさ重視に方針を転換したようにも思えて興味深い。

自由度の高さの実現とゲームデザインの都合の折り合いの設定が難しい

　結びにもYerli氏は、「技術革新を目的とした技術革新は意味がない」、「最新テクノロジーを実装することだけにこだわるな」と述べており、これまでは「技術力のCRYTEK」という部分だけが取り沙汰されてきた同社は、「CRYSIS」の開発を経て「先進的で楽しいゲーム開発が行なえるスタジオ」に生まれ変わってきたようだ。

「技術のCRYTEK」は技術開発だけでなく楽しいゲーム作りを目指す	2007年についに「CRYSIS」発売	「CRYSIS」の開発は2004年から開始。足かけ4年で完成に漕ぎ着けた。プロジェクトの長さとしては「Far Cry」も同じくらいだった。果たして次回作は……!?

■ 「CRYSIS」は1フレームあたり平均200万ポリゴン

　「技術力のCRYTEK」から、「楽しいゲーム開発を目指すCRYTEK」へ変身を遂げようとしているCRYTEKだが、彼らの最新作「CRYSIS」は、そうはいっても時代をリードする3Dグラフィックス技術のショーケース的なポジションであったことは間違いない。

　例えば、本連載の前回で紹介した「Screen Space Ambient Occlusion」(SSAO) は「Unreal Engine 3 (UE3)」よりも「CRY ENGINE2 (CE2)」の方が実装が早く (そもそも最初の実験実装はCRYTEKで行なわれたとされている)、CRYTEKはユニークな3Dグラフィックス技術の3Dゲームエンジンへの実装が本当に早い。

Tiago Sousa氏 (R&D Graphics Programmer, CRYTEK)

「CRY ENGINE2」のグラフィックスエンジン基本スペック

　「CE2」には注目すべき技術はいろいろあるのだが、CRYTEKのTiago Sousa氏 (R&D Graphics Programmer, CRYTEK) は、GDC会期中に「CRYSIS」(CE2) におけるいくつかの3Dグラフィックスエフェクトの種明かしを行なった。

　まず、「CE2」の3Dグラフィックスエンジンはプログラマブルシェーダー2.0～4.0に対応している。ライティングは完全に動的光源で行なっており、1パスあたり最大、4点光源までをサポートする。

　シェーダーはブリン、フォン、Cook-Torrance、Ward、Kajiya-Kayなどなど、広く知られた基本シェーダーを多用しており、特別な材質……たとえば肌、眼球、布、ガラス、植物、氷……のようなものをCRYTEK独自開発のシェーダーで表現しているという。

　先進的でキャッチーなシェーダー・フィーチャーを挙げるとすれば視差遮蔽マッピング、法線マッピング、前述したSSAO、64ビットHDRレンダリングなどは全て「CE2」でサポートされ「CRYSIS」に使われている。

　今さらいうこともないかもしれないが、レンダリングは基本マルチパスレンダリングで各パスのレンダリング結果を最終的に合成してフレームを作り出す。具体的にはZパス (Zバッファレンダリングを先に行なう)、半透明パス、透明/反射パス、特別な材質のシェーダーパス、影生成パスなどがあるとSousa氏は語っている。

　フルグラフィックスオプション時の1フレームあたりの平均ポリゴン数は200万だという。これは今世代のゲームにおいて実は破格に多いという数字でもない。むしろ平均的と言ってもいいだろう。そう、「CRYSIS」があれだけ重いのはジオメトリ負荷だけではなく、ピクセルシェーダー負荷とメモリ負荷に起因しているところが大きいのだ。

■ ジオメトリレベルの波の生成

　「Far Cry」もそうだったが、「CRYSIS」も水面の表現が美しい。

　「CRYSIS」のエンジン「CE2」では、「Far Cry」の「CE1」よりもさらに説得力をもった水面表現の実装がなされている。

「CE2」ではジオメトリレベルの凹凸を持った水面表現を実装

　フラットなポリゴン面に動的法線マップによる“さざ波”を適用するだけでは古い……とし、「CE2」の水面表現は「ジオメトリレベルで立体的でリアルあること」をコンセプトとして開発されている。競合の「UE3」も同様の方針を取っているので、これは今後のトレンドとなる可能性が高い。

　「CE2」では、動的な波動シミュレーションとしては、水面の表現に関して広く活用されているJerry Tessendorf氏のアルゴリズムを実装している。波動シミュレーションの結果はCPUで計算され64×64グリッドに適用され、これが64×64テクセルのFP32-128ビット (R32G32B32A32F) テクスチャに転送される。このFPテクスチャをVTF (Vertex Texture Fetching) を用いてジオメトリレベルの立体的な水面の凹凸へと変換する。なお、64×64のグリッドは全水面に反復使用されることになり、反復性がユーザーに露呈する可能性があるが、これを低減する意味合いもあって、4レイヤーの周波数の違う動的な法線マップアニメーションをこのジオメトリレベルの凹凸の水面に合成している。

開発時、シミュレーション結果を適用する水面ポリゴンをどうあらかじめ分割しておくかで迷ったという。画面座標系でポリゴン数を均一にするメソッドで分割しておくか、遠近区別せずに分割しておいたポリゴンを視界に沿った形で敷いておくか。双方に短所長所があったが、結局、後者が選択された

　水面のシミュレーションをCPUでやったことでゲーム側の物理エンジンとの連携もしやすく、水面の波で翻弄されるキャラクタや乗り物の様子を表現することができるようになった……としている。

■ 「CRYSIS」の水面における反射と屈折

　水面といえば、水面に映り込む情景 (反射マップ) をどうするか、という問題がつきまとう。

　「CRYSIS」(CE2) において、映り込む情景はリアルタイムレンダリングされるわけだが、既に1シーン、1フレームあたり約2,000の描画コール (200万ポリゴン程度) が実行される見積もりがあったことから、反射マップ生成のために割けるレンダリングコストがあまり大きくできなかった。最適化に最適化を推し進め最終的には300コールにまで抑えることに成功したという。ちなみに反射マップの解像度は画面解像度の半分程度に抑えられている。

　この反射マップをレンダリングするタイミングは数フレームに1回という制限を設けることで負荷低減を行なっている。瞬間瞬間には正しくない反射マップが水面に適用されることになるが、もともとその解像度は低くしているし、水面の揺らぎに隠れ、見た目的にはあまり気にならない。

　また、(一人称シューティングなのでその効果はあまり高くないようだが) 視線が動かないときも反射マップの更新をさぼっている。

　さらにSLIのようなマルチGPU環境では、各GPUで反射マップ更新を行なってしまうと全GPU間で反射マップ同期が始まってしまい、これがボトルネックとなって効果が上がらない。そこで、これを低減するために反射マップ更新はメインGPUだけで行ない、その後、再びメインGPUにレンダリング工程が回ってくるまで各GPUは同じ反射マップを使うようにしているという。

反射マップには異方性垂直ブラーを仕掛けている

　ユニークな試みとしてこの反射マップには垂直方向のブラー (ぶれ) を仕掛けているという。それも始点から遠いほどブラー量が少なく、近い位置ほどブラー量を多くするという異方性のブラーを適用している。これは映り込みがキッチリしすぎるCG水面のわざとらしさを低減するとともに、低解像度反射マップのジャギー (エイリアシング) を低減する副次的効果もある。

　水面下の情景は屈折シェーダーによって生成されるが、これはそれほど難しいものではない。この屈折表現技法に関してはNVIDIAが発刊した「GPU Gems2」の「Generic Refraction Simulation」に記載されている技法をほぼそのまま適用している。ちなみに、この章の執筆者はSousa氏本人だったりする。

上が製品版のショット。下は水面下でないものまでが屈折シェーダーによって掻き乱されてしまっている例。水面上のものであるはずの桟橋の脚部やプレーヤーキャラクタの腕がグニョリと曲がってしまっている点に注目

　この技法を簡単に解説すると、この「CE2」の屈折シェーダーでは、水面ピクセルの向き (法線ベクトル) を適当にスケールした値を「タネ」にして、通常通りにレンダリングしておいた水底の情景をサンプルするだけだ。特別な水底シーンレンダリングパスがあるわけではなく、簡単にいえば、水面を除いて通常通りシーンをレンダリングして、それに対し水面ピクセルの法線に従って水底情景を掻き乱す……というようなイメージだ。

　ただ、この方法だと、水面より上にあるものなのに屈折シェーダーで掻き乱されてしまうようなアーティファクト (正しくない描画) が発生してしまう。これについては水面より上の情景については屈折シェーダーから影響を受けないようにするマスクの仕組み (αチャンネルを利用) と、視点から水面までの深度値と、描かれている情景の深度値を比較して、掻き乱す情景が本当に水面より下なのかどうかを判定している。

擬似的な色収差のシミュレーション

　これは実は一般的な屈折シェーダーの実装なのだが、「CE2」では、この「水面下の掻き乱し幅」を「R、G、B (赤、緑、青)」の三原色についてバラバラに行なうことで、「色収差」現象を擬似的にシミュレートしている。色収差とはレンズなどでも起こる、光が屈折した際に分光されてしまう現象のこと。

　物理的には全然正しくない反射、屈折、色収差の表現ではあるが、「CE2」ではそれっぽく見えるように妥協案を実装して非常にリアルに見せている事がわかる。

■ プロシージャル生成された集光効果「火線」

集光効果「火線」はプロシージャル生成されている

左が火線なし、右が火線あり

　Sousa氏は現在の水面レンダリングにおいて「CAUSTICS」は非常に重要な要素だと強調する。

　CAUSTICSは和訳すると、あまり馴染みのない言葉の「火線」となるが、これは水面下の物体に光の網目模様みたいなのが投射される光学現象のことだ。太陽光が水面のレンズ効果で集光して輝いて起こる。だから3DグラフィックスにおいてはCAUSTICSは火線とは訳さずに「集光効果」と意訳する場合も多い。

　これまでの多くの3Dゲームグラフィックスでは、こうした火線効果はあらかじめ用意したそれっぽく描いた適当なパターンテクスチャを投射するだけであったが、「CE2」では、火線シェーダーを実装してリアルタイム合成している。Sousa氏は「火線のプロシージャル生成」という言葉を使ったが、解説を聞く限りでは「GPU Gems1」に記載されている「Rendering Water Caustics Juan Guardado (NVIDIA) and Daniel Sanchez-Crespo (Universitat Pompeu Fabra / Novarama Technology)」を参考に実装したものと推察される。

　これは水底下の情景の各ピクセルにおいて、このピクセルの法線方向にレイを飛ばし水面のポリゴンと交差して、水面上へどういう角度でこのレイが飛び出すかを計算し、これが太陽方向に向いていれば向いているほど明るい……という陰影処理を行なって求める技法だ。

　Sousa氏は「シーンの全てのピクセルにおいてピクセル単位の法線ベクトルを適当なバッファにレンダリングしてしまうDeferredレンダリングの手法も考えた」と振り返るが、最終的にはこういう方法を採択したようだ。

　火線は3レイヤー分を生成して合成しており、さらにその際に、前述の水面下の屈折シェーダーでも触れた色収差の効果を加えて合成している。なお、この火線レイヤーは意図的にやや黒っぽくすることで濡れた感じを強調させたとしている。

■ 岸辺と泡沫の処理

左が岸辺境界処理と泡沫なし。右が岸辺境界処理と泡沫あり

　水面と陸地の境界線が強く出てしまうのもCGっぽい見た目の原因となっている。

　これを低減するために「CE2」では、水面と岸辺の境界が近くなればなるほど水面の透明度を上げるようにブレンドしている。これは丁度、パーティクルとシーンの交差線を見えにくくするソフトパーティクル処理と原理はまったく同じだ。

　水の上に浮かぶ泡……「泡沫(うたかた)」については2レイヤーのアニメーションの泡テクスチャを水面のさざ波法線マップで摂動させつつ、岸辺境界から水深の深い方向に向かって柔らかく合成していっているだけ。それでも、十分満足のいく結果になったとしている。

■ 水面下の表現～水中に降り注ぐ光筋の表現

　基本的には火線シェーダーと同じアルゴリズムのものを動かしているという。

　生成した火線を、視点 (カメラ) の前に戸板のように並べた無数のレンダーターゲットに投射していく。レンダーターゲットは画面解像度の1/4の低解像度のものを使用している。

　イメージ的には火線を投射して作り出した無数のどでかい光筋スプライトをカメラから奥行き方向に向かって重ね描きしていくようなイメージのようだ。超大ざっぱなボリュームレンダリングのようなイメージだろうか。

　なお、水面下の奥行き方向の霞んで見える様はZバッファの内容 (深度値) をキーにして濁らせる擬似的な光散乱フォグで表現している。

水面下に降り注ぐ光筋の表現。後述の逆光の光筋とは別の実装法	左が光散乱による霞み表現、中央が火線表現を付加したフレーム、右がさらに光筋を付加したフレーム。この図ではわざとわかりやすいように光筋は色濃く示しているが、ゲーム中では実際はもっと薄い

■ 水面表現のその他のフィーチャー

　視点 (カメラ) が水面に入ってしまった場合にはいくつかの特例措置が実施される。

　まず、泳いでいるときのような、視界の中に水面上と水面下が捉えられた場合は、反射マップの起点は、視点の位置 (画面の中央に相当) にして処理している。

　水面下の奥行き方向の霞みについても、波の細かな凹凸はもう無視して、水面の高さから水深方向に向かっての疑似光散乱シミュレーション (のフォグ) を加えている。

　視界内に水面が丁度かかるようなときには、視界と水面の交差線を出してしまうと格好悪いので、前述の水面と岸辺の境界線を消した要領で柔らかく合成している。

　また、水面から上がったときには、いかにもといった風情の、視界に水滴が付いたような表現……具体的に、局所的に視界が屈折したようなエフェクトが挿入される。

　そして、水面下に潜水したときには物理的に正しくはないが、視界全体が揺らぐようなエフェクトも入れている。潜水水泳していると時折、泡が上がるが、それらは完全な擬似的なもので、パーティクルベースの泡を出現させているに過ぎない。ただし、それらの泡パーティクルには擬似的なライティングを行なっているため、きちんと光源方向にハイライトが出る。このパーティクルに擬似的なライティングを行なう手法については本連載の「ワンダと巨像」編の「疑似ボリュームパーティクル」方を参考にして欲しい。

水しぶきや水泡はパーティクルベース。ただし擬似的なライティングが成されるので陰影が出る

■ CRYTEKの次なる水面表現

ここまできてもまだ盛り込めてない要素はいっぱいあるという

次回作以降の水面で実装したいテーマ

　CRYTEKにとって「CE2」の水面で完璧か……というとそういうことでもなく、Sousa氏は将来プロジェクトに向けていくつか持ち越したテーマがあるという。

　「CE2」の海の波はジオメトリレベルの凹凸を獲得したが、海辺に打ち寄せる巻き込むような高波 (浜に打ち寄せる波) の表現は実装されておらず、将来はこれを実現したいという。これにはジオメトリレベルの頂点アニメーションが必要になるだろうと予見している。

　また、水面と何かが衝突したときの水しぶきはパーティクルで表現しているが、波動シミュレーションの結果で波の頂点から生じる水しぶきを実現したいという。ちなみに、これは「鉄拳6」(バンダイナムコゲームス) で既に実装されている。

　前述したように、CPUによる水面の波動シミュレーションを行なっている関係で、水面の動きに従ってキャラクタを動かすことには対応できたものの、キャラクタのアクションが水面の波に影響を与える表現や、岸辺と水面の波が衝突したことによる波へのフィードバックなども現状では省略されている。そうした要素もいずれは対応したいとのことであった。

　なお、CRYTEKのご厚意により、この水面シェーダーの様子をまとめたムービーを頂いたので興味がある人は見て欲しい。これは実際のゲーム中の映像のものだ。

　提供いただいたムービーはハイビジョン仕様であったがサーバー側の都合によりSD画像へトランスコードしてある。これ以降に紹介しているムービーについても同様だ。この点はご容赦いただきたい。

【水面シェーダーのムービー】
[WMV形式: 29.5MB 1分1秒] ZIP圧縮 ※クリックするとダウンロードが始まります

■ 「CRYSIS」凍結した世界の再現～3つのプロトタイプで実験

　冒頭の「メイキング話」で触れたように、「CRYSIS」のキーコンセプトは「凍結した楽園」に決定していたが、これをどう再現するかが悩みの種だったという。

　なにしろ、このテーマを取り扱った過去の研究が非常に少なく、どういうアプローチが適切なのかが皆目見当が付かなかったためだ。

　逆に、これこそが、誰も見たことのないビジュアルを見せられる好機ともいえ、挑戦のしがいのあるテーマともなった。

最初のプロトタイプ。通常シーンから改めて凍り付いた世界を作り直すアプローチ

2番目のプロトタイプ。通常シーンをベースにプロシージャルアプローチで凍り付いた世界を生成させた

　Sousa氏は、この問題について「リアリスティックにすべきなのか、アーティスティックにすべきなのか」、「通常の楽園シーンのセットを動的に凍り付かせるビジュアルに変換するのか、それとも凍り付いたシーンを新たに作り直すべきなのか」、大きな2つの問題を掲げて思考を巡らせ、最終的なバージョンの完成までに、途中、3つのプロトタイプを制作したことを打ち明けた。

　第一のアプローチは、おそらく、現在のゲーム制作においては、もっとも「採択されやすい方策」ともいえる、通常シーンをベースにして凍り付いたシーンを丸ごと作り直すというものであった。これはアーティストにかかる負荷が大きく、またデータ的にも両方を用意しなければならず、DVD-ROMの容量を食いつぶすことになることがわかってきた。また、通常シーンから段階的に凍っていくような表現を実装するのは難しいということもわかったようだ。

　続いて、今度は、実験的なユニバーサルな「凍り付きシェーダー」を開発し、これを通常シーンに適用するプロシージャルアプローチのプロトタイプを製作。これは段階的に凍り付いていく世界の表現ができる利点はあったが、シーンを作成するアーティストが調整すべきパラメータが多く、さらに合成処理の負荷が大きくレンダリング負荷が高くなりすぎるという問題が発生した。また、そのビジュアルクオリティもやや説得力に欠けている印象も持ったという。

　なお、この2番目のプロトタイプの映像もいただいたので、ここに示しておこう。

【プロトタイプのムービー】
[WMV形式: 7.62MB 16秒] ZIP圧縮 ※クリックするとダウンロードが始まります

3番目のプロトタイプは、1番目と2番目のプロトタイプのいいとこ取りアプローチ。Sousa氏も、椰子の木の葉っぱなどは十分にリアルに凍り付いた感じが表現できていると感想を述べている

　3番目のプロトタイプは、1番目と2番目のプロトタイプのいいとこ取りをしようとしてハイブリッドなアプローチを試作。つまり、一部のオブジェクトについては凍り付いた世界用のものを新たに制作し、できる限り、通常シーンのものにプロシージャルな凍り付きシェーダーを適用しようとするアプローチだ。これならばアーティストの負荷と描画システムへの負荷の両方を低減できる。

　結果としては、シーンによっては満足いったが、そうでもないシーンもあり、完璧ではなかったようだ。

■ 凍り付きシェーダーの最終形は「雪」+「氷粒」+「パーリンノイズ合成」+ぎらつき

　結局、最終的には3つのプロトタイプから学んだことをベースにして、最終仕様の策定に乗り出すことになったわけだが、それが完了したのは「ゲーム仕様固定期限期日」の1週間前だったことをSousa氏は振り返り「あの時はやばかった」と述べている。

実際に調査に用いた写真

　最終仕様では「見た目に興味深く、それでいてアーティストへの負荷は少なくする」ことをコンセプトにしたプロシージャルな凍り付きシェーダーの開発をすることで確定。その際には、1つの賢くてユニバーサルでプロシージャルな凍り付きシェーダーの開発はあきらめ、「凍り付き」要素をいくつかの典型に分けて実装することにしたという。その「典型」とはなんなのか、これについては現実世界の冬場の写真を徹底調査して実装要素を絞り込んでいったそうだ。

　開発チームが絞り出した、プロシージャルな凍り付きシェーダーで再現する要素は3つ。

　1つは雪を積層させること。2つ目は結露して発生した露 (つゆ) が凍ってできた氷粒。3つ目は光がそうした雪や氷粒に反射して起こすランダムな「ぎらつき」であった。

　「雪の降り積もり」はシーン内の各オブジェクトの面の向き (ピクセル単位ではピクセルの向き)……すなわち法線が天空に対してどのくらい傾いているかに配慮して雪テクスチャを合成する (積層させる) シェーダーによって実現される。これはつまり、天空に真っ直ぐ直上方向に向いていればいるほど雪は一杯積もり、天空に向いていなければ雪が滑り落ちて積もりにくい……というような異方性の処理をしていることになる。

　「氷粒」は微細凹凸の法線マップを2レイヤーで重ねて表現している。これは法線マップを積層させる方式のファー (毛皮) シェーダーと同じ原理だ。ファーシェーダーは法線マップを多層で積層するが、氷粒シェーダーは微細なので2層表現で十分だということなのだろう。この氷粒の発生条件は、雪の積層とは違って、天空に向いていない垂直面や斜面に発生しやすいというアルゴリズムになっている。

　また、こうした雪と氷粒とシーンの合成をただ一律にやってしまうと反復性というか人工的に見えてしまうので、3次元パーリン・ノイズ (3D Perlin Noise) をボリュームテクスチャに生成し、これをキーにして合成している。

　ランダムな「ぎらつき」は、2次元のノイズ (乱数的な) ベクトルテクスチャを用意して、この値と視線ベクトルに適当な計算を行ない、敷居値を超えているようならば高輝度値を返すという単純な実装になっている。計算結果がHDR値になったら、それは後段のHDRレンダリング向けのポストプロセスによって光のあふれ出し処理 (ブルーム) などの影響を受けるので、シーンに溶け込み、なおかつ説得力のあるギラギラ感が得られる。ランダムなベクトルテクスチャとはいえ、視線ベクトルに配慮した計算結果が得られるので、視線を移動したときに、それにインタラクティブに反応したギラギラ感が得られる。適当に実装しているわりにはリアリティは高い。

　下にこれによって生成された最終仕様のショットを示しておこう。

プロシージャルな凍り付きシェーダーの詳細仕様	最終仕様の画面	元の状態
氷粒を適用	雪を積層	シーンへの合成比率をパーリンノイズでランダム拡散

　結果的に、通常シーンをベースにして、かなりプロシージャルなアプローチを実装できたことで、「CRYSIS」(CE2) では段階的に、動的に、リアルタイムに凍り付いていく世界を表現することに成功している。Sousa氏の説明では、「段階的に凍り付かせる」表現については通常シーンへの雪や氷粒の合成割合の増減制御だけでなく、雪や氷粒のレイヤー (層) の増減も行なっているという。

Sousa氏は「結果は満足のいくものになったが、リアルに見せるには、光源の設定 (光源位置や光源色) をちゃんと調整する必要がある」と述べている

　基本的には、この「プロシージャル凍り付きシェーダー」はオン/オフのスイッチで「凍り付いた世界か/そうでないか」を切り換えられるほど簡単な実装になってはいるが、もちろんデザイナーがパラメータをいじって、より説得力のあるビジュアルに作り込めるように調整余地は残してあるという。

　Sousa氏は、このプロシージャルアプローチについて「まぁ、相対的には軽く実装できた」と振り返っていたが、「CRYSIS」の全編を通してプレイしたユーザーの立場から言わせてもらうと、この凍り付いた世界のステージはとにかく「重かった」の一言に尽きる。今回のSousa氏の種明かしで「重い訳」もよくわかった。

　さて、ここでも、CRYTEKより映像素材を頂いているのでお見せしよう。このムービーでは、最終的なゲーム仕様の凍り付きシェーダーをオン/オフと切り換えていく様が見られる。

【凍り付きシェーダーのムービー】
[WMV形式: 25.0MB 52秒] ZIP圧縮 ※クリックするとダウンロードが始まります

■ 「CE2」におけるポストプロセス方針

CRYTEKの考えるポストプロセス

　近代3Dゲームグラフィックスでは、レンダリングし終わったフレームをそのまま表示することはむしろ希で、ほぼ間違いなく「最終的なお化粧」としてなんらかのポストプロセス (後処理) を施している。

　「CE2」でもそれは同様で、レンダリング結果に対して様々なポストプロセスを施している。最後のテーマとして、「CRYSIS」(CE2) におけるポストプロセスを見ていくことにしよう。

　CRYTEKの考えるポストプロセスは「エイアス (ジャギー) の低減」、「速度を犠牲にしない」、「あまり目立たせることをしすぎない」を基本方針としている。この基本方針自体は別段突飛なことは言っておらず、十分同意できる要件だ。要するに、わざとらしくて、重くて、ジャギーが残るようなポストプロセスはしない……といっているのだ。

■ 「CE2」におけるモーションブラー(1)
　　カメラ・モーション・ブラー(CMB)

　まずはモーションブラー (Motion Blur) だ。これは一言でいえば、速い動きに対して残像を付加するポストプロセスになる。

　「CE2」におけるモーションブラーは2つのメソッドが実装されている。

　1つは視点 (カメラ) の移動によって視界がぶれて見えるカメラ・モーション・ブラー (CMB)、そしてもう1つはシーン内のキャラクタやオブジェクトが移動したり、あるいは速い動きをしたりすることで起こるオブジェクト・モーション・ブラー (OMB)だ。

カメラ・モーション・ブラー。「CE2」におけるモーションブラー処理は全てHDR次元で行なわれ、HDR光の残像はHDR光の軌跡を描く

　まずはCMBから解説しよう。

　一般にCMBの生成にはカメラの移動速度が必要になる。これは前のカメラの向きと現在のカメラの向きの差分から求められる。この速度情報を元に現在のフレームに対してブラーを掛けてしまうと、画面全域にわたって均一のブラーが掛かってしまう。確かにこういう簡素なCMBの実装も存在するが、「CE2」はもうちょっと高度なものを実装している。

　現実世界でも視線を動かせば、近くのものが速く動き、遠くのものはゆっくり動くことがわかるはずだ。「CE2」では、CMBでこの表現を実装している。

　ポストプロセスは、レンダリングされたフレームに対して行なう2次元的な画像処理になってしまうわけだが、このフレームを生成するのに使った深度バッファ (Zバッファ) の内容を参照すれば、そのフレーム中のピクセル単位の奥行き情報を知ることができる。

　「CE2」ではこのZバッファの内容を奥行きに配慮したCMB処理を実現するための情報として、レンダーターゲットのαチャンネルに書き込んでいくが、この時にブラーを掛けたくないマスク情報も書き込んでいく。

　理論上は近くのものは速く動くのでブラーが激しくなるはずだが、カメラ近くのもの……たとえばプレーヤーが持っている銃器のようなものがブラーが激しいとプレイがしにくいため、そこで、一定距離以内のものについては残像を起こさせないマスク情報を書き込んでいる。

奥行き情報に配慮したCMBを実現するための工夫
シェーダー・コード

　実際のブラー処理では、このαチャンネルに格納された奥行き情報/マスク情報と、CPU計算で求めたカメラの移動速度に配慮して、レンダリングされたフレームをサンプルしてボカしていく (ブラーさせていく) ことになる。

ピンポン・ブラー処理によってブラーのクオリティを向上させている

　ボカし処理はサンプル数を多くすればするほど自然になるのだが、これについてはブラー処理の常套手段である「ピンポン・ブラー」(Ping-Pong Blur) を行なっている。

　最初のパスでは8サンプルのボカシを行ない、次には同じフレームに対して8サンプルのボカし処理を行なう。これで仮想的に8×8で64サンプルしたものと同等の結果が得られるのだ。こうした反復サンプル処理によって高次サンプルブラーを仮想的に実現するテクニックが「ピンポン・ブラー」処理だ。

　Sousa氏は、「CE2」におけるCMBに関する最適化手法についても明かしている。

　まず、カメラの移動が全くない場合にはカメラブラーの処理を完全スキップさせている。また、カメラの移動速度が遅い場合はブラーのサンプル数を減らし、速い場合は増やすという適応型処理を行なっている。この最適化処理により、GeForce 8800 GTX、1,280×1,024の解像度にて、1ms程度の処理時間ですんでいるとのこと。

　また、せっかく実装したCMBも、「ハードコアゲーマーにとっては映像がぶれるだけの余計な要素として認識してしまうようで、オフにされてしまうことが多い」とSousa氏は冗談ぽく不満を漏らす。とはいえ、ユーザーあってのゲームなので、「CRYSIS」ではPATCH1以降のバージョンではモーションブラーの掛かり具合 (シャッタースピードに相当) の調整をできるようにした、としている。

■ 「CE2」におけるモーションブラー(2)
　　オブジェクト・モーション・ブラー(OMB)

「CE2」におけるオブジェクト・モーション・ブラーもトーンマッピング前にHDR次元で行なわれている。だからブラーした残像自体がHDRだとそこからもあふれ出しが発生する

　オブジェクト・モーション・ブラー (OMB) は、最近流行のモーションブラーテクニックだ。本連載でも「ロストプラネット」(カプコン) がこのタイプのモーションブラーを実装していることを紹介した。「CE2」のOMBは「ロストプラネット」の実装とは似て非なるものとなっている。順を追って解説しよう。

　ただし、意外なことだが、「CRYSIS」におけるOMBは、DirectX 10/SM4.0以上専用の効果として実装されている。

　これは「CRYSIS」のゲーム仕様とDirectX 9/SM3.0の仕様制限が微妙に関わった問題だ。

　キャラクタの関節変形処理の際の頂点ブレンディング計算を行なうハードウェア・ボーン・スキニング処理を行なう際、頂点シェーダーを利用するわけだが、DirectX 9/SM3.0ではこの頂点シェーダーにおける定数レジスタの数が256個に限定されている。

　「CRYSIS」のキャラクタ達は1描画コールあたり70個程度のボーンがあり、1ボーンが2個のレジスタを活用するので2×70=140レジスタが必要になる。

　OMBを実現するにはキャラクタの前フレームのボーンの変形状態情報が必要になるので、さらに2倍……すなわち280個の定数レジスタが必要になってしまう。つまり、DirectX 9/SM3.0では実装できないことになる。

　Sousa氏も「OMB生成専用の少ないボーンのキャラクタモデルをDirectX 9/SM3.0環境専用に用意するという妥協案もないことはなかったが……」と振り返るが、結局のところ、DirectX 10/SM4.0以上専用のフィーチャーと決断したのだそうだ。まぁ、これはあくまで筆者個人の推測だが、DirectX 10/SM4.0以上のGPUを売っていきたいGPUメーカーの意向や、余計な作業を増やしたくないという思惑などがあった上での決断なのだろう。

　CMBではカメラの移動速度と奥行き情報をベースにブラーを掛けていたが、CMBでは奥行きだけでなく、キャラクタ、そしてその関節……など様々なものが異なる向きに、異なる速度で動くため一筋縄では行かない。

ステップ1：まずはベロシティマップを作成する

　そこで、各キャラクタの画面上でのピクセル単位の動きベクトル (ピクセル単位の速度に相当) をレンダーターゲット (テクスチャ) に書き込んでいく。具体的には前フレーム時の各頂点の位置と現在フレーム時の各頂点の位置の差分から各頂点単位の速度がわかるので、この情報をもとに、視点から見たピクセル単位の速度情報に変換して、FP16テクスチャ (R16G16B16A16F) に書き込んでいく。これが画面上の全ピクセル単位の速度分布を記録したテクスチャ「ベロシティマップ (Velocity Map)」となる。なお、「CRYSIS」では、ベロシティマップは表示フレームの半分の解像度になっているとのこと。

　ベロシティマップにはそれだけでなく、ブラー具合の重要なパラメータとなる奥行き情報 (深度値)、そのキャラクタのインスタンスIDなども書き込んでいるという。

　なお、CMBの時と同じようにOMBでも最適化措置と負荷低減の名目の特例措置が盛り込まれている。1つはまったくキャラクタが動かなかったとき。この場合、このベロシティマップに書き込むという処理そのものを省略する。もう1つ、たとえ動いていても、その動き速度が、ある決めた速度敷居値よりも低ければ速度ゼロとしてベロシティマップに書き込んでブラーを起こさせない……といった特別処理をしている。あまり動きが遅いものにブラーを掛けても負荷だけかかって見栄えに影響が無く、意味がないからだ。

左はベロシティマップを元にそのままブラーを掛けた場合。ブラーとそうでないところに不自然な境界線が出てしまっている。また、ブラー幅も小さい。そこで「CE2」開発チームは右のようにスムーズで長い残像を出すのを目標とした

　このベロシティマップだけでOMBをやろうとすると、動いてブラーが起こっているところとそうでないところの境界線が強く出てしまうアーティファクトが生じる。「ロストプラネット」もそうであったように、OMBを実装しているほとんどの3Dゲームでは、このアーティファクトについては無視している。

　また、「ロストプラネット」ではブレをダイナミックにするために、前フレームの頂点位置から現在フレームの頂点位置まで頂点を引き伸ばして、動きの軌跡としてのベロシティマップを作成していた。これには引き伸ばし用の頂点を生成するためにジオメトリシェーダーを使うか、あるいは引き伸ばし用の頂点を事前に3Dモデル側に仕込む必要がある。「CE2」ではそういった処理はしていないとなるとモーションブラーの効果が低くなってしまうのではないか。

　「CE2」開発チームはそうした問題に対し、比較的低コストで解決する仕組みを考案した。

ステップ2：ベロシティマスクを作成

　OMBでも、CMB同様のベロシティマスクを作成するが、その解像度は表示フレームの1/8の低解像度レンダーターゲットとしている。さらにこれを速度方向にガウス・ブラー (ボカし) を掛ける。ベロシティマスクの意義としてはCMBと同じだが、結果的にはモーション・ブラーが起きている箇所とそうでないところをスムーズに合成するためのうっすらとした型抜きの役割を果たすことになる。

　続いて、ステップ1で作成したベロシティマップを垂直方向2回、水平方向2回ガウス・ブラー (ボカし) で膨張させる。これが「ロストプラネット」の頂点引き伸ばしテクニックにかわる部分だ。

　なお、このボカしはベロシティマップの速度値を柔らかく拡散させる意味合いがあるので、キャラクタの実体がある場所のブラーは避ける。もちろん、ベロシティマスクに配慮し不用意なブラーも回避する。

ステップ3：ベロシティマップの膨張処理を行なう

　最終パスでは、ベロシティマップを参照してその速度方向にブラー処理をしていく。ブラー処理の際には、ベロシティマップ作成時に書き込んだキャラクタのインスタンスIDにも配慮して行なう。これはサンプル先のピクセルを読み出す前に、そこに対応するベロシティマップを参照してIDを比較する処理をしなければならず、負荷は軽くない。ただし、無関係なピクセルがブラーに流れ込んできてしまうアーティファクトを低減できるのでやる価値はあるとしている。なお、「ロストプラネット」では深度値を見て無関係ピクセルのブラーに対処していた。

　こうしたブラーのエラー・アーティファクトは「高速に動いているゲームの画面であれば気がつかないのでは?」という意見もあるが、バレットタイム的なスローモーション演出などが入った場合には、じっくりと見られて「おかしい」と思われてしまう可能性があるため、「CE2」では適切に対処したとしている。

最終的なブラー処理

最終的なブレンドマスク	最終シーン	なお、ブラー処理のサンプル方法はCMBとまったく同じで8サンプルを基本としてピンポン・ブラー法を実践している

　「CE2」のOMBの効果は「ロストプラネット」のような3Dモデルの事前の仕込みをしないわりにはそれなりの効果が得られ、満足はしているようだが、問題がないわけでもない。半透明オブジェクトが絡んでくるとおかしなことになってくることをSousa氏は指摘する。しかし、これにまともに処理しようとして頑張ったところで、負荷対効果の面であまりおいしくないのでやらなかったようだ。

　なお、この「CE2」のOMBは、パフォーマンス的にはGeForce 8800 GTX、1,280×1,024ドット解像度にて、平均2.5ms程度の処理時間ですんでいるとのこと。

■ スクリーンスペースの光筋表現

　「CRYSIS」で印象的なビジュアルといえば逆光時に生じる光筋表現だ。一見するとなにやら高度なボリュームレンダリング的な技法が用いられているのか……と思えてしまうが、実際にはポストプロセスで実装されている。

　まず、太陽を遮蔽しているマスクを、シーンをレンダリングた後に残っている深度バッファから生成する。次にこのマスクを画面上の太陽位置から放射状にブラーを掛ける。これと同じ方向に太陽をブラーして拡大。双方をマスクしつつ合成すればできあがりだ。

　つまり、逆光の太陽を遮っている遮蔽物の影が広がり、それ自体が、同じ方向に広がっている太陽光を遮蔽している……というような感じだ。

　ブラーのサンプル方法についてはモーションブラーの時と同じピンポンブラー法が用いられており、「CRYSIS」では8サンプルの3パスによる仮想的な512サンプルでこの光筋表現を実装しているとのこと。

ポストプロセスによる光筋表現	太陽を遮っているマスクを放射状に拡大
実際のゲーム中での表現

　なお、この方式とほぼ同じ光筋表現はかつてのNVIDIA GeForce 6000シリーズの人魚デモ「NALU」で実装されたことがあった。

NVIDIAの「NALU」におけるほぼ同技法の光筋表現

　CRYTEKより、このポストプロセス関連の映像素材も頂いているのでここに示しておく。モーションブラーの効果、光筋表現の効果などが見られるようになっている。

【ポストプロセス関連のムービー】
[WMV形式: 12.6MB 26秒] ZIP圧縮 ※クリックするとダウンロードが始まります

■ まとめ

　水面に関しては、これまでの水面の表現に対して、GPU性能の向上分、新要素を追加したような実装になっており、2004年の「Far Cry」の時と比較するとずいぶんと進化したことが見て取れる。

　この部分については、これから先もGPU性能の強化と技術力の向上とともにさらにリアルになっていくことだろう。今後の進化ぶりが楽しみだ。

「Far Cry」(2004) における水面表現。この時の水面は法線マップによるもので実際の凹凸はなかった
「CRYSIS」(2007) における水面表現。実際の凹凸を獲得し水面、水面下の表現が各段に進化した

　筆者個人としては、今後の3Dゲームグラフィックスの1つのトレンドの方向性をほのめかしている……もっといえば、DirectX 10/SM4.0時代以降の3Dゲームグラフィックスの試金石的存在となりそうだと予感したのが「凍り付きシェーダー」のコンセプトであった。

　いや、「凍り付いた世界の再現の素晴らしさ」を言っているのではない。

　その再現に、アーティストへの負荷を減らし、構築済みのゲーム世界に対して、AI的なアプローチのシェーダーによって全く別の見栄えのものに作り替えてしまうプロシージャル・アプローチをいち早く実用化したことに感銘を受けたのだ。

　今回のGDC 2008でも、「CE2」ほどではないが、本連載で紹介したUBI SOFTの「DUNIA ENGINE」、ソニーの「PHYRE ENGINE」といい、プロシージャル的なアプローチでゲームコンテンツを構築しようとする実例が登場し始めてきている。

　GPUは年を経るごとにシェーダー数が増して演算能力が向上し、プログラマビリティについてはかなりCPUに近づきつつある。今年または来年には、シェーダーそのものがx86コアといえるメニーコアプロセッサ、Intelの「Larrabee (ララビー)」が登場してくると言われる。

　つまり、3Dグラフィックスのシェーダーに「知性的」なものをインプリメントすることが近未来には可能になってくるかもしれず、その先駆けとして、この「CE2」の「凍り付きシェーダー」は興味深いのだ。

　「HDRレンダリング」、「法線マップ」、「リアルタイム影生成」で底上げされた今世代の3Dゲームグラフィックスは、今後、この知性的シェーダー……すなわち3Dグラフィックスのプロシージャル的アプローチを目標に進化していくような気がする。

□CRYTEK(英語)のホームページ
http://www.crytek.com/
□Game Developers Conference(英語)のホームページ
http://www.gdconf.com/
□Game Developers Conference(日本語)のホームページ
http://japan.gdconf.com/
□関連情報
3Dゲームファンのためのグラフィックス講座 バックナンバー
http://game.watch.impress.co.jp/docs/backno/rensai/3dg.htm
【2007年3月7日】西川善司の3Dゲームファンのためのグラフィックス講座
「CRYTEK CRYENGINE2.0」GDC 2007特別編
屋外の自然表現にこだわったリアル系グラフィックスマジックの秘密
http://game.watch.impress.co.jp/docs/20070307/cry2.htm

(2008年3月10日)

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