このセッションは「NDA(秘密保持契約)ベース」ということであったが、今回、マイクロソフトおよび株式会社イニスの両方から特別に記事化の許可を頂けたのでここにレポートすることにした。

■　ゲームライクなリアルタイム・インタラクティブ・デモ「妖精が棲む森」とは?

株式会社イニス取締役副社長 矢野慶一氏

　デモの名称は「妖精の棲む森」。デモの開発を担当したのは「ガンダム・パイロット・アカデミー」などの開発を担当したことでも知られる株式会社イニス。

　ゲームライクなデモということだが、このデモはXbox 360上で動作するゲームエンジンの基本を制作し、その上で動作する形態を取っている。GPUメーカーが新GPUのたびに公開する自己完結した一過性のメガデモではない。

　実際の株式会社イニスがXbox 360のゲーム開発に利用できるエンジンとして制作が進められてきたとのことで、このエンジンには「nFactor2」という名称が付けられている(イニスにはnFactor1エンジンもある)。このnFactor2は、Xbox 360のハードウェアとしての特徴となっているマルチプロセッサCPUとプログラマブルシェーダ3.0仕様GPUを効果的に活用するようなエンジン・アーキテクチャとなっている。

　なお、このエンジンは「Unreal Engine」のような他社ライセンスや販売を前提としたエンジンではなく、あくまで社内向けに開発されたエンジンとのこと。このデモでは、実際にワールド内を歩き回ることができる上、ワールド内の様々なオブジェクトに相互干渉でき、非常にゲームライクな作りになっており、完成度が高い。開発期間についてはお茶を濁しつつも矢野氏は「数カ月間」という言い回しを使っていた。

　Xbox 360のゲームはどうなるのか、を推し量るものとしては最上のサンプルなので、目に付くテクニカルなフィーチャーを順番にじっくり見ていくことにしよう。

■　HDRレンダリング～Xbox 360特有のα2ビット、RGB10ビット浮動小数点実数のフォーマットを使用

空があまりにも明るいために空の明るさ基準でトーンマッピングが行なわれ妖精キャラクタが非常に暗く見えている。これもHDRレンダリング特有の表現だ

　次世代機では当たり前のレンダリングメソッドとなるハイ・ダイナミック・レンジ(HDR:High Dynamic Range)レンダリングが、このデモにも使われている。現実世界はディスプレイ機器で表現できる以上の高い表現幅(ダイナミックレンジ)に富んだ光/色に満ちあふれている。3Dグラフィックスにおいても、陰影処理自体を表現幅が広い数値系で行なって現実世界に即したレンダリングを行なおうとして生まれたのがHDRレンダリングだ。

　いわゆる1,677万色のバッファはαRGBがそれぞれ8ビット整数である32ビットバッファになっており、これはHDRという言葉に対してLDR(Low Dynamic Range)バッファと呼ばれる。HDRレンダリングではその高いダイナミックレンジ確保のために浮動小数点バッファ=HDRバッファを活用する。PCの世界のHDRバッファといえば、αRGBがそれぞれ32ビット浮動小数点(FP32)の128ビットFPバッファや、それぞれ16ビット浮動小数点(FP16)の64ビットFPバッファを使うことが多いが、省メモリが大前提の家庭用ゲーム機Xbox 360では、特別なモードが用意されているのだ。

　それはα2ビット、RGBが10ビット浮動小数点(FP10)のPCにはない特別なHDRバッファだ。ちなみにFP10の内訳は指数3ビット仮数7ビットの“7e3”となっており、Xbox 360のGPUでは、この32ビットFPバッファならば、加算ブレンディングではペナルティ無しでフル速度で実行できる。まさにハイダイナミックレンジ性とリアルタイム性が適度にバランスされた非常にゲーム向きなフォーマットだといえよう。このデモでは、レンダーターゲットのバッファとしてこのバッファを使い、環境マップなどのテクスチャについても同様のHDRフォーマットを採用しているとのことだ。

　さて、HDRレンダリングでは、その定義通り、ハイダイナミックレンジにレンダリングしたとしても、そのままディスプレイに表示することはできない。それはディスプレイが最大1,677万色カラーの表示能力しか持たないためだ。1,677万色カラー以上の表現域でレンダリングされるHDRレンダリングではディスプレイに表示するための後処理(ポストプロセス)が必要になる。

　人間の視覚のダイナミックレンジは120～140dBあると言われているが、色として正しく感知できる幅はこれよりもずっと狭く、正しく色が知覚できるように眼球の中の瞳孔を絞ったり開いたりして適正な光量を網膜に導いている。HDRレンダリング結果を1,677万色ディスプレイに表示するというのはハイダイナミックレンジな現実世界を人間が瞳の絞りを調整して網膜に適正光量を導くのとほぼ同義になるわけだ。

　この処理を行なうのがHDRレンダリングとペアになって行なわれることの多いトーンマッピング(Tone Mapping)と呼ばれるポスト処理だ。このデモでもトーンマッピングがHDRレンダリングされた結果の平均輝度に応じて動的に行なわれており、暗いところから明るいところへ、あるいは逆に明るいところから暗いところへ行ったときにスムーズに適正な輝度になって表示される。人間が明暗の違うところを行き来すると目が慣れるまで眩しすぎたり、見えにくかったりする経験をするが、あれがこのデモでも再現されているのだ。

明るい屋外から屋内に入ってきた際に、段々と目が慣れていく様子。これが動的にトーンマッピングを行なうことで実現される瞳孔シミュレーション

　また、適正輝度に調整され、そのシーンの適正輝度に対し相対的に強く輝いて見える箇所には、光があふれ出して見えるブルームやグレアといった効果を画像処理的に付加している。現実世界でも強い光を見ると光と遮蔽物の前後関係を無視して光が溢れだして見えたり、星形の輝きが見えたりするが、ああいった現象をこのデモでは再現しているのだ。

昼間のシーン。家やその他の小道具がHDR光源の太陽に照らされて白飛びしているだけでなく、その明るさが周囲にあふれ出しているブルーム効果が見て取れる

■　法線マッピング～ハイトマップ付きで視差マッピングまでをサポート

法線マッピングにより実現されたオブジェクトのサンプル。見た目には多ポリゴンのディテールが再現されている。実際にはジオメトリ情報が失われており、ピクセル陰影のみで表現されているディテールなのだ

　超多ポリゴンでモデリングした3Dキャラクタの見た目のディテールをほぼそのままに、低ポリゴンにてゲームエンジンで動作させるテクニックとして法線マッピング(正確には法線マップによるバンプマッピング)がある。プログラマブルシェーダ2.0時代以降、トレンドとなっているテクニックであり、プログラマブルシェーダ3.0アーキテクチャのXbox 360で動作するこのデモでも、この技術は当然のごとく使われている。

　「私どもイニスでは、かつてガンダム・パイロット・アカデミーをGeForce3 Ti 500ベースのPCハードで制作したことがあります。あの時も法線マッピングは使っていたんですが、あの時はパフォーマンス的な制約で、法線マップを適用できるオブジェクト数が限定的でした。今回のXbox 360で動作するデモでは登場するほぼ全てのオブジェクトに対して(法線マップを)適用していますが、パフォーマンスの落ち込みはありません。」(矢野氏)

　凹凸やシワなどのミクロスケール部分のディテールは最近にわかにブームとなっているソフト「Zbrush」を使用して制作しているとのこと。

　なお、このデモでは、法線マップのαチャネル部分には凹凸の物量を記録しており(これをハイトマップという)、このデータを利用した法線マッピングの進化形である「視差マッピング(Parallax Mapping)」をも実装している。

　視差マッピングとは、視線ベクトルとの位置関係とハイトマップからの高さデータを元に、法線マップから取り出す法線ベクトルをずらすことで、擬似的な視差を強調する効果を実現するテクニックだ。結果としては凹凸が強調され、視線の動きに呼応したリアルな凹凸感が得られるようになる。

多ポリゴンでモデリングされた石レリーフ(左)。そのポリゴン数は44,313ポリゴン。これを541ポリゴンにまで削減した低ポリゴンモデル(中央)。低ポリゴン化で失われた多ポリゴンモデルのディテール部を法線マップに落とし込むと上記のオブジェクトが完成する(右)

タワーに掘られた各種浮き彫り模様は視差マッピング/法線マッピングによるもの。見た目の1/8にポリゴン数が削減されているのだが、視線位置が変わるたびにディテールの陰影が変わるためにあたかも本当に凹凸があるかのように見える

■　ライトスペース・パースペクティヴ・シャドウマップ(Light-Space Perspective Shadow Maps)～3DMark05の影生成技法のさらなる進化形

シャドウマップ技法の効果的活用の元祖的存在である「スプリンターセル」シリーズ。画面は第2作目の「パンドラ・トゥモロー」

　次世代機ゲーム機ではHDRレンダリングと並ぶ重要なテーマとなっているのが「リアルタイム影生成」だ。

　このデモでは、「スプリンターセル」(UbiSoft)での採用で著名になった「シャドウマッピング(デプスシャドウ)技法」と同系列の「ライトスペース・パースペクティヴ・シャドウマップ(Light-Space Perspective Shadow Maps、以下LSPSM)」技法を実装している。

　LSPSMは、ウィーン工科大学のMichael Wimmer氏他が、2004年に「Eurographics Symposium on Rendering」に論文発表した技術で、パフォーマンスとクオリティがバランスされたゲーム向きなシャドウマッピング技法として注目を集めている。

　「PSM:Perspective Shadow Maps」というキーワードを聞いてピンと来た人もいるかもしれない。PSMはあの業界標準3Dベンチマークソフト「3DMark05」に採用された影生成技法だからだ。LSPSMは名前の通り、PSMの改良形なのだ。

　シャドウマッピング技法では、まず、光源から見たシーンの深度情報(奥行き情報)をテクスチャなどにレンダリングし「シャドウマップ」と呼ばれるその光源の遮蔽構造分布を生成することから始める。最終的なシーンのレンダリング時には、各ピクセル描画時に、そのピクセルが光源から遮蔽されているかどうかを、生成したシャドウマップを参照しながら描画していく。

　この技法では複雑な遮蔽構造に配慮できるために、相互投射影もセルフシャドウにも配慮した影生成が行なえる利点がある。しかし、その影のクオリティが、遮蔽構造を記録しておくシャドウマップのサイズに強く依存してしまう弱点がある。例えば500m×500m四方が見えているようなシーンのシャドウマップを512×512ドット(テクセル)で生成した場合、なんと約1m×約1mの領域の遮蔽構造が1テクセルに集約されてしまうことになり、非常に大ざっぱな影生成になってしまう。

シャドウマッピング技法の弱点(左)と、相対的に見て視点に近い位置に落ちる影にジャギーやフリッカー(チラツキ)が出やすい構造を示した図

光源視点でシャドウマップをレンダリングする際に、透視変換した座標系で行なうのがPSM。これで視点側から均等な解像度でのシャドウマップが生成できる

　この問題に対してPSMは「視点に近い位置のシャドウマップを高解像度で生成し、遠くに行くに従ってそれなりの解像度で処理する」という工夫で対処する。具体的にはシャドウマップ生成を、視界からの座標系、すなわち透視投影(perspective projection)した状態で生成しようという方針になる。これにより、近い位置のシャドウマップは高解像度になり遠くに行くに従ってそれなりの解像度になる。

　ところが、PSMにも欠点が残されていた。それは、シャドウマップの解像度が不十分だと、遠景の影が広範囲に描かれるシーンで、ひどいジャギー(エイリアシング)を起こしてしまうのだ。PSMではシャドウマップの生成の際に視点から見た透視投影を行なうわけだが、改良版のLSPSMでは、これに加え、最終レンダリングする視界がシャドウマップ領域を最大利用できるように光源座標系で最適化しつつ、シャドウマップを生成する。

　これによりシャドウマップの歪み方がPSMよりも大部緩やかになり、近景と遠景のシャドウマップの情報解像度の変化がなだらかになる。つまりは、近景と遠景の影の品質がより平均化されて、PSMで問題となった投射距離が長くなる影のジャギーがかなり低減されるようになるのだ。このデモでもアップになる妖精のセルフシャドウから遠景の建物の影までが非常に高品位に均一化されたものになっており、不自然さはほとんどない。

角の影が顔に、頭の影が肩に落ちているセルフシャドウ。床に落ちている影にもジャギーはない。近景の影にもジャギーが出にくいのはPSM系シャドウマッピングの特徴	橋の影が地面に落ちている。何気ないシーンだが、影の投射距離が大きくなるとPSM技法ではひどいジャギーがでるのだが、LSPSM技法を採用するこのデモではその心配もない

左からシャドウマップ技法の原型、PSM技法、LSPSM技法。シャドウマップ技法原型ではかなり影が大ざっぱになっている。PSM技法では近場の影はいいが遠い影が大ざっぱになってしまっている。LSPSMでは近場から遠景まで全ての影品質が均等

左からシャドウマップ技法の原型、PSM技法、LSPSM技法、それぞれのシャドウマップの内容。視点は光源位置になっている点に留意。半透明の白い領域はシャドウマップに対して視界が占める範囲

左からシャドウマップ技法の原型、PSM技法、LSPSM技法。シャドウマップ技法原型では遠景の影は許容範囲。PSM技法ではタワーの影にひどいエイリアシングが発生している

左からシャドウマップ技法の原型、PSM技法、LSPSM技法、それぞれのシャドウマップの内容。PSM技法で遠くのシャドウマップ情報が大ざっぱになりすぎて、これが大きな影を落とすシーンでは致命的なエイリアシングを生じる。LSPSMのシャドウマップでは遠景の情報が圧縮気味だがPSMほど極端ではない

■　プログラマブルシェーダとパフォーマンス

LSPSM技法といえども、本来は影に若干のジャギーが出るものなのだが、この動的分岐を活用した影ボカシ技法により影の輪郭をいい具合にぼやけさせている

同様のテクニックによる半影表現は「スプリンターセル」シリーズ最新作「カオス・セオリー」でも実装されている。いよいよプログラマブルシェーダ3.0時代に本格突入してきた

　Xbox 360のGPUはATIのR520ベースといわれており、プログラマブルシェーダ3.0“+”仕様のシェーダアーキテクチャになっている。

　このデモは、開発当初はアセンブラ言語でシェーダを書いていたのだが、これをマイクロソフトのシェーダ高級言語「HLSL」にて書き直してコンパイルしたところ、アセンブラコーディングしたシェーダよりもだいぶパフォーマンスが上がったという。また、シェーダ設計に効果的に貢献してくれたのは、プログラマブルピクセルシェーダ3.0になって初めてサポートされる、動的条件分岐だったそうだ。

　このデモの影生成にはLSPSMが活用されているのは前述した通りだが、影の輪郭が非常に柔らかでリアリスティックになっている。動的条件分岐は、この半影(Penumbra)生成に一役買っているのだ。

　この半影生成を行なうには、影の輪郭付近でより多くのシャドウマップ参照を行なってフィルタリングする処理が必要になるが、全てのピクセルに対して一様にこの処理をしていたのではとてつもなく遅くなってしまう。そこで、このデモでは、影を生成するシェーダにて、これから描画するピクセルが影の輪郭付近か否かどうかを判断して、輪郭付近の場合のみ多くのシャドウマップ参照を行なってやわらかい影生成を行なっている。

　矢野氏によれば「この条件分岐の有り無しではパフォーマンスで2倍は違った。」とのことだ。

　このほか、このデモでは、シーンのレンダリングには2xのアンチエイリアス処理を適用しているが、これによるパフォーマンス面でのペナルティはないという。これは、Xbox 360-GPUに接続されたeDRAMの速度とeDRAMに内包されたピクセルプロセッサの恩恵によるものだ。

　このeDRAMは、レンダリング専用バッファとして接続されているものでXbox 360-GPUとは32GB/secのバスで接続されている。内包されるピクセルプロセッサはGPU本体とは分離された形でレンダリング最終工程時のZ処理、α処理、ステンシル処理、MSAA処理などを行なう仕組みとなっている。マイクロソフトの技術者によればアンチエイリアス処理は10MB容量のeDRAMをオーバーしない限りは4xまでのアンチエイリアス処理はフルスピードで実行できると説明している。

　今回、イニスから頂いたスクリーンショットを見てもらうとわかるが、これまでの家庭用ゲーム機のグラフィックスとは違い、全くジャギーらしいジャギーがないのがおわかり頂けるだろう。

本稿で示している画面ショットはXbox 360開発機から直接キャプチャしたもの。Xbox 360のゲームはこの画面品質で表示されるのだ。Xbox 360ならば家庭用ゲーム機としては初のジャギーフリー映像が堪能できるわけだ

■　物理エンジンはマルチプロセッサ対応のNovodeXを使用

　このデモでは無数の椰子の実のような果実がピンボールのような感じで木の棒をボーリングのように倒すシーンや、この椰子の実を放り投げて建物を破壊するシーンなどが公開された。

　こうした衝突や破壊といったアクションは、物理エンジンによる挙動計算に基づいたものであるわけだが、このデモでは最近名前をよく聞くようになったAGEIAの「NovodeX」ライブラリを使用している。

AGEIAの物理エンジン「NovodeX」はマルチスレッドを前提に開発されてきており、Xbox 360やプレイステーション3のようなマルチコアCPUとの相性がよいとされる。画面はNovodeXのデモソフトの画面をリアルタイムキャプチャした物

　NovodeX採用の理由として筆頭に挙げられたのは「NovodeXがマルチプロセッサ前提のライブラリでありXbox 360のマルチコアCPUアーキテクチャに効果的に機能できるため」ということであった。

「非常に導入が楽でした。入れて1カ月くらいで動かせるようになりましたから」(矢野氏)

　妖精の髪型のHari物理はイニスの独自開発実装で、CPUとGPUの両方で物理シミュレーションを行なっているという。髪型については硬度が指定でき、髪の毛が立ったり、風に簡単になびかないような調整も物理パラメータの設定如何でリアルタイムに変更できるとのこと。

妖精が身につけている腕輪、アクセサリー類は妖精本体と物理エンジンで繋がっている	動き出せば身につけているアクセラリー類や髪の毛は物理シミュレーションに従って揺れる

ハンドルを回すとギヤが回転して仕掛けが動いて橋の上の籠の中の椰子の実がコロコロと転がり出す。ギヤの回転からボールの転がりまでが物理シミュレーション	椰子の実は転がって木でできたピンを倒す。ボーリングの要領だ。「いかにも物理エンジンを活用中」といった感じの印象的なシーン

椰子の実を拾って広場中央の塔に向かって投げてみる。命中すると、命中した箇所と衝突エネルギーに配慮した崩れ方をする。これも物理シミュレーションによるものだ

■　「妖精の棲む森」レンダリングパイプラインの解説

妖精デモのレンダリングパスの内訳

　今回の講演で興味深かったのは、このデモのグラフィックスのレンダリングパイプラインの構成やパフォーマンスを明らかにしたことだ。これでXbox 360でどの程度の複雑なグラフィックスを実際のゲームに盛り込めるかのアタリが付けられることになり、その価値は大きい。このデモのグラフィックスエンジンの総レンダリングパスは21～22パスだとのこと。その内訳は図のようになっている。

　シーン平均のポリゴン数は15万ポリゴン程度。頂点シェーダを回すことになるパスは最初の5パスくらいで、結局GPU自体は毎フレーム75万(15万×5パス)ポリゴンくらいを処理するくらいの概算になる。結局のところ、今世代でも描画負荷の大半はピクセルシェーダに集中することになるようだ。

左が光源を仮想視点にシーンをZバッファにレンダリングしたシャドウマップ。右がその適用結果

●パス1、2：シャドウマップの生成

　影生成のタネとなるシャドウマップを、前述したLSPSMアルゴリズムに従い、シーンを光源を視点にしてレンダリングして生成する。

　レンダーターゲットとするバッファはXbox 360-GPUがサポートする浮動小数点のデプスバッファ(Zバッファ)で、24ビット精度(FP24、D3DFMT_D24FS8)を持つ。浮動小数点次元で深度情報をレンダリングできるので、これまでの整数デプスバッファのようにバイアスなどを気にせず、高精度に深度情報の比較が行なえる。

●パス3:Zバッファのプリパス

　シーンのレンダリングに取りかかる前に、先に視点からのデプスバッファ(Zバッファ)レンダリングのみを行なう。

　通常の3Dグラフィックスのレンダリングでは、ピクセルの描画をしつつデプスバッファを更新し、次回の同じ場所のピクセル描画があったときに反復描画が起きないようにしていく。ところが、描画するオブジェクトの前後関係がしっかりソートされていないと、意外にも同一XY座標のピクセルが反復描画されてしまうことが多いのだ。

　Xbox 360を含むプログラマブルシェーダ世代のグラフィックスでは、1ピクセルに対して複数の長いシェーダが走ることになり、1ピクセルに掛かるシェーダコストはとてつもなく大きい。1ピクセルの反復描画を極力避けたいという思いがあるのだ。

　そこで、このデモでは先にそのシーンの正しい深度情報をデプスバッファを完成させてしまい、1ピクセルには適切なシェーダが1回だけ走るようなお膳立てをしてやっているのだ。こうした先にデプスバッファをレンダリングして後から通常のレンダリングを行なう手法を特に「Deferred Rendering」(意訳:遅延されたレンダリング)と呼ぶ。

　なお、以降のパスでも、ここで生成したデプスバッファの内容は再利用するので、全てのレンダリングパスが終了するまで、eDRAMには残り続けることになる。Xbox 360-GPUでは、レンダーターゲットへの色+デプスの書き出しは1サイクル8ピクセルだが、色更新無し+デプス値のみの書き出しについては倍速の1サイクル当たり16ピクセルのパフォーマンスがある。つまり、非常にDeferred Renderingに適したGPU設計であるということができるのだ。

シーンの深度情報だけを先にレンダリング。このショットはこのZバッファの内容を可視化したもの。色が白い方が手前にあり、色が黒いほど奥にある…というようなイメージだ。以降のレンダリングパスでは、このZバッファの内容を参照しながらレンダリングしていき、奥行き関係で見えないピクセルは早期に破棄して反復描画を極力避けている

●パス4:シャドウカラーのレンダリング

　パス1～2で生成したシャドウマップを元に、実際の影を描画していくパス。

　一般的にはこうした影描画のプロセスは、通常カラーのレンダリングパスと同時に行なうのが普通で、実際、当初はパス5のカラーのレンダリングに含まれていた処理だったという。ところが、パフォーマンスが思ったように上がらず、悩んだ末にその影レンダリングパスを分離したところ、パフォーマンスが劇的に向上することとなった。

　矢野氏は「このデモの特徴的なパスである」と解説したが、もしかするとXbox 360のグラフィックスエンジンのパフォーマンス最適化の行程における重要なノウハウ、なのかもしれない。

　矢野氏の推測では、テクスチャ・キャッシュの効率を影レンダリングパスが阻害していた可能性を指摘していたが、筆者もその可能性はきわめて高いと思っている。このデモの影レンダリングでは、影の輪郭付近で半影処理を適用しているが、これが5x5のガウスフィルタ(Gaussian Filter:映像をぼかす際に一般的に使われる)によって実行される。1ピクセルあたりシャドウマップ(テクスチャ)の参照を25点も行なうので、カラーのレンダリングの際に使用するテクスチャキャッシュの局所性を破壊していた可能性があるのだ。

　Xbox 360-GPUはトランジスタ数がシェーダ規模の割には少なく、このダイエットはキャッシュ容量の削減で賄われたという推測がある(その代わりレジスタ領域はマルチスレッド対応化のためにトランジスタ数が多く割かれている)。比較的潤沢なキャッシュを載せたNVIDIA系とは違う、Xbox 360-GPU独特な最適化が必要になる局面は意外に多いのかも知れない。

パス1-2のシャドウマップ上の光の遮蔽構造と、パス3のシーンの深度情報とを吟味して影となるべきところを影色としてレンダリングする。影の輪郭付近には選択的にフィルタ処理を行なってぼやかして半影化

●パス5:カラー、ライティング

　実際のメインレンダリングとも言えるパスで、様々なマテリアル表現に従ったライティング/シェーダ処理を行ない、テクスチャの指定があればこれを適用し、色を付けていく。また、このパスで、パス4でレンダリングされたシーンの影が描かれたフレームと合成される。

　このパスで実装しているライティング効果は拡散反射(Diffuse)、法線マッピング、環境マッピング、光沢(Gloss)マッピングなど。なお、シーンに存在する全ての光源に対応する光源処理はこのパスで一元実行される。

ライティング/シェーダ処理、テクスチャ適用といった基本的なカラーレンダリングパス。同時にパス4の影フレームを合成。この時点では被写界深度のシミュレーションやトーンマッピング処理は行なわれていない

このデモでは空はHDR扱いなので、空を見上げると平均輝度が空基準となり、その他の部分がかなり暗く見えるようになる。現実世界に即した3D表現だ

●パス6～11:シーンの輝度の算出

　HDRレンダリングしたHDRフレームを舐めていき、その平均輝度を算出するパス。パス数は多いがピクセルシェーダのみによるフレームバッファ処理だけなのでGPU負荷はそれほどでもないという。

●パス12～19:ブルームとグレア

　HDRレンダリングにおける定番のエフェクトであるブルーム(Bloom)効果やグレア(Glare)効果を付加するパス。

　ちなみに、ブルーム効果とは高輝度部分がジオメトリの前後関係を無視してまで、じわっと柔らかくあふれ出してくる効果で、グレアとは高輝度部分が放射状に煌めくようにあふれ出してくる効果。

　パス6～11で求めた平均輝度と比較して高輝度な部分を低解像度なバッファにブラーをかけたり、放射状に引き延ばしたりして、これを最終レンダリング結果にブレンドしている。

低解像度バッファにシーンの高輝度部分をブラーさせて描画。これがシーンに満溢れる、ほのかな光となり、フォトリアリティ感が増す

●パス20:トーンマッピング

　パス6～11で求めた平均輝度値を元に適正な輝度バランスにてHDRフレームを1,677万色範囲のLDRフレームに変換するパス。こうした処理系をトーンマッピング(Tone Mapping)という。

　暗いところから明るいところへ、あるいはその逆の状況などで目が徐々に慣れてくるような瞳孔シミュレーション効果(動的な露出補正効果)の処理もここで行なわれており、前の状態から算出された適正な輝度へゆっくりと推移するような振る舞いをする。

ここまで来るとほとんど最終結果と変わらないレベル

このシーンではタワーの低い階にはピントが合っているが、タワーの上部や木などはブレて見えている。これによりタワーの高さが静止画でも伝わってくる

●パス21:被写界深度

　主人公キャラクタの周辺はくっきりと見えるが、画面の奥に行くに従ってピンボケのように見える効果、被写界深度(DOF:Depth of Field)のシミュレーションを行なうパス。

　これまでにDOF効果実現には様々な実装手法が考え出されているが、このデモで使われているこの手法は、最近の3Dゲームではよく用いられるシーンの深度情報を用いるタイプだ。

　具体的には、パス20によってトーンマッピングパスを経た最終レンダリング映像に対し、視点からある距離以上の奥にある映像を、奥に行けば行くほどブラー量を大きくしてぼやけさせているという流れになる。なお、最終的に、このパスを経た映像が画面に表示される。

被写界深度のシミュレーションは、このような遠近感の演出の他に高低感の演出にも効果的に効いてくる。

■　最後に～Xbox 360のゲームはマルチスレッド設計が基本となるか?

　この他、このデモで、Xbox 360らしい設計といえば、マルチスレッド前提のソフトウェア設計がなされているという点だ。このデモでは実験段階バージョンでハードウェアスレッドを5つ、今回の公開バージョンでは4つを走らせているという。

　Xbox 360のCPUでは、3基のPowerPC970互換コアが搭載されており、それぞれが2個ずつのハードウェアマルチスレッドに対応しているので、まだ1個余っている計算になる。内訳としては下記の通りになっているという。

・スレッド0:メイン・ゲームループ
・スレッド1:レンダリング・エンジン(公開版はスレッド0に統合)
・スレッド2:物理シミュレーション
・スレッド3:ヘア・シミュレーション
・スレッド4:オーディオ関連
・スレッド5:未使用

　プレゼンを行なった矢野氏によれば、特に物理シミュレーションライブラリの「NovodeX」のデモ・エンジンへの組み込みが容易だったと感想を述べており、1週間ほどで全貌が把握でき、1カ月もしないうちに試験動作できる段階に持ち込めたという。もともとマルチスレッド・設計であるNovodeXはXbox 360-CPUとの相性もいいようだ。

　それほど、ノウハウが蓄積されていない中での試行錯誤の中での開発だったようだが、それでも、マルチスレッド化によるパフォーマンスは上々だったという。このデモのこうした設計情報は他のXbox 360のゲーム開発にとってもベンチマーク的存在になることだろう。

　なお、このデモを動作させた「nFactor2」エンジンは、これからも完成度を高めていき、将来的にはイニス自身、あるいは関連ゲームスタジオによる実際のゲーム開発プロジェクトで活用されることがほのめかされた。今から、どんなゲームが出てくるのか楽しみだ。

copyright 2004, iNiS corporation. all rights reserved.

□イニスのホームページ
http://www.inis.co.jp/
□「nFactor2」のホームページ
http://www.inis.co.jp/technology/nfactor_j.htm

(2005年9月29日)

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