【著者近影】
大画面と多画面と、そしてゲームグラフィックスを愛するテクニカルジャーナリスト。本誌では主にGPUや3Dグラフィックス関連の記事を執筆している。生まれて初めて所有したパソコンはシャープ「MZ-721」。PSPに必ず入れておくソフトは「もじぴったん」(バンダイナムコゲームス)で、コツコツパズルの最終問題に悩み続けて早4年。未だ、この1問を残す。個人ブログはこちら

　今や世界で最も有名なゲームエンジンとなったEpic Gamesの「Unreal Engine 3」(「UE3」)。今年も年次更新的バージョンアップが図られている。バージョン番号に大きな変更はないが、ライセンシーからの要望への対応、技術トレンドの導入により今年もいくつかの大がかりな機能強化が図られている。

　今回はこの新版「UE3」の機能強化点の紹介を皮切りに、新生「UE3」の最初の自社採用タイトルである「Gears of War 2」のグラフィックスの秘密に迫ってみたいと思う。

■ 新版「UE3」のグラフィックス・エンジン・フィーチャー その1「グローバル・イルミネーション」

「UE3」の新機能について語ってくれたJames Golding氏(Epic Games、Senior Programmer)

演算結果のGIは頂点単位に出力することも可能。これに法線マップを適用すればGIベースでの陰影がでる

　本連載「ソニック・ワールド・アドベンチャー」編でも取り上げたが、今期の3Dゲームグラフィックスはグローバル・イルミネーション（Global Illumination、GI)の導入がトレンドとなってきており、先進的なタイトルのほぼ全てが何らかの形でリアルタイムGIを導入しつつある。ちなみに、前回取り上げた「CRY ENGINE 3」、前々回で取り上げた「KILLZONE 2」でも、リアルタイムGIの導入がなされていた。

　こうしたトレンドを受けて、「UE3」もさっそくリアルタイムGIへの対応が行なわれている。格好いいブランド名を率先して付ける傾向にあるEpic Gamesは、今回も自社のGI技術には「Unreal Lightmass」テクノロジーと命名してその機能をアピールしている。

　「Unreal Lightmass」は、他タイトルの実装例と同じく、静的オブジェクトを配置した完成シーンに静的光源を設置した状態で相互反射まで配慮したGIを事前計算するテクニックになっている。算出されたGI情報はライトマップ(または頂点付随情報)として出力され、またシーン内において適当な間隔で全方位の環境光の往来を球面調和関数で持たせることができるようになっている。頂点付随情報で持たせた場合は、本連載「メタルギアソリッド4」編で紹介した分離プリライティング的なテクニック、「ラジオシティ法線マッピング」も実現できる。

　このLightmassテクノロジー発表に同期して、分散コンピューティングに対応したGI事前計算を行なうための専用ツール「Unreal Swarm」が発表されている。Swarmは虫などの“大群”を意味する言葉で、これまた実にEPICらしいネーミングだ。

　「Unreal Swarm」では、ネットワーク接続したマルチコアCPUベースの複数PCに、「Unreal Lightmass」の計算ジョブを発行でき、PC台数を増やせば増やすほど計算を短時間で終了できるスケーラブル設計になっている。各PCのハードウェアスペックはバラバラでも問題なく、「Unreal Swarm」が個々のPCのスペックに適したジョブを発注して全体として最大限のパフォーマンスが出せるようになっている。

【「Unreal Lightmass」（グローバル・イルミネーション）】
「UE3」もGIに対応。赤いカーテンの反射光が柱を赤く照らしている様に注目
「Unreal Lightmass」は透過材質のGIにも対応する

・その2「Unreal MCP」

　新生「UE3」では、統合的なネットワークサービスとして「Unreal Master Control System」(Unreal MCP)も用意している。これは「Gears of War 2」で既に導入実績のあるシステムで、ネットワークゲームプレイで必要とされる機能を総合的に備えたコンポーネント・ミドルウェアだ。例えば、ロビーでの複数プレーヤーをまとめて管理するマッチングシステムでは、パーティーを解散せずに別のマッチへ挑戦できるサービス機能などを備えている。

　また、ネットワークプレイのロギングシステムも持っており、各プレーヤーがマップ上をどう動いて、どのように攻撃を成功させたか、あるいは死亡したかといった情報をヒートマップ表示することができる。この機能はユーザーサービス向けにも利用できるし、あるいは開発途中におけるゲームバランス調整やマップデザインのチューニングにも有益となる。

　この他、マイクロソフトのLive Server Platformを介した「UE3」ベースゲームのPC版とXbox 360の相互通信をサポート。さらに「UE3」ベースであればPC版とプレイステーション 3版との相互通信もサポートするとしている。

【Unreal Master Control System】
マップ上で死亡率の高いところを赤く表示した図(ヒートマップ)。開発サイドとしては、こうした情報を、ゲームバランスの調整やマップの再設計に活用することになる

・その3「ナビゲーションメッシュ」、「コンテンツブラウザ」

　「UE3」のAIシステムが、ナビゲーションメッシュの自動生成に対応したことも発表された。ナビゲーションメッシュ(Navigation Meshes)とはキャラクターがゲーム内シーンを移動する際に利用する三角形ベースで構築された経路データのこと。

　ゲームシーンは多数のポリゴンで構成されるが、このままでは、ゲーム内を移動するキャラクターにとってはあまりにも漠然とし過ぎている。そこで、映像としてのポリゴンとは別に、キャラクターが移動出来る範囲を、キャラクターのおよその歩幅基準の大きさの三角形で紡いだ“道”を用意してやるのが常套手段となっている。これがナビゲーションメッシュだ。ランタイムのAIは移動するときにこのナビゲーションメッシュを基準に移動を考えればよくなる。

　「UE3」のAIはこのナビゲーションメッシュを自動生成し、また経路探索もこのナビゲーションメッシュベースで行なえるようになった。ナビゲーションメッシュの上を移動する場合においては、床とキャラクターとの相対的な位置関係が固定化されるため、キャラクターは床との衝突判定を省略できることになり、これはパフォーマンス向上にも結びつくとしている。

　また、プレイステーション 3のネットワークサービスで「UE3」ベースのゲームが提供できるように対応したこともアナウンスされた。今後は安価な「UE3」ベースのカジュアルゲームがプレイステーション 3で楽しめるようになるかもしれない。

　クリエーションサイドの話題としてはライセンシー向け開発支援ツールとして強力な「コンテンツ・ブラウザ」の提供が始まることも告げられている。コンテンツ・ブラウザとは、作成した3Dモデル、マテリアルシェーダ、サウンド、アニメーションといった「UE3」ベース素材を、ファイルの実態存在場所に依存せずに、総括的に分類、そしてアクセスできるツールだ。

　Epic Gamesによれば「Flickrにインスパイアされた」とのことで、「UE3」素材を自在にカテゴライズでき、また効率よく呼び出せる設計になっている。プレビュー画面はリアルタイムレンダリングされたものであり、エンジン上で描画される実態とほぼ同じ状態で見ることができ、「UE3」の各種エディタツールに、コンテンツ・ブラウザからドラッグ・アンド・ドロップして利用することも可能。提供される機能としてはシンプルだが、膨大な素材を取り扱うことになる大規模ゲーム制作においては強力な武器になりそうなツールだ。

　なお、ここまで、紹介した新「UE3」の機能のうちコンテンツ・ブラウザ、Unreal MCP、グローバル・イルミネーションについてはデモ映像が提供されているので、そちらも合わせてみてみて欲しい。

【コンテンツブラウザ】
新「UE3」のコンテンツ・ブラウザ。「UE3」の各種エディタツールにアイテムをドラッグ・アンド・ドロップ可能

■ 「GoW2」の残虐表現～事前人体分断処理による実装

「Gears of War 2」の残虐表現の裏側について語ったNiklas Smedberg氏(Senior Engine Programmer,Epic Games, Inc.)

死体を盾にして戦う「肉盾」戦法。「GoW」らしい表現だ

　ここからは、この新「UE3」開発のリアル・テストケースとなった「Gears of War 2」(「GoW2」)のレンダリング・テクニックについて見ていくことにしたい。

　2008年に発売された「GoW2」は、世界で450万本を売り上げたXbox 360専用の大ヒットタイトルで、世界中で117個ものゲーム賞の獲得とノミネーションを受けた実績を持つ。日本でもついに待望の完全日本語版が7月30日に発売される。

　さて、この「GoW2」で特筆すべき点はいくつもあるが、やはり、まず取り上げるべきなのは、徹底した残虐表現ではないだろうか。「GoW」シリーズの代表的な残虐表現と言えるのはやはり分断表現(ゴア表現)だろう。

　前作「GoW」でも分断表現は存在したが、分断された瞬間にシンプルな1ボーンによるスキニング表現に切り替えていたため、注意深く見ていると少々不自然に見えることがあった。「GoW2」では、この反省を踏まえて、分断された部位も4ボーンのスキニングを行なうことでシームレスな柔体(Soft Body)表現の分断表現を実現している。

　分断される単位は、実はアーティストが手作業で事前に細かく分断したモデルを作り込んでいる。また切断面から見える内蔵や骨格の様子についても手作業によるモデリングとテクスチャの描き込みを行なっている。意外にも、この部分はいわゆる「作り込み系」であり、プロシージャル的なアプローチは採用されていない。つまり、攻撃によってキャラクターの部位が切り落とされる場合、その切断面はあらかじめ決まっているということになる。ただ、ダメージを受けたキャラクターとそうでないキャラクターとで、ゲームプログラム上での負荷が大きく変わらないように心がけてデザインがなされたという。

　各身体の部位にはヒットポイントが仕掛けられており、攻撃がそのヒットポイントを消費しきると、スクリプトベースで部位がボーンの接続部単位で破損するようになっている。破損した部位の飛散は物理シミュレーションに従うが、破損のきっかけは「GoW」と同様にスクリプトベース(つまりゲームロジックでの管理制御)になっている。これは、ゲーム性と演出を考えた場合、最適だと判断されたためだ。

　大型のボスの破損表現については、「UE3」のUnreal Editorベースで仕込まれたデータ駆動型の破損表現になっている。ダメージによって外装が破損していき、中身が見えていくようなダメージ表現がそれだ。大型のボスでは末端が切断されるというよりは、外装が剥がれていき、だんだん傷口が広がっていくというような表現(および処理系)になっている。

　死体についての破損表現もスクリプトベースで制御されている。ここでいう死体とは、完全なラグドールのことで、自発的なアニメーションやゲームプレイに直接関与しない人体オブジェクトのこと。死体でもやはり、ダメージを受けた箇所の事前分断単位で破損するようになっているが、手榴弾などの攻撃を受けるとバラバラになって飛散する、特別な処理系も盛り込まれている。

　なお、部位単位で破損はするが、ダメージ管理を部位単位で行なわない処理系もある。それは「肉盾」(Meatshield)戦法の処理においてだ。「GoW2」では死体を羽交い締めにして持ち上げ、これを敵からの銃撃の盾にすることができるが、これは肉盾全体のヒットポイントを持っており、その低下に応じて部位が外れていくという表現になっている。つまり、肉盾の胴体に銃弾が当たり続けていても、一定量のダメージを受けると腕が外れたりする。いわば部位の脱落具合が肉盾のヒットポイント表現になっている。このあたりはゲーム表現としてわかりやすさを優先して割り切っている格好だ。

【人体分断】
事前分断された人体。「GoW2」ではこの分解度で破損する	いくつかのキャラクターはここまでの粒度の事前分断処理を行なっている

【ボスの破損表現】
ボス「Brumak」が受けたダメージで破損していく様子

【ダメージ管理】
「肉盾」戦法については部位ごとは損するがダメージ管理は全体で行なっている

■ 「GoW2」の流血表現のテクニック(1)～「血痕シェーダー」

流血しながら這いずり回るとその軌跡が地面に絵筆のように描かれる

このように重ね描きされて実現される流血の軌跡

　「GoW2」は分断表現もさることながら、かなりアグレッシブな流血表現を実装している。流血量は、おそらく、ゲーム史上でもトップクラスとも思えるほどだが、実際、流血表現のためのテクニックも並のゲームの数倍は力が入っていると感じる。まず飛び散った血しぶきはゲーム世界に血痕を残す。この血痕は「GoW2」のシステムでは基本的にデカールテクスチャとしてレンダリングされる。

　基本的な仕組みとして「投射テクスチャマッピング」(Projected Texture Mapping)的な実装になるが、単なる1枚の画像テクスチャの貼り付けではなく、システム上、アーティストが創意工夫したマテリアル表現を伴って適用できるようになっている。具体的には、カスタム材質シェーダ、ライティング、半透明合成、法線マップ、ムービーテクスチャなど。

　「GoW2」では、壮絶な流血表現を行なうために、血痕デカールは大量に描画されるが、Xbox 360とはいえリソースは無限ではないため、「最後に描かれた視界外のもの→最後に描かれた視界内のもの」という優先度でゲーム世界から消失させ、新たな血痕デカールの描画に回す最適化を行なっている。また、無駄な重ね描きを避けるために、描画先の隣接付近に既に血痕デカールが描かれていないかのチェックも行なっている。

　基本的には投射テクスチャマッピングだが、血痕デカールの投射対象によっては特別な追加処理が必要な場合もあり、「GoW2」ではそれらをまじめにこなしている。例えば、静的な背景オブジェクトに対しての血痕には、ちゃんとそこに適用されているライトマップを配慮したライティングをするし、動的な光源の影響下に飛び散った血痕には追加のライティングまで行なう。

　地味に凄いのは動的キャラクターに対しても血痕が付着するという点だ。この効果は動的なキャラクターのローカルスペースでの特別な投射テクスチャマッピング処理を行なって実現している。こうした工夫により、付着した血痕はただの固定色の赤ではなく、そのシーンに適切なライティングがなされた生々しいハイライトを伴った血痕となる。

　ちなみに、流血した動的キャラクターが這いずり回った時には、その這いずり方向に不透明度を上げたグラデーション血痕を0.5秒おきに描き、その這いずりによる流血の軌跡が絵筆の軌跡のように見えるような特別な描画を実践している。さらにこの血痕のグラデーションが機械的に行われていることがばれないように(パターン性が知覚されないように)、時々、通常の血痕デカールを混ぜて描いているという。凄いこだわりだ。

【血痕】
床の凹凸に的確に投射されている血痕

・ 「GoW2」の流血表現のテクニック(2)～「血しぶきシェーダー」

　「GoW2」は血しぶきの表現にも力が入っているが、この血しぶきエフェクトは、大別すると2D的なテクニックと3D的なテクニックに大別される。2D的なテクニックとは、プレイ中のカメラ面に付着する血しぶきのこと。これには開発チーム内で「Screen Space Blood Splatter」(SSBS、画面座標系血しぶき)という、これまた凄まじいテクノロジー名が付けられている。

　名前は凄いがSSBSは処理としては実はシンプルだったりする。飛散する血しぶきは3Dパーティクル(いわゆるビルボード)的なもので、実際のゲーム中でのキャラクターの被弾やダメージエフェクトにシンクロした流血イベントをきっかけに発生し、画面に付着する。前述の血痕デカールと同じく、カスタムシェーダによる材質表現が適用されたり、法線マップを伴っていたり、動くムービーテクスチャだったりと様々なテクニックを血しぶきパーティクルに適用できるようになっている。

　一方、3D的なテクニックとは、ゲーム内シーンで飛び散る血しぶきのこと。この3D的なテクニックの方でも用いるのは基本的には3Dパーティクルになる。このパーティクルに適用するテクスチャは上方を明るく下方を暗くするような疑似ライティングを行ない、さらに法線マップも適用して立体感を出している。

　液体が蠢いている感じのムービーテクスチャは4レイヤーの6フレームの反復テクスチャを用意しており、これを適当なテクスチャアドレスでサンプルして使うような実装になっている。この液体ムービーテクスチャはカラーマップが2048×1024テクセル、対応する法線マップが1,024×512テクセルの解像度で意外に大きい。なお、この液体ムービーテクスチャは流血表現だけでなく、色を変えて、水などのその他の液体表現にも流用しているとのこと。

・ 「GoW2」の流血表現のテクニック(3)～「血みどろシェーダー」

動的キャラクターにベットリ染みつく血液はスペシャルシェーダーによって実現されている

　「GoW2」では血みどろの巨大な生体兵器「Riftworm」の体内に閉じ込められるシーンがある。このシーンではまさに血の海に浸かりながらの行動になる。そこでは出血とか血しぶきとかいうレベルではなく、身体に血が付着しまくるのだが、この表現には「GoW2」ではスペシャルなシェーダーを用意して対応している。

　それがSurface Space Blood Effects(オブジェクト座標系血みどろ効果)だ。本稿では説明の都合上「血みどろシェーダー」として呼称するが、このシェーダーは0～1の実数引数によって駆動され、0が綺麗な状態、1が血みどろな状態を作り出すように設計されている。

　このシェーダーは動的キャラクターのピクセル単位の陰影処理の際に利用されるわけだが、キャラクターの衣装の材質や凹凸の都合に配慮するため、どの部分に血が付きやすいかのマスク・テクスチャを各キャラクターは持たされている。マスクテクスチャとは、例えば突起しているディテール部には血は付きにくく、溝になっている部分や布の部分らは血が付きやすいといった“血の付きやすさ分布”に相当する。

　各ピクセルはライティング結果と、通常のテクスチャ色と血の色の乗算色で決定されるが、血の量が少ないところはそのピクセル色の青(B)と緑（G)要素を減退させる演算も行なう。これは血の色が支配的になる前にその材質色が黒っぽくシミになるサマを表現することに繋がるのだ。

　キャラクターに付着した血液がだらりと流れ落ちるサマは、法線マップ付きの血糊テクスチャをテクスチャ座標系でワールド座標系で下方向(すなわちゲーム世界基準で重力方向)にスクロールさせることで実現している。

・ 「GoW2」の流血表現のテクニック(4)～「流体シミュレーション」

　前述したようにRiftwormのシーンでは血の海が登場するが、この血の表面の動きには流体シミュレーション(実際には液体面の波動シミュレーション)が適用されている。この波動シミュレーションはゲームロジックやレンダリング制御のスレッドとは非同期の、別スレッドで駆動されている。「UE3」では流体シミュレーションをCPUあるいはGPUのいずれでも実施できるが、Golding氏の説明を聞く限りでは「GoW2」では前者を選択しているようだ。

　波動シミュレーションの結果はハイトマップとして出力され、これを頂点テクスチャとして取り扱って、Xbox 360 GPU特有の機能であるテッセレーション機能を活用してジオメトリレベルの凹凸へと変換して描画している。なので、掠め見たときにも実態感のある凹凸の波を見ることができる。タプンタプンと揺れ動く血の海の表面は色は違うが、一般的な水面の波動表現を利用しているのだ。

　放出される血液や脈打つ動脈や膜の表現は、流体シミュレーションではなく、「動き前」と「動き後」の頂点位置を指定されたタイミングで反復往来するような頂点モーフィング(頂点アニメーション)で実現されている。最後に示す映像では、動的キャラクターには前出の血みどろシェーダーが適用され、ドバーっと噴出する血は頂点モーフィングが適用されているので、観察してみて欲しい。

■ 「GoW2」における疑似GI手法(1)～静的光源の配置の工夫で実現

「GoW2」におけるレンダリングテクニックについて語ったDaniel Wright氏(Epic Games,Engine Programmer)

　徹底したリアリズムを追求する「UE3」、そしてそのエンジンデモ的なタイトルである「GoW2」では、それまでの動的な光源によるライティングを超えた、ゲーム内シーンに溶け込むような動的キャラクターのライティングの手法が必須と考え、これが疑似GI手法の開発動機となっている。そして、この「GoW2」向けの技術開発が新生「UE3」におけるLightmass機能の実装にも繋がったのだろう。

　「GoW2」の疑似GI開発時に掲げたもうひとつのテーマは、アーティストの特別な作業工程が不要であるということ。表現できる効果が高くてもアーティストやデザイナーへの作業利用が増しては意味がないと考え、基本的な初期設定をすればあとはランタイムで的確な効果が得られることを重視したというわけだ。

　「GoW2」では、開発段階において、背景に無数の静的な光源を設定しているが、デフォルトでは設定した光源は直接光のみを発生する光源となっている。デザイナーは、このうち、任意の静的光源を環境光(fill light)として設定できる。この環境光は「疑似的なGI環境光」として設定される。

　このうち環境光として設定された光からのライティングはリアルタイムレンダリングとは別スレッドで計算させてライトマップへと書き出しておくので、リアルタイムレンダリング時のライティング負荷にはならない。ただし、環境光がゲーム進行等の都合で消失した場合は、複数フレームにまたがる格好で、このライトマップは再更新されることになる。まとめると、疑似GIとはいうものの、実際には、GIっぽくみえるように、たくさんの静的な光源を配置しているだけに過ぎない。

　動的なキャラクターのライティングは、これらの静的光源に全て配慮することだが、パフォーマンス的な意味合いにおいても、GPUのプログラマブルシェーダの仕様的な制限においても現実的なソリューションではない。そこで「GoW2」ではユニークな方法を用いて、動的なキャラクターのライティングに取り組んだ。

【静的光源】
[S]として設定されているのが静的光源(Static Light)	その光の影響範囲を可視化した図がこちら
直接光としてライティングに影響する静的光源	疑似的なGIを実現するために設定された静的光源達。環境光的な役割を果たす

・ 「GoW2」における疑似GI手法(2)～「球面調和関数を用いて全方位環境光を動的に調合」

l=0、1、2、3… m=-l～+lにおける球面調和関数の3次元可視化図。「GoW2」ではl=2の3段目まで使うので総計9個の球面調和関数を使うことになる

　「GoW2」では動的キャラクターごとに、その位置から近隣の光源に対してレイを飛ばして、動的キャラクターへのライティングに影響すると判断できる光源を選択する。その選択された複数の光源達、全方位からの光の入射量を9個の係数からなる球面調和関数として合成する。球面調和関数については本連載「KILLZONE2」講座を参照してほしい。

　実際のライティングでは、この球面調和関数をデコードして最も影響力の強い(光量の多い)方向からの光を選択して、これを動的キャラクターに対してのプライマリ光源としてライティングを行なう。遠距離のキャラクターなど、適当なクオリティでのライティングで留めたい場合は、さらに球面調和関数から天球方向からの光と地面方向からの光を取りだして、これを元に半球ライティングを行なう。

　近場のキャラクターにはハイクオリティなライティングを行なうが、これは球面調和関数で表現されている全方向の入射光情報を利用して、動的キャラクターをライティングすることで実施する。具体的にはレンダリングする際の各ピクセル単位で、そのピクセルの法線方向の環境光を球面調和関数をデコードして取ってくると言うようなイメージになる。

【ライティング】
全方位の光を球面調和関数として合成	球面調和関数から抽出した1番影響力の強い光源でライティング
半球ライティングとは環境光を天地からの2方向に簡略化したもの	中程度のクオリティのライティングでは代表光源からのライティング以外に半球ライティングを行なうのみとする
真ん中が球面調和関数による間接光のみライティング結果。一様同色になりがちだった前出の半球ライティングの結果と比べると、こちらの方は環境光の方向性が感じられる結果になっている	テクスチャ類や材質シェーダーまでを適用した最終的なライティング結果

・ 「GoW2」における疑似GI手法(3)～「影生成」

影はプライマリ光源からのみ行ない、影には環境光の影響が出るようにしてGIぽい雰囲気を演出

　影生成は、球面調和関数から取り出した最も影響力の大きいプライマリ光源から行なっている。面白いのは、影生成をしたあとに、“セカンダリ光源”とも言える半球ライティング、あるいは球面調和関数ベースの全方位のピクセル単位の環境光によるライティングを行なうところ。これにより、生成された影自体がほのかな環境光で照らされるため、GIぽい雰囲気が増す。

■ 「GoW2」におけるScreen Space Ambient Occlusion(1)～SSAOの動作原理

SSAOの原理

　CRYTEKが考案したと言われるScreen Space Ambient Occlusion(SSAO、画面座標系環境遮蔽)は静的なシーン、動的なシーンに関係なくレンダリング結果に対してポストプロセスでGI的な陰影表現ができることから、今なお高い関心を持って改良型の研究が進められているテクニックだ。

　EPICでもさっそく「GoW2」にSSAOを採用したが、その際にSSAO特有の“アーティファクト”が問題となったようだ。順だって解説するのに、まずは、SSAOの仕組みについて簡単に整理しておこう。

　SSAOにはレンダリング結果の深度値を利用する。任意のピクセルの深度値よりも、周辺の深度値の方が出っぱっていて、そのピクセルが遮蔽されていると判断できたとき、そのピクセルを濃いめの色にする。つまり遮蔽率が高ければ高いほどピクセルの色を濃くするのだ。これを反復的に全ピクセルに対して行なうことで、通常のライティングや動的影生成では出すことのできない淡い“陰”を出すことができる。これがSSAOの基本的なアプローチだ。

　SSAOは画面座標系での処理なので、視線角度によって遮蔽陰影が変わってしまうという弊害があり、これを避けるために遮蔽を調査する際のサンプル数を少なくし、さらにノイズを与えて散らす工夫も行なう。しかし、これはかえって視線やオブジェクトが動いたときに遮蔽陰影に不自然な高周波ノイズを与えてしまう結果となる。

　そこで、一般的なSSAO実装例では、これを排除するためにローパスフィルタで遮蔽陰影部分をぼかす処理も加える。ただ、これもかけ過ぎるとディテール感が失われるので、そのグラフィックスエンジンごとのチューニングを行なって適切なボカし量に調整することが重要となる。また、ポリゴン輪郭付近の陰影遮蔽はボカしすぎると染み出てきて、ポリゴン輪郭をぼんやりとさせてしまう。これへの対策は、ボカしフィルタ処理時に深度値を見てエッジと判断できる部分については選択的にぼかさない処理を加えるのが常套手段となっている。

　SSAOは、このように重い処理系だが、ハイエンドPCゲームでは採用が相次いでおり、例えば、あの「Starcraft 2」(Blizzard)でも採用されていることが「SIGGRAPH2008」で発表されている。しかし、家庭用ゲーム機では、採用例がなく、EPICは「GoW2」が家庭用ゲーム機タイトルとしては世界初のSSAO採用例だという。

【SSAO その1】
ノイジーになってしまった低サンプルSSAO	輪郭以外をボカしてノイズを低減させたSSAO

・ 「GoW2」におけるScreen Space Ambient Occlusion(2)～「GoW2」におけるSSAO最適化手法

　「GoW2」では最初スタートしたのが1,280×720ドット解像度で、近傍16サンプルの遮蔽調査を行ない、遮蔽陰影の出力も1,280×720ドットで、さらにこれに20サンプルのボカしフィルタを適用するというSSAOだったそうだ。これは贅沢な方法だっただけにクオリティが高かったが、とてもリアルタイムゲームで使えるパフォーマンスではなかった。

　そこでトレードオフを意識しつつ、クオリティを下げてパフォーマンスを稼ぐチューニングを試みた。最初開発チームが試したのは遮蔽調査のサンプル数を半分の8に減らし、ボカしフィルタも12サンプルに削減するチューニングだった。これは劇的なパフォーマンス向上をもたらしたものの、遮蔽陰影が的確な周辺のジオメトリ情報を反映せずにぼやけて、さらにボツボツとした低解像感を与えてしまった。ボカしも大ざっぱになったことで、ノイジーな印象も残ることとなってしまう。

【SSAO その2】
「GoW2」の初期仕様SSAO	ライティング結果のみ	SSAOと合成した最終ショット。クオリティは高いが重かった

遮蔽調査のサンプル数を8に減らし、ボカしフィルタも12サンプルに削減した状態	遮蔽調査のサンプル数16、ボカしフィルタ20サンプル	遮蔽調査のサンプル数8、ボカしフィルタ12サンプル

　そこで、SSAOの生成解像度そのものを下げるアプローチを導入する。具体的には縦横半分の1/4解像度で行なう。いってみれば、サンプル数を少 なくしたので、これに合わせて解像度も下げてバランスを取ったという感じだ。もともとSSAOで得られる遮蔽陰影には高解像度のものは求められていない。 高解像度フレームに対して低密度な遮蔽調査を行なってスカスカしてしまうよりは、適度にぼけながらも隙間感のない、連続した遮蔽陰影が得られる方が望まし い。

　この際に問題なるのが、SSAOの遮蔽調査対象とするデプスバッファ(深度パッファ)をどう取り扱うかという問題。デプスバッファの 解像度はレンダリング解像度(1,280×720ドット)のままなので、ポイントサンプルで代表点的な深度値を取ってくることになるが、これをやると、 エッジ付近の遮蔽調査にミスを生じやすく(2×2分の深度値のうち1つしか拾われないため)、最終的に得られた遮蔽陰影を合成したときにはエッジ付近にチ ラツキのエラーを生じてしまうこととなる。

　そこで対策として、調査対象の2×2の深度バッファを読み出して、最も奥行きが大きい(1番遠 い)深度値を起点として遮蔽調査を行なうように調整している。これをやると、輪郭に黒い遮蔽陰影が付きやすくなって縁取りっぽく見えてしまうはずだが、 「チラツキが出るよりはまし」という判断のようだ。

　この部分の処理系をさらに推し進める意味合いで、SSAOの遮蔽陰影の出力先の1/4 低解像度バッファに、SSAOの遮蔽調査対象とするフル解像度のデプスバッファの値を盛り込んでしまう。この際には2×2分の深度値の最も遠い値を入れて やる。いちいち遮蔽調査の際に2×2分の深度値を読み直すよりもこの方が効率がいい。

　バッファのフォーマットはRG16F(2要素の16ビット浮動小数点32ビットバッファ)で、16ビット分にこの代表深度値、もう16ビット分に遮蔽調査を行なったあとの遮蔽陰影項を格納する。

　 SSAOパスを完了するとこの1/4低解像度RG16Fバッファには(2x2で最も遠い)深度値と遮蔽陰影項が格納される。これは後段の遮蔽陰影のボカし 工程でも都合がいい。なぜなら、このバッファを読み出すだけで遮蔽項と深度値が読み出せてしまうため、深度値に着目したボカしフィルタの適用が高効率に行 なえるからだ。なかなかクレバーな実装だといえよう。

　また、さらに別の角度からの最適化も行なう。それはテクスチャキャッシュのスラッシ ングを避けるというもの。Xbox 360 GPUのテクスチャキャッシュは容量が32KBで、これらはテクスチャユニットに共有される格好で、テクスチャユニットが読み出したデータの局所性が高け れば高いほどパフォーマンスが上がるが、局所性がないとキャッシュの機能を果たせずパフォーマンスが低下してしまう。そのパフォーマンス落差たるや10倍 とも言われており、テクスチャを反復的にサンプルするシェーダーを動かす場合にはこの部分の最適化は死活問題となる。

　「GoW2」ではこのテクスチャキャッシュの恩恵をできるだけ受けられるようにするために、遮蔽調査のサンプルを行なう際、画面座標系で70ピクセルの範囲を超えたときには調査を打ち切る制限を付加している。

解像度を1/4にして同仕様でSSAOを得た状態。スカスカ感は低減された	エッジに明るいピクセルが出ているのが分かる。これがチラツキの元	着目した点の近傍の1番遠いところを調査開始点として遮蔽調査を行なうようにすればこのチラツキを押さえられる

・「GoW2」におけるScreen Space Ambient Occlusion(3)～SSAO残像の低減

「GoW2」におけるSSAOレンダリング例。静止画だと何の問題もないように思えるが……

Reverse Reprojection Cachingの動作概念フロー

　ここまでのレンダリング結果が右図になる。静止画で見た限りだと分からないが、実は動画で見ると重大なエラーが見て取れる。生成されたSSAO遮蔽陰影が、視点を動かしたりするとモヤモヤとした残像のような動きを見せるのだ。

　これを低減する最も単純な近道は径の大きいフィルタを掛けてしまうこと。ただし、これをやるとせっかく得られた遮蔽陰影の形状を薄めてしまう。そこで、「GoW2」ではReverse Reprojection Caching(逆方向再射影キャッシング)と呼ばれるテクニックを応用して時間方向のフィルタリングを行なってこのモヤモヤを除去することに取り組んだ。

　Reverse Reprojection Caching(RRC)は、前フレームレートとの相関を見てピクセルシェーダーの動作を制御する、本来はハイフレームレートを実現するための最適化テクニックとして考案されたものだ。「GoW2」では、このアイディアを応用して、時間方向の相関に着目した、いわば"3D"ボカしフィルタリングを実現したと言うことになる。

　RRCの処理次元はやはり画面座標系で、ピクセル単位の動きに着目した処理を行なう。まるでMPEG圧縮かなにかの処理のようだ。実装レベルの話は複雑なので省略するが、簡単にいうと、前フレームと現在フレームの各ピクセル単位の遮蔽値を比較して、遮蔽され続けているところは強くボカして、そうでないところは淡くフェードイン、フェードアウトさせるというような適応型のフィルタ処理を行なうのだ。こうすることで、遮蔽陰影が広く広がっている箇所のモヤモヤは低減され、遮蔽陰影の輪郭付近のディテール感はそれなりに維持されることになる。

　ちなみに、前フレームのピクセルの位置というのは静的な背景などについてはカメラ(視点)の動きを逆算することで求まるし、動いている物体については前フレームでの位置や姿勢がわかれば求まる。このあたりで使用されるテクニックはモーションブラー生成のテクニックとほぼ同じだ。

　この時間方向フィルタリングの効果により、視点が静止しているときのSSAOによる遮蔽陰影はそこそこノイジーのままだが、視点が動いたときには滑らかな遮蔽陰影となり、上で指摘したモヤモヤ感は劇的に低減される。

　「GoW2」の場合は基本的に動き回るゲームであり、また、静止していても高精細なテクスチャや法線マップが適用されるため、SSAOの遮蔽陰影が粗いと感じられることはまず無いようだ。

　ただ、映像を見てもらうとわかるが、始点の移動やキャラクターの移動によって画面外にクリップアウトされていく領域の遮蔽陰影は唐突に消えるし、逆に画面に新たに飛び込んでくる領域の遮蔽陰影は唐突に現われる。この点は、「GoW2」のというよりは画面座標系のポストプロセスであるSSAO自体の限界からくるアーティファクトだ。

　この他、「GoW2」ではSSAOを適用しても効果が薄いと予測される箇所については、SSAOの処理を省略する最適化も行なっている。具体的には、プレーヤーの姿と遠方情景を除外している。SSAO処理を除外するピクセルに対応するステンシルバッファにマーキングし、SSAOシェーダはこれをチェックしてSSAO処理を行なうか否かを決定している。これにより、視点から近い、遮蔽陰影が広く出る領域に対してのみSSAOが掛かることになる。

【SSAO その3】
動的オブジェクトの前位置の求め方	静的オブジェクトの前位置の求め方
視点静止状態はこの程度	視点が動くとここまで滑らかになる
こうしたシーンがあったとして	まずプレーヤーの姿をSSAO対象外としてマーク
ある一定距離以上の遠景もSSAO対象外としてマーク	こうして出来たマスクをスイッチにしてSSAOシェーダを動作させる

■ まとめ～「UE3」はこれからも汎用ゲームエンジンのベンチマーク的存在となる！

Xbox 360の今年のキラータイトルとなりそうな「Gears of War 2」

　「UE3」は、今年度以降、トレンドとなると予測されるリアルタイムGIへいち早く対応してきた。汎用ゲームエンジンは1度完成を見ると、なかなか新しい技術トレンドを盛り込まなくなり、時代と共に老朽化していくことが多いのだが、「UE3」の場合はしっかり年次更新をやってきており、全くペースが衰えることなく新テクノロジーを吸収してきている。このあたりはさすがは技術志向の高いEpic Gamesといったところか。

　ライバル「CRY ENGINE 2」に先行されたSSAOの機能も、「CRY ENGINEに遅れは取らない」と言わんばかりに、昨年のうちに「UE3」にさりげなく実装されたし、新機能搭載までのフットワークは軽い。「UE3」ならば、汎用ゲームエンジンベースでゲームを開発しても最新技術トレンドに遅れを取らないというわけだ。日本ではサポート問題で苦戦している「UE3」だが、今後もゲームエンジンの、そして3Dゲームグラフィックスの先端のベンチマーク的な存在として業界に刺激を与え続けて欲しいものだ。

　それと今回詳しく紹介した「Gears of War 2」の残虐表現に関するレンダリングテクニックは、ふだんなかなか表に出てこない部分だけに興味深い。人体をリアルにバラバラにすること、そして生々しい流血表現をいかに恐ろしくグロテスクに見せるかを、ここまで情熱を掛けて実装した3Dゲームはこれまでにない。他に誰もやってないことに先進的なテクニックを取り入れることは大きな意義がある。

　もちろんこうした考え方に賛否はあるだろうが、「Gears of War」シリーズはこの路線を極め、リアル系残虐シェーダーの開発にいそしんで欲しいと思う。なお、7月に発売される日本語版では、このテクニックがどの程度残されるのかが気になるところ。表現的な問題なので調整は色々と難しいとは思うが、本稿で紹介したテクノロジーの大部分が残っていることを期待したい。

　疑似GIについては、「GoW2」に実装されたテクニックは、静的光源を多量に置くという意外にも原始的で、新生「UE3」に搭載されたものよりもやや古くさい。ただ、現行のコンテンツパイプラインを崩さずに疑似GI的な表現を行ないたいという場合には参考になることだろう。

　SSAOについては、「GoW2」の実装例を見てきて、効果は大きいものの、万能でない部分もあるということがわかったのではないだろうか。ただ、SSAOによる柔らかい“陰”は、今年以降トレンドとなることが間違いない疑似GI表現とすこぶる相性がよいため、今後、疑似GI表現とセットで活用される機会が増えるに違いない。

(C) 2008 Epic Games, Inc., except underlying technology (C) 2008 Microsoft Corporation. All rights reserved.