そんな2006年末商戦において、“日本発”のタイトルながら次世代3Dゲームグラフィックスの可能性を感じさせてくれるタイトルが1つだけあった。それはXbox 360の「ロスト プラネット」だ。

　今回は、この「ロスト プラネット」をメインに据えつつ、そのカプコンが完成させたというPS3、Xbox 360、PCの3プラットフォーム向けの次世代ゲームエンジンについて見ていきたいと思う。

■ カプコン自社開発のツールベース・ゲームエンジン「MTフレームワーク」

　これまでは各ゲームプロジェクト毎に、新しいゲームエンジンをゼロから起こしても予算的にも時間的にもなんとかなった。しかし、マルチプラットフォームでゲームをリリースすることを前提としているサードパーティにとって、今世代のPS3、Xbox 360ではハードウェア側の規模が大きくなり、しかもそのハードウェア毎の特徴が強くなってきたために、ゲームごとにフルスクラッチビルドをしていたのでは、エンジン設計に時間が掛かり、しかも動作検証にも時間が掛かりすぎてしまう。

　そこで、各ゲームスタジオでは、その次世代機の高機能ぶり、強い個性を吸収して使いやすく実装したミドルウェアやフレームワークを利用してのゲーム開発に関心を注ぐようになってきている。

　「ミドルウェア」(Middleware)と「フレームワーク」(Framework)とは共にハードウェアの違いやそのハードウェアの機能を使いやすいように具体化して提供するハードウェア(あるいはOS)とアプリケーション(ゲーム)の中間を取り持つソフトウェアだ。両者はよく似たものだが、ソフトウェアの雛形のような形態のものをフレームワーク、ハードウェアを抽象化して扱いやすくしたものをミドルウェアとして呼び分けることも多い。フレームワーク、ミドルウェアを一緒くたにして漠然と「ゲームエンジン」というキーワードで呼ぶことも多い。

　PCでは、この考え方が比較的前から浸透してきており、本連載で取り挙げた事もある「DOOM3」エンジン、「HalfLife2」エンジンなどはその最たる例だろう。

　そんな状況の中、比較的大手のゲームスタジオでは、PS3、Xbox 360の双方に対応させたミドルウェアあるいはフレームワーク……すなわちゲームエンジンを自社開発して行こうという流れが起こりつつある。その1つのサンプルとして紹介したいのが、今回の「ロスト プラネット」のゲームエンジンであり、秋に発売されたばかりの「デッドライジング」のゲームエンジンでもある「カプコンMTフレームワーク」(以下MTフレームワーク)だ。

「MTフレームワーク」はPS3、Xbox 360、PCに対応したユニバーサルなゲーム開発フレームワーク

　このエンジンの名前の“MT”には「マルチスレッド(Multi-Thread)」、「メタツール(Meta Tools)」、「マルチターゲット(Multi-Target)」というような意味合いが込められている。MTフレームワークの開発は2004年9月頃からスタートしたとのことで、2005年1月から、このエンジン上の第一タイトルとなった「デッドライジング」の開発が進められていた。カプコンがこうした自社ゲームエンジン、ゲーム開発フレームワークをフルスクラッチから開発しようと思った動機はどこにあるのだろうか。

石田智史氏「鬼武者3の時からエンジンを共有化して開発効率を上げていこうという動きがありまして、これを次世代機でも……というのが基本的な流れです。当初は、ここまで汎用性の高いものにしていく予定はなく、『デッドライジング』と『ロスト プラネット』の2タイトルで共有化するというのが当面の目標でした。この時、某著名なミドルウェアも評価検討したのですが、自分達の求めていたものと少し違っていたのと、要求していたパフォーマンスを引き出すのは難しいと判断し、自分達の使いやすいフレームワークを作っていこう……ということになりました」

　なお、余談になるが、石田氏は、「鬼武者3」のゲームエンジンの設計にも深く携わっていた人物で、本連載の「鬼武者3」編でも協力頂いたことがある。ぜひとも「鬼武者3」編も参照してもらいたい。

　PS3、Xbox 360の今世代ゲーム機のミドルウェアとして最も注目されているのは米EPIC GAMESの「UnrealEngine3.0」(UE3)だ。もともとはPC向けだったが、PS3、Xbox 360にも対応させ、ソニー・コンピュータエンタテインメント、マイクロソフトのそれぞれにおいて開発プラットフォームの準標準的な立場を勝ち取っている。世界中のゲーム開発現場から注目されているが、どちらかといえば欧米での採用例が目立つ。「UE3」の日本サポートチームは北米にあり、言語や時差の壁が小さくなく、リアルタイムサポートはなかなか難しい状況にあるためか、日本では今のところ主流にはなりきれていない。ただ、日本でもXbox 360用「LOST ODDYSSEY」(マイクロソフト)などが「UE3」ベースで開発が進められており、今後の展開は期待されている。

　MTフレームワークはマルチプラットフォーム展開が推し進められており、Xbox 360とその親和性が高いPC版に加え、PS3版への実装も進んでいるという。なお、PCへの対応というのは、ゲームタイトルのPC版のリリースを主眼においたと言うよりは、Xbox 360とPCの親和性から、その開発効率向上のために“開発された”ということのようだ。おそらくはプロトタイピングなどの用途に使われるのだろう。もちろん、カプコンは家庭用ゲーム機タイトルをやや遅れてPC版でリリースすることはこれまでに何度も行なってきているので、その際にこのMTフレームワークPC版が活躍するという機会はきっとあるはずだ。

伊集院勝氏：「2005年10月頃には、『ロスト プラネット』や『デッドライジング』は、基本的な部分はそれなりの形で動くようになっていて、社内からPS3のも欲しいという声が大きくなってきたんです。我々のMTフレームワークは基本設計はPS3でも十分行けるだろうということで、PS3へ載せる方針が決まり、この頃からPS3への実装作業も開始しています」

　MTフレームワーク(PC、Xbox360)は開発当初は3人で開発がスタートし、途中で5人体制になり、PS3版向けへのスタッフが4名追加されたという。

PC上の画面	同じシーンのXbox 360上の画面(PC上と同じツールが動作)

　このMTフレームワークの凄いところはカプコン内製のパフォーマンスモニタでリアルタイムに負荷変化を見ることができ、ボトルネックを探しやすい構造になっているという点。後述するマルチスレッド処理におけるスレッド処理履歴なども参照可能で、複雑で難しいというイメージのあるマルチスレッドベースのゲームエンジンを視覚的に動作検証ができる点も優れている。グラフィックスについても、各種セッティングをリアルタイムに変更できたり、描画技法を低負荷のものに切り換えたり……といったパフォーマンスチューニング的なこともリアルタイムでできてしまう。ゲームをフルスクラッチで作り込んでしまうと、その後のパフォーマンスチューニングは結構面倒くさいものだが、こうしたツール群が充実しているMTフレームワークでは、ゲームの動作に関わる根幹部分の途中の仕様変更がスケーラブルに行なえるという点が強力だ。

　このMTフレームワークは、Xbox 360、PC、PS3の3プラットフォームに対応し、しかも大ヒットタイトルとなった「デッドライジング」や「ロスト プラネット」のエンジンと言うことであれば、「ゲームエンジンビジネス」としてもかなり訴求できそうだ。マルチプラットフォーム対応の和製フレームワークとしてカプコンがエンジンビジネスを展開する予定はないのだろうか。

伊集院氏：「エンジンを外部に供給するには、残念ながらまだそれを実現できるのに十分な社内体制が整っていません。また、より優れたゲームタイトルを開発しようとすると、ただエンジンの上に載せて動かすだけではダメで、そのタイトルごとの細かな拡張とかが必要になってくるんです。今も進行中のプロジェクトに対して、そうした対応をしつつ進化していますし、こうした状況を考えると現実的に外に出すというのは難しいと思っています」

PC上の開発環境で動作している「ロスト プラネット」

　確かにタイトルごとの特殊な拡張というのは社内向けのエンジンだからこそ小回りの利く対応ができるのであって、これが商用エンジンということになれば、そうはいかない。社外向けはバージョンアップの機会ごとのアップデートにして、社内向けはリアルタイムに進化させていくということもできなくはないが、バージョン管理が難しくなるのは想像に難くない。

　現時点では、カプコンのこのMTフレームワークはカプコン社内のエンジンとして利用されることになりそうだ。

■ 実はゲームはマルチスレッド向きだった!

　PS3、Xbox 360のCPUはマルチコア化がなされ、これがいわゆる新世代ゲーム機の特徴になっている。PS3はCELLプロセッサというPowerPC 970互換(PPE)×1基＋128ビットRISC型ベクトルプロセッサ(SPE)×7基の非対称型、Xbox 360はPowerPC 970互換×3基という対称型という構造的な根本的な違いはあれど、マルチコアはゲーム機においても1つのメインストリームとなった。これは必然的に今世代のゲーム開発では、ハードウェア側がゲームプログラム側のマルチスレッド化を求めてきている……といってもいい。

　マルチスレッドとは複数の処理を同時並列実行して処理効率を上げ、ひいてはパフォーマンスを向上させようと言うソフトウェアパラダイムだ。ところが、ゲームプログラムは大局的に見れば逐次処理構造の典型であり、元来、これはマルチスレッド化に向かないとされてきた。

PC、Xbox 360、PS3の今世代のゲーム開発において「マルチスレッド対応」はもはや避けて通れない道

　ところが、石田氏は「タスクという観点から見ると、依存関係は最小化でき、むしろゲームプログラムは並列化しやすいともいえるんです」と、これまでのゲーム開発の常識とは正反対の意見を主張する。

　MTフレームワークでは「処理内容」を「モジュール」、「ループ」、「タスク」という3つのタイプに分けて考え、マルチスレッド実行可能なものはマルチスレッド設計で実装している。具体的には「モジュール」は専用スレッドで実行し、「ループ」と「タスク」は、常に動いている5つの汎用のジョブスレッドに、ジョブ(関数ポインタ)として渡すことで並列処理させている。

処理の固まりの大きさで言うと、モジュール ＞ タスク ＞ ループの順に大きい

　並列化できる「モジュール」は、それ自体がゲームメインプログラムにおいて比較的独立性が高く、ハードウェア機能をドライブするものに多い。MTフレームワークでは、レンダリングエンジン部、サウンドエンジン部、データのロード部が並列実行できるモジュールとして設計されている。

　並列化して効果の高い「ループ」は、比較的、量の多いデータに対して処理を適用するもので、MTフレームワークでは、データのソート処理などを並列化実装しているという。

　「タスク」はプレーヤー、敵、カメラ(視点)、ライティングなどの同時多発的に発生するゲームを進行させる処理そのもののことを指す。各タスクには、プレーヤータスクの更新処理、描画処理。敵タスクの更新処理、描画処理といった形で「更新処理」、「描画処理」が存在する。そして、プレーヤータスクの更新処理、敵タスクの更新処理などが並列に実行されるようになっている。

　更新処理は、相互に依存関係があって、並列に向かない処理の組み合わせもある。そこで更新処理は、並列処理が可能な更新処理の実行(並列更新)と、その実行結果をもとに、依存関係を吟味しての逐次処理(同期更新)と分けて実行している。

　こうすることで、避けられない同期オーバーヘッドについては集中して実行して、並列更新の最中の並列タスク間の依存関係を低減させている。これによって並列実行性が最大限に引き出されることを狙うわけだ。なお、同期更新(逐次処理)時は、値の取得や値の受け渡しだけを行ない、時間の掛かる計算やデータ処理は次回の並列更新時に並列処理として実行する。まとめると、同期更新は並列処理後の結果の受け渡し作業、そして次の並列更新のための準備をするフェーズ……というようなイメージだ。

並列更新と同期更新	従来のゲームプログラムと並列化されたゲームプログラムの流れの比較

　MTフレームワークにおける並列処理は、実行すべきタスクを「ライン」と呼ぶ処理パイプラインに流し込むスタイルをとる。同一ライン上に複数のタスクを投げ込むとそれらは同時にマルチスレッド実行されるというイメージだ。各タスクの実行終了時間はまちまちなはずなのでパイプラインバブルが発生する可能性はある。同一ライン上に投げ込めるのは相互に依存関係がないタスク。依存関係がある場合はその依存関係の時系列に準じたラインに投げ込むことになる。

並列処理される同一ライン上のタスク間のデータ参照は不可だが、過去の終了したタスクに対するデータ参照は可能としており、過去から未来へ継承するような依存関係は並列更新中にも処理できるわけだ

　同じ「ライン」に登録されたタスクは、更新処理時、ジョブとしてキューに積まれ、5つのジョブスレッドで並列に実行される。一方、描画処理時は、ラインに関係なく全てのタスクの描画処理をジョブとして一度にキューに積み、5つのジョブスレッドで並列に実行される。つまり、同一ライン上のタスクの更新処理は、複数のスレッド(5つのジョブスレッド)で並列に処理していくというイメージになる。なお、Xbox 360版のMTフレームワークでは、スレッド数はメインスレッドを含むジョブ処理用の5つで固定となっている。

　結局、マルチコアCPUにおいて、最大パフォーマンスを得るためには、いかに多く並列処理をさせられるかがキーになってくるので、並列処理後のつじつま合わせに相当する同期更新は最短で実行されることが重要になる。そこで、同期更新処理の際にはXbox 360 CPUの巨大なL2キャッシュ(1MB)と、メモリ帯域をこの同期更新の1スレッドに占有させて実行させているという。

Xbox 360(対称型マルチコアCPU)におけるスレッド実行の仕組み	MTフレームワークのツール上で見た各ライン上におけるスレッド処理の流れ

　MTフレームワークでは描画タスクも並列実装されている。描画タスクは、主にグラフィックス描画を司るGPUを制御するための描画コマンド列を生成する処理を行なう。これは、大きな単位で例えると、敵キャラをどこに描く、煙はどこに描く……といったGPUへの描画手順指示を作成する処理系。

　描画タスクも、ライン管理の並列処理の仕組みをとるあたりは更新タスクと同じだが、最終的に描画を行なうGPUは1つであり、しかも3Dグラフィックスは描画時における順序が重要になってくるのでこのあたりのつじつま合わせには独特の工夫が必要になってくる。

MTフレームワークでは描画コマンドの作成も並列処理で行なっている

　半透明処理においては描画順序が重要になってくるし、反射マップやシャドウマップなどの動的生成したテクスチャを使用してシーンを描画する際には、その素材が既に描画完了していなくてはならない。そこで、描画タスクの並列処理では、最初、描画順序等に関連した情報(プライオリティタグ)を付加した中間的な描画コマンドを生成し、これをポスト処理でつじつまの合う順序ソートし直してネイティブな描画コマンドに“精製”するという手順を実装している。

　中間描画コマンドの生成はマルチスレッドで並列処理で行ない、これは各スレッドごとに用意されたそのスレッド専用のバッファに生成する。複数バッファに生成された順不同な中間描画コマンドは、次のフェーズで描画順序に配慮して1本のバッファにまとめ直すわけだが、そのマージソート処理も並列処理で実行される。

並列処理では中間描画コマンドを作成し、これをあとでソートしてネイティブコマンドに“精製”	並列処理で作成された複数バッファにまたがる中間描画コマンドを1つのコマンドバッファにまとめるためにマージソートする

　こうしてみてくると、MTフレームワークでは、ゲームプログラムの大きなパイプライン構造はそのままに、そのパイプラインを構成する処理を極力マルチスレッド実装しているということがわかる。

　さて、Xbox 360 CPUは3.2GHzのPowerPC 970互換コアの3基構成だが、このCPUのパフォーマンスはあまり高くないという声もあるようなのだが、実際のところどうだったのだろうか。

石田氏：「我々の経験からすると1コアのパフォーマンスは大体同クロックのPentium 4の2/3くらいですかね。各コアのSMT(後述)をフルに活用して6スレッド分をフルに稼働させることができると、大体その4倍くらいのパフォーマンスが出ますよ。PCでいうとデュアルコアPentium 4 Extreme Edition 840(3.2GHz)のSMT有効時の4スレッドくらいのパフォーマンスは出せますね。ゲームエンジンを並列化実装しないとかなりきついですが、並列化実装したときのパフォーマンスは今のハイエンドPCと比較しても遜色ないと思います」

　SMTとは「Simultaneous Multithreading」の略で、1コアのCPUを2つの論理CPUとして振る舞わせて、内部演算器の実行効率を上げようという技術。Intel系CPUに搭載されている「HyperThreading」はSMT技術そのものだ。Xbox 360 CPUの各PowerPC 970互換コアはSMTが搭載されており、2スレッドまでのハードウェアマルチスレッディングに対応している。遅いと言われるXbox 360 CPUも、石田氏が言わせればマルチスレッドを活用すれば非常に高いパフォーマンスを発揮できる……ということなのだ。

　さて、Xbox 360のアーキテクチャで弱点としてよく指摘されるのはメモリコントローラだ。ただでさえレイテンシの大きいGDDR3 SDRAMをメインメモリとし、しかもそのメモリコントローラがGPU側にあるため、CPUからのメモリアクセスのレイテンシはかなり大きい。この点はパフォーマンスに響かないのだろうか。

石田氏：「確かにレイテンシは小さくはないんですけど、そのためのSMTなんです。つまりメモリアクセスをSMTによるハードウェアマルチスレッディングで隠蔽するようなイメージですね」

　極力L2キャッシュに命令コードが載るように心がけ、実メモリアクセスが発生した場合でも、パイプラインがストールしたら、SMTで別スレッドを実行してメモリアクセスの遅延を覆い隠すというわけだ。これは、GPUのメモリアクセス隠蔽のマルチスレッドの仕組みとよく似ている。

石田氏：「これが非常に効果が大きくて、例えばPentium 4のHTオン時のマルチスレッド・パフォーマンスってよくてHTオフ時の大体1.2～1.3倍くらいじゃないですか。Xbox 360 CPUだとSMT活用したマルチスレッド時のパフォーマンスってコアあたり1.5倍くらいは出るんですよ」

各タイトルにおけるMTフレームワークのマルチスレッドパフォーマンス。Xbox 360版のCPUは3コア×2SMTなのでハードウェア的に6スレッドを走らせられる。MTフレームワークではメインスレッド(ジョブ兼用)と4つのジョブ専用スレッドがそれぞれ5つのハードウェアスレッドに割り当てられている。また、レンダリングとサウンドは1つのハードウェアスレッドに2つのソフトウェアスレッドとして割り当てられているという

　スレッドの処理時間はスレッドによってまちまちなので、同期更新が開始できるのは全ての並列処理が終わってからしか行なえない。ということは、早く終わったスレッドが全ての並列処理が終わるまで待たされてしまう、いわゆるパイプラインバブルのような現象か゛発生してしまうと推察されるが、これに対しては何か工夫があるのだろうか?

石田氏：「ジョブの実行が早く終わったスレッドから、次々にキューからジョブを取り出して実行していくため、ジョブの数が十分に多い場合は平均化されパイプラインバブルは最小化されます。もちろん、ジョブの数が少ない場合や、極端に処理時間のかかるジョブがキューの最後に積まれていた場合などは大きなバブルが発生してしまいます。従って、ジョブの数が少ない場合は、SMTではなく異なるコアで処理されるように、また処理時間のかかるジョブはキューの最初に積むようにすることで、ストールの時間を減らしています」

　現在MTフレームワークはPS3版の開発もかなり進行しており、現在開発中の「デビルメイクライ4」、「バイオハザード5」などは、このフレームワークを採用しているという。PS3のCPUは非対称型のマルチコアであり、並列処理の実装形態はXbox 360と大部違うようだ。PS3のCPUは、メインプロセッサ的なPPEは1基で、これに7基のSIMD型ベクタプロセッサのSPEが連係動作する形態になっている(うち1基はシステムで使用。ゲーム側で使えるのは6基まで)。PPEも3.2GHzで動作のPowerPC 970互換CPUでSMTで2スレッドのハードウェア・マルチスレッディングに対応しており、いわばこれはXbox 360の1コア分に相当するが、もちろんXbox 360での対称型用のエンジンはそのまま持ってこられない。そこでPS3版のMTフレームワークは、Xbox 360版とはかなり変わった実装になっている。

PS3(非対称型マルチコア)におけるマルチスレッド実行の仕組み

　PS3版のMTフレームワークでは各スレッドはソフトウェアスレッドとして実装され、スレッドの実処理をSPEに外注する形態をとる。外注先のSPEからの結果が戻ってくるまでただぼーっと待っていては無駄なので、外注後、別のスレッド実行に切り換えてSPEの実作業時間を隠蔽するような仕組みになっている。

　こうした一連の徹底した処理の並列化実装の効果は大きかったようで、「デッドライジング」では1スレッド実装時に比べてパフォーマンスは2.6倍に、同様に「ロスト プラネット」では2.15倍に向上したという。

　難しいとされてきたゲームプログラムのマルチスレッド化を、ここまで積極的に推し進めてこられた技術力には感服する。

　1つ興味深いのは、このMTフレームワークが、Xbox 360、PS3のどちらか一方に優位なように設計されず、最大公約数的な性能が発揮されるように設計されている点だ。

　現在のMTフレームワークのSPEの活用形態ではSPE側のわずか256KBのローカルメモリ(ローカルストア)では、プログラムやデータの出し入れが頻繁に起こりやすく、そのオーバーヘッドの帯域消費がバカにならないような気がする。しかし、かといってSPEの最大性能が活かされるような形でのエンジン設計をしてしまうと、今度はXbox 360での動作が厳しくなる。

　どちらか一方のハードウェアに傾倒するよりも、両プラットフォームで最大性能が得られるようなエンジン設計になったのは、マルチプラットフォーム展開前提のカプコンという立場を考えればごく自然な戦略だといえる。

負荷の軽いシーン。左端の青緑赤からなる縦ゲージがトータルな負荷を表している	負荷の重いシーン。左端の青緑赤負荷ゲージが下方向に長くなっている点に注目

■ 「ロスト プラネット」はカプコン「MTフレームワーク」ベース第2弾タイトル!

　「デッドライジング」からさらに進化したMTフレームワークの最新型で動作しているのが「ロスト プラネット」ということになる。最新世代の3Dゲームは一体どのくらいのポリゴン予算で動作しているのだろうか。

澤田泰英氏：「キャラクタは1万～2万ポリゴンくらい。VSというロボット兵器が3万から4万くらい。背景が50万ポリゴンくらい。その他、影生成をはじめとした目に見えないレンダリングコストを含めると1シーンあたり毎フレーム300万ポリゴンくらいですね」

　PS2世代のゲームでは数十万ポリゴンが平均で、3DMarkなどのPCのベンチマークソフトの高ジオメトリテストでも100万から200万ポリゴン。家庭用ゲーム機向けタイトルで数百万ポリゴンをリアルタイムに動かすことが当たり前になってきたということはなかなか感慨深い。

澤田氏：「一方、『デッドライジング』は400万ポリゴンくらいです。『ロスト プラネット』は特殊効果へ負荷予算を割いているのに対して、『デッドライジング』では特殊効果はそれなりにして大量のゾンビを出すことに注力したのでポリゴン数だけで言えば圧倒的に多いんです」

ついに毎フレーム数百万ポリゴンをリアルタイム・レンダリングする時代がやってきた!

　気になるレンダリング解像度は1,280×720ドット、表示解像度も1,280×720ドットを実現し、リアル720p出力を公言している。

　アンチエイリアスは4サンプル・マルチサンプル・アンチエイリアス(4x MSAA:Multi-Sample Anti-Aliasing)を使用。基本これで毎秒30コマ(30fps)になるよう調整されているが、動的なキャラクタが大量出現したり爆風などのエフェクトが大量発生したときなどは30fps以下になることもある。これが検出されると動的には4x MSAAを2x MSAAに下げ、さらに負荷が高いようであればMSAAをオフにするような仕組みも入れてあるという。

石田氏：「あくまで目安ですが、Xbox 360だと、2x MSAAで+10%負荷、4x MSAAで+20%の負荷という感じなので、これを目安に動的に調整していますね」

　なるほど、発想としてはシンプルだが、描画品質とフレームレートのベストバランスを動的に調整する機能として、これは非常にユニークかつ有効なソリューションだと思う。

MSAA OFF(43.80fps)	2x MSAA(38.76fps)	4x MSAA(35.91fps)
MSAA OFF(31.74fps)	2x MSAA(29.46fps)	4x MSAA(27.40fps)

　一度にメモリに存在するテクスチャ量は約160MB。うち背景が60MB～80MB程度だという。

石田氏：「1ステージあたりの延べはもちろんもっと多くなります。『ロスト プラネット』ではシームレスローディングを採用しているためです。『ロスト プラネット』ではお気づきの人も多いと思いますが、ステージ中、画面を止めてのローディンクはなく、随時リアルタイムにデータを読み込んでいきます」

キャラクタも数万ポリゴン時代に

岩や瓦礫などの破壊アニメーションはリアルタイムHAVOK物理ベース

　「デッドライジング」、「ロスト プラネット」共に物理シミュレーションについては、基本的にはHAVOKを使用しているという。具体的には死体の挙動などを司るラグドール物理(Ragdoll Physics)、岩や破片など挙動を司る剛体物理などがHAVOKベースとなっている。

伊集院氏：「物理シミュレーションについては我々MTフレームワークのチームではなく、『デッドライジング』、『ロスト プラネット』といったアプリケーション側のチームが使いやすいものをそれぞれ選択したような形態です」

石田氏：「ですから現在はHAVOK物理がシングルスレッドで実装されています。オリジナルのマルチスレッド化された本格的な物理シミュレーション・エンジンの実装などは今後の課題ですね」

　人体と身につけているアクセサリとの衝突や、衣装のクロスシミュレーションなど、3Dキャラクタ・ローカルな物理シミュレーションはMTフレームワークのオリジナルを実装して使っているとのこと。また、銃撃をはじめ、キャラクタ同士の衝突判定もHAVOKではなくオリジナル実装で、衝突単位は平面、あるいはカプセル形状(球体を引き延ばしたような閉じた立体形状)単位となっている。

　また、「ロスト プラネット」では複雑な地形を持ったステージが目立つが、巨大ボスやキャラクタが地形に潜ったりするようなこともなく、自然なアクションを決めている。これについてはオリジナルのIK(Inverse Kinematics:逆方向運動学)エンジンを開発して実現している。具体的には、デザイナが付けたアニメーションやキャプチャしたモーションなどを、IKエンジンで算出したモーションを合成し、不自然なところを補正するというような実装になっている。

IKなし。足が地面に潜り込んでしまっている	IKあり。雪の斜面に追従した形で足の位置や姿勢を制御

　もちろん、オリジナル実装した物理シミュレーション、IKエンジンについてはマルチスレッドに対応しており、登場しているキャラクタごとに独自スレッドが立ち上がって並列に実行される。

伊集院氏：「このマルチスレッド実装した衝突判定があってこそ実現できたのが『デッドライジング』のゾンビですね。あの何十、何百というゾンビ達って相互にちゃんと衝突をとっているので、お互い重なることがないんですよ」

石田氏：「アニメーションは最大で8つまでが合成されます。細かいことで、気が付かないかも知れませんが(笑)……このIKとアニメーションの合成の効果で足とかもちゃんと地面の傾斜に沿って曲がって接地しますよ」

　未だにキャラクタ同士が不当に重なったり、背景にめり込んでしまうゲームが多い中、これは確かにさりげなく次世代感をアピールする要素になっていると思う。

キャラクタの髪やアクセサリ、衣装などのローカル物理はMTフレームワーク自家製のものを使用	ゲーム進行を司る衝突判定もやはりMTフレームワーク自家製。衝突単位は直方体やカプセルベース

■ 60fpsに限りなく近い30fps表現を実現する2.5Dモーションブラー

　3Dグラフィックスはカメラ的に言えばそのシャッター速度は1/∞秒なので、理論上ぶれることはない。そこで写真ぽいリアリティを付加することを狙い、速い動きに対してあえて人工的なブレを適用してみては? ……というアイディアが生まれることになる。これが速い動きをカメラで捉えたときに出てしまうブレの効果、「モーションブラー」だ。大胆なたとえで言えば、漫画やアニメなどにも見られる効果線や軌跡線のこと。そしてMTフレームワークの「2.5Dモーションブラー」は一口に言ってしまえば「モーションブラー」のユニークな一形態だ。

　最近の3Dゲームグラフィックスでもこのモーションブラーは広く実装されてきているが、その多くが過去フレームの内容を参照/引用して実行するポスト処理による画像処理的なアプローチだった。この方法も悪くはないのだが、いわば2D(二次元)ベースのボカシ処理になるので、シーン内で同時多発的に起こる3次元的な速い動きをブラーで見せることは難しかった。

2.5Dモーションブラー

　MTフレームワークでは、新世代機PS3、Xbox 360の高いポテンシャルを活かし、3次元的なモーションブラー専用の仕組み「2.5Dモーションブラー」をグラフィックスエンジンに実装した。

　基本的な考えはGDC2003にてNVIDIAのSimon Green氏が発表した「NVIDIA OpenGL Shader Tricks」がベースになっている。

　第一にシーンをテクスチャにレンダリングして、これを後に参照する素材とする。次のパスで頂点シェーダにて現在の位置と前の状態の位置を計算して、画面上の全ピクセルが前と現在フレームではどういう方向にどういう速度(ベロシティ)で移動してきたかの情報をテクスチャにレンダリング(ベロシティマップ)。そして、ベロシティマップを元に、テクスチャとしてレンダリングしたシーンテクスチャを参照(サンプル)して最終フレームを生成する。

2.5Dモーションブラーの概念図

　前回位置と現在位置と比較して大きく離れている前回位置のところは時間が経過している……すなわち速度が速かったという意味になり、シーンテクスチャからサンプルした色を薄くするようにブレンドするわけだ。こうすることで時間経過が大きいところが薄く見えて、現在に近ければ近いほど濃くなるような残像を作り出せる。

　この方法でまずポイントとなるのはベロシティマップの作成。基本となる考え方は、各頂点における頂点の向き(法線ベクトル)が動きベクトルと一致していれば(近ければ近いほど)現在の状態(位置や回転)で計算し、一致していなければ(遠ければ遠いほど)過去の状態で計算する。すると前状態から今の状態へビヨーンと伸びたような3Dモデルに変形できる。この引き延ばされたモデルをバッファにその速度情報で書き出せばピクセル単位の速度分布がわかるベロシティマップが作り出せる。

　この方法は実はいくつか問題点を孕んでいる。1つは、見かけは1つの頂点だが、実は複数の頂点からなっていて、その向き(法線ベクトル)が異なっているような場所があると、引き延ばした時に、破綻して隙間が空いてしまうことがあるということ。2つ目は、最終的には画像処理的にブラー処理するので速度の違う物が重なり合っているような場所で、不自然なブラーが出てしまうこと。3つ目は通常レンダリングに加え、ベロシティマップ生成時に速度方向に変形したモデルを再びレンダリングするため、頂点負荷が単純計算で倍増されてしまうという問題。MTフレームワークの2.5Dモーションブラーでは、それぞれの問題についてユニークなアイディアで対処している。

2.5Dモーションブラーの問題点とその回避方法

左:縮退ポリゴンなし(12,392 triangle)。右:縮退ポリゴンあり(17,765 triangle)

　この1つ目の問題点に対しては、そうした破綻が起こりうる頂点に対してダミーポリゴン(縮退ポリゴン)を仕込んでおくというテクニックで対処したという。こうした縮退ポリゴンを仕込む技は影生成技法のステンシルシャドウボリューム技法でも行なわれるテクニックだ。

ブラー時のサンプリングに深度情報を利用

　2つ目の問題点に対してはベロシティマップ生成時に、その引き延ばされたモデルの深度情報も生成しておき、深度に配慮したモーションブラー生成を行なうことで対処している。具体的には、シーンテクスチャを参照してブラーを生成する際に、その参照先が奥行きとして手前であれば、これは残像生成の参照先としては不適合という判断を下すのだ。これにより背景のブラー生成に手前に立っているキャラクタのピクセルが漏れてくるような変なブラーを低減できる。

シーンテクスチャ	ベロシティマップ	一様に2.5Dモーションブラーを処理してしまうとシーンの前後関係を無視してピクセルが漏れてきたような画になってしまう
シーンテクスチャの深度情報	ベロシティマップの深度情報	深度情報に配慮した形で2.5Dモーションブラーを適用して「漏れ」を低減した場合

　3つ目の問題点についてはゲームらしいパフォーマンス重視の大胆な割り切りと近似の手法を用いている。

　ブラーが起こって見た目に訴えてくるのは比較的近くのオブジェクトのはず。そこで、マジメに定義通りの2.5Dモーションブラーを適用するのは近景だけに限定してしまうのだ。そしてなんと遠景についてはカメラ(視点)の動きによって引き起こされるブラーだけに限定してしまうのである。

　このカメラのブラーも2.5Dモーションブラーのアルゴリズムで作り出すのだが、その際に使用するベロシティマップの生成を、シーンを生成した後にできあがる深度情報(Zバッファ)から近似生成(疑似生成)してしまう。これは現在のシーンで表示されている各ピクセルの“位置”が1フレーム前の時点ではどこにあったのかを逆算して、これをベロシティマップの値としてしまう。この実装により、かなりブラー負荷を一定量に留めることができ、頂点量の増減によるパフォーマンス低下をかなり低減できているという。実際、2.5ブラー処理における負荷の変動要素は近景モデルに限定できるようになる。

2.5DモーションブラーにおいてLOD的概念を導入	近景モデルのみにフルスペックの2.5Dモーションブラー処理を適用	静的、遠景モデルにはカメラブラーに限定するというLOD処理を適用

　この2.5DモーションブラーはXbox 360の統合型シェーダアーキテクチャにも適しているという。というのも、頂点の引き延ばし時には頂点シェーダが自動的に増量されるし、ベロシティマップ生成時やブラー生成時にはピクセルシェーダが自動的に増量される。

石田氏：「実際に計測してみたんですが、現状の2.5Dモーションブラーは大体5msくらいで、そのうちの頂点引き延ばし処理は1msくらいですね。Xbox 360 GPUの頂点性能は最新のPC向けGPUのNVIDIA GeForce 8800シリーズと比較してもいい勝負だという手応えですね」

　あえて今の実装で課題を挙げるとしたら、静止画としての品質があまり高くないこと、そしてMSAAとの相性が悪いことだという。

大きな動きや、重なり部分での破綻	同じシーンのスーパーサンプリング

2.5Dモーションブラーの長所と短所

　前者の問題は、スクリーンショットとして止めてみるとブラーした部分がザラザラしてしまい意外に汚いということを言っている。後者の問題は、2.5Dモーションブラー処理についてはMSAAを適用していないので、MSAAしている部分としていない部分の誤差が画面上に微妙に露呈してしまい、輪郭付近に微妙な毛羽立ちが出てしまうことをいっている。ゲーム中は映像を動画で見るのでほとんど気にならないが、メディアに公開するショットがこれでは困るので、MTフレームワークでは画面ショット提供用にフレームレート無視で品質を優先したスーパーサンプリングモードも持っているとのこと。

MSAAにより輪郭部が毛羽立ってしまうことが
輪郭部を引き延ばす簡易対応でこれを低減

2.5Dモーションブラー処理のパイプライン

　筆者も、そうした問題点よりも、この2.5Dモーションブラーの効果は大きいと思う。

　「ロスプラネット」は基本30fpsだが、体感上はかなり60fpsに近く見え、また、30fpsで追い切れない部分の残像が、かなり立体的な質感で見えるため、ビジュアルインパクトとしても斬新なのだ。この“動く立体ブラー”とも言うべき2.5Dモーションブラーは、ある意味、「ロスト プラネット」のビジュアルの根幹を支えていると言ってもいいと思う。

2.5Dモーションブラー(実際の出荷バージョン)	スーパーサンプリングモーションブラー(理論通りマジメに実装した場合。ほとんど非リアルタイム)	モーションブラーなし

■ 「ロスト プラネット」の“超あり得ない”パーティクル量の秘密
　　～Xbox 360のフィルレートを4倍に引き上げる裏技が発見された!?

　この連載でも指摘したことがあるが、Wii以外の新世代ゲーム機はハイビジョン世代となり、従来の解像度の約4倍～7倍の高解像度モード(いわゆるハイデフ)をサポートすることとなったが、GPUのフィルレート自体は4倍程度しか向上していない。つまり、普通に考えてもギリギリかちょっと余裕がない程度だ。逆に、表示解像度が高くできる分、より凝ったエフェクトを見せないと、画面上の物足りなさがこれまで以上に伝わりやすい。

　しかし、「ロスト プラネット」では、ありえないくらいのボリューム感のあるエフェクトが画面を覆い尽くしており、その量たるや尋常ではない。この圧倒的な量の爆炎、雪煙、閃光は一見しただけではどうやって実現しているのかがわかりにくい。

　この実現の基本的なアイディアは、CEDEC2002で元ぶんか社Gamesの川瀬正樹氏らが発表した「縮小バッファ」技法がベースになっている。

　爆炎、雪煙、閃光などのエフェクトは半透明のパーティクル(スプライト)から成っており、フィルレート喰いの主たる原因はこうした半透明パーティクルの重ね描きにある。もともと半透明パーティクルはぼやっとしたものだし、それが重ね描きされるということはそれ自体に解像感は求められておらず、大胆に言ってしまえば「それっぽく仕上がっていればOK」なのだ。縮小バッファ技法とは、半透明パーティクルの重ね描きを低解像度次元でドカドカと行ない、それを最終的に、ちゃんとした出力解像度のフレームにα合成するというものだ。

縮小バッファ技法	縮小バッファ技法の問題点

　ポイントはシーンフレームの低解像度版を用意し、ここに半透明パーティクルのエフェクトを重ね描きするところにある。低解像度版フレームは元フレームの1/4以下に“縮小”したものだから縮小バッファ技法と呼ばれる。1/4以下のフレームに重ね描きするので低解像度にはなって描画品質は1/4以下になるが消費フィルレートも1/4以下に抑えられる。

　ただ、高解像度表示が当たり前となった今世代では、この技法も粗が目立つ瞬間がある。

　1つは半透明パーティクルの描き込みが低解像度で行なわれるだけでなく、深度テストも低解像度化されたZバッファで行なわれるために、半透明パーティクルとシーン内オブジェクトとの微妙な前後関係が配慮されなかったり、輪郭境界付近との重なりが不自然になったりしてしまう。

　もう1つは、不自然なぼやけが出やすいという問題点もある。縮小バッファ技法では、半透明パーティクルの縮小バッファへの描き込みを行なう際、同時に合成時に用いるマスクパターンを生成する。このマスクの働きにより、縮小バッファとフルフレームと合成されるのは、半透明パーティクルが描かれた部分に限定されるのだが、この透けた部分が低解像度バッファの内容になるので合成時にぼけてしまうのだ。

　こうした縮小バッファ技法の問題点について、MTフレームワークの開発チームは日本のゲーム開発者らしい、ハードウェアの機構を逆手にとった“裏技”を駆使することで対処している。

Xbox 360 GPUの裏技的MSAA(EDRAM)を利用した縮小バッファ技法

　Xbox 360 GPUにはビデオメモリバス消費低減の意味合いで内蔵された10MBのEDRAM(Embedded DRAM)の機能により、4点サンプルのマルチサンプルアンチエイリアス処理(4x MSAA)までをパフォーマンス低下なしに実現できる。MSAAの詳細概念については誌面の都合もありここでは割愛するが、簡単に解説すると、例えば“4”x MSAAの場合を想定するならば、アンチエイリアス処理に用いるピクセルカラーは手抜きの1色としてしまうが、深度情報への配慮とアンチエイリアス処理はちゃんと“4”ピクセル分の解像度(＝“4”サブピクセル)で行なう。

　通常の縮小バッファ技法ではシーンフレームを1/4の解像度に変換して描き込み先バッファとして用意するが、MTフレームワークではシーンフレームの解像度をそのままに、4x MSAAを行なう対象のサブピクセルバッファの内容としてXbox 360 GPUのEDRAMに転送してしまう。この際、ハードウェア設計上の理由から、通常のシーンフレームのピクセル配置とMSAAのサブピクセルバッファの配置が異なっているので、この変換はピクセルシェーダで行なう。

　このあとEDRAM上で(4x MSAA処理は行なわず)、半透明パーティクルのエフェクト描き込みをひたすら行なう。MSAAのアルゴリズムの特性上、 半透明パーティクル側の1ピクセルは、4x MSAAバッファ側の4サブピクセル分に対して描き込まれる。

　全ての半透明パーティクルが描き終わったら、今度はEDRAM側の4x MSAAのサブピクセルバッファを元のシーンフレームの配置に戻して取り出す。これをもともとのシーンフレームと合成する手順などは縮小バッファ技法と同じ。

MSAA縮小バッファを使わずにまじめに描画したケース(24.02fps)	MSAA縮小バッファを使って描画したケース(33.13fps)

　ポイントは3つ。1つは1ピクセル書き込みが実質4ピクセル描き込みになってしまうということ。そして半透明パーティクルの深度テストと重ね描きはちゃんと4サブピクセル(あとでは実質的に4ピクセルに相当)に行なえてしまう。さらに、これがXbox 360 GPUのEDRAM上で、コストフリーで行なえてしまうということ。そう、語弊があることを覚悟して言ってしまえば、かなりの負荷を占めるエフェクト書き出しに関して、4倍のフィルレートが実現されてしまうのだ。

　そして、縮小バッファ技法と異なり、描き込み対象のバッファの解像度は維持されるので、前述した「合成部のボケ」の問題が起きない。深度テストがフル解像度で行なわれるので前後関係や重ね描きの不自然さも起こらない。また、縮小バッファ自体を用いないのでフルフレームとの合成用のマスクも不要になる。

　もちろん、デメリットもある。1ピクセルが4ピクセル分として描き出されるので、半透明パーティクルは1/4の低解像度となってブロッキーなエリアシングが見えやすい。特に小さく描かれるべき遠距離のエフェクトにその粗が見えやすい。

MSAA縮小バッファの長所と短所

被写界深度モーションブラー(薄め)の効果によりブロック化アーティファクトを低減

　この点に関して、一定距離より遠くの半透明パーティクルのエフェクトについては、この特殊技法を用いないというLOD(Level of Detail:視点からの距離に応じて処理を切り換える負荷低減テクニック)を実装して対処している。なるほど、遠くのエフェクトは小さく描かれることが多いので、面積も小さく、つまりはフィルレート消費も少ないはずなので、理にかなっている。また、被写界深度のシミュレーション(焦点が合っていないとする部分を意図的にぼかす)、モーションブラーなどの副次的効果もあり、「ロスト プラネット」では、かなりうまくごまかせているとのこと。

　この方法はかなりユニークで、今後、Xbox 360の裏技として活用されていきそうだ。

石田氏：「EDRAMって4x MSAAを使ったときくらいにしかその有効な使い方って無かったんですけど、この方法はこれからのもう1つの使い方になるんではないかなと思っています。ええ、マイクロソフトからもよく考えましたねといわれました(笑)」

■ 影生成はカスケード・ライトスペースシャドウマップ技法を採用

かなり高品位な影生成を実践している「ロスト プラネット」

　今世代のゲームでは無視することのできない影生成。「ロスト プラネット」では、焼き込みの事前生成の影も無くはないが、基本的には動的な影生成を実践していて、もちろん自分の影が自身にも投射されるセルフシャドウや、異なる3Dオブジェクトが影を落とし合う相互投射影も実現している。影生成技法は一体どんな技法を採用しているのだろうか。

上田智広氏：「基本的な考え方はライトスペースシャドウマップ技法(LSPSM:Light-Space Shadow Maps)です」

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

　高品位にジャギーのない影生成を行なうためには、このシャドウマップを高精度に生成する必要があり、そうでないと影の輪郭付近で影か否かの判断のエラーが多くなり、ジャギーやちらつきが目立ってしまう。これを抑えるには理論上は無限大の解像度のシャドウマップが必要になってしまう。

　とはいうものの、Xbox 360、PS3などの今世代のゲーム機の影生成はこのシャドウマップ技法が有望視されており、各開発者はこのエラーを克服するために様々な工夫を考案している。

　その改良版シャドウマップの1つがLSPSMなのだ。LSPSMについては、本連載の「3DゲームファンのためのXbox 360グラフィックス/物理エンジン講座～Xbox 360用ゲームライクテクニカルデモ『妖精の棲む森』の秘密」にて詳細に紹介しているのでそちらを参考にして欲しい。

セルフシャドウ、相互投射影。「ロスト プラネット」の影生成は全部入りだ

上田氏：「基本的な実装はLSPSMなのですが、視線(視錐台=View Frustum)からの距離応じて近、中、遠の3段階に分けて、それぞれ個別のシャドウマップを生成しています。『ロスト プラネット』では1,024×1,024テクセル解像度のシャドウマップを近、中、遠にそれぞれ割り当てていますので、影生成だけで毎フレーム12MBレンダリングしていることになりますね(笑)。ご存じのようにシャドウマップ生成時にはZバッファレンダリングが行なわれますが、Xbox 360 GPUはZ出力だけのときはフィルレートが2倍になるんで、それに助けられていますね」

　3面のシャドウマップは1枚を3回使い回すのではなく、実際に1,024×1,024テクセルのテクスチャを3面確保しているという。言ってみれば影生成だけで、PS2の3倍のビデオメモリを消費しているわけだから、ある意味、すごく「次世代」な感じがする。

このシーンの近距離シャドウマップ	同じく中距離シャドウマップ	同じく遠距離シャドウマップ

カスケード拡張されたLSPSM技法の概念図

　図の黒い部分が視錐台(視界)、そして光源方向が赤矢印だとすると、LSPSMでは緑のような感じに、光源向きと直角になるように光源からの仮想的な視錐台を形成させ、これが視界を内包するように割り当ててシャドウマップを生成する。この工夫によって原形シャドウマップ技法よりも近から遠にかけての誤差は大部平均化されるが、近場のジャギーや遠方でのフリッカーは完全には無くならない。「ロスト プラネット」では、このLSPSMをさらに拡張し、青のように、視界を遠中近と3分割してそれぞれに1,024×1,024テクセルをカスケードさせてシャドウマップを生成するのだ。

　LSPSMのカスケード拡張は最新3Dグラフィックスエンジンの最近のトレンドになりつつあり、3DMark06で採用されている他、id softwareが開発中のDOOM4エンジン(仮称)もこのタイプの拡張技法を採用していると言われている。

上田氏：「影の実際の描画時には、描こうとしているピクセルのビュー座標系でのZ値でどのシャドウマップを使うかを単純に切り替えているだけです。それぞれのシャドウマップ境界において補完するような処理も試してみたのですが重かったので採用しませんでした」

　着眼的には香港大学Fan Zhang氏らの並列分割シャドウマップ技法(Parallel-Split Shadow Maps)にある方法と似たものと推察される。Zhang氏らの手法では自動で分割する距離を算出する実装になっているが、「ロスト プラネット」では分割距離を手動設定して調整しているという。

　「ロスト プラネット」では巨大ボスから、VS兵器までが、かなり高品位なセルフシャドウを出しているので、注目して見よう。

1枚のシャドウマップではLSPSMでの破綻条件(光源の向きとカメラの向きが近い時)では、このように破綻する	同一シーンでも、3枚のシャドウマップを用いたカスケード拡張されたLSPSMでは破綻を回避できる

　さて、その影を注意深く見ると、影の輪郭が微妙に柔らかくなっており、いわゆるソフトシャドウになっている。これについては、ピクセルシェーダを活用し、9サンプルしての近傍比率フィルタリング(Percentage Closer Filtering:PCF)によるボカシ処理を実施しているとのこと。こうした影生成時にぼやけさせるのは常套手段となりつつあり、同じシャドウマップ系の影生成を採用する「Splinter Cell 3: Chaos Theory」(UbiSoft)では、ピクセルシェーダ3.0の動的分岐命令を活用して影の輪郭周辺のみ16サンプルするソフトシャドウ処理を入れていたが、「ロスト プラネット」ではどうなのだろうか。

上田氏：「試してみたこともあるんですけど余計な動的分岐が入ると遅くなるんですよね。『ロスト プラネット』では影の中も外周の輪郭周辺目別なく一様に9サンプルのフィルタを掛けてしまっています」

一般的な4点サンプリングのバイリニアPCF	9点サンプリングのバイリニアPCF

■ 「ロスト プラネット」は次世代ゲームグラフィックスのショーケース!?

　「ロスト プラネット」は、(前出の影もそうだが)今世代の3Dゲームグラフィックスで、標準になるだろうといわれるテクノロジーが、ほとんど全てが実装されている。

　まず、微細凹凸は、法線マップを用いたバンプマッピングを実装しているし、動的トーンマッピングを組み合わせたハイ・ダイナミック・レンジ・レンダリング(High-Dynamic Range Rendering)も採用している。

法線マップなし	法線マップあり

　HDRレンダリングはXbox 360オリジナルの指数3ビット仮数7ビットの“7e3”からなる10ビット浮動小数点のFP10ベース。環境マップやテクスチャもHDR次元なので、映り込んだ情景などもHDR次元で処理される(後述)。HDRテクスチャはFPではなく整数バッファにエンコードする方式を採用している(後述)。

ブルーム、グレアといったHDR表現は全て実装	FP16-64ビットバッファによるHDRレンダリング	FP10-32ビットバッファによるHDRレンダリング。製品版ではこちらを使用。半分の帯域、メモリ使用量でもFP16に肉迫した高品位レンダリングを実現できるのもXbox 360 GPUのアドバンテージ

「ロスト プラネット」の水面

　水面などは複数レイヤーの法線マップをスクロールさせる基本技で、水底はシーンをレンダリングしたテクスチャをサンプルする方法、そして水面への映り込みは事前作成の環境マップを採用している。波動シミュレーションや動的鏡像の水面への映り込みは省略。ただし、視線角度に応じてインタラクティブに周囲の映り込みと水底の情景の混ぜ具合が調整されるフレネル反射は考慮される。これは、特に対戦マップの一部で効果的に使われているので確認してみよう。

人肌はスペキュラとディフューズの調整でそれっぽく見せている。ファーの積層数は8層とのことだ

　人肌などは鏡面反射(スペキュラマップ)と拡散反射(ディフューズ)のバランスをデザイナが調整してアートワークでそれっぽく見せている方式。

　毛皮を表現するファーシェーダーは、主人公の衣装の首周りなどに用いられているが、これはバンプマップを積層させたようなシェル型のファーシェーダーを採用している。

　そして、特記しておきたいのが、おそらくは一般プレーヤーだと、あまりにも自然すぎて目が行かないのが爆炎、閃光、吹雪などのパーティクル処理。

　よく、煙が3Dキャラクタや背景に切り取られ、境界線がくっきり見えてしまうような表現を多くのゲームで見たことがあるはずだ。PS3、Xbox 360世代でも手を抜いているタイトルは少なくなく、未だにそうした表現に遭遇することは多い。大量にパーティクル・エフェクトが重ね描きされる「ロスト プラネット」では、ここで手を抜くことは考えられなかったようで、パーティクルの切り取られエッジを柔らかくする工夫が盛り込まれている。

　「ロスト プラネット」のパーティクルは全て厚みの情報を持っており、全てのパーティクルを描き終えて最終的な厚みが決まり、そのシーンのZバッファの内容(深度値)とこれを比較して、境界と近ければ(つまりは切り取られ境界に近ければ)近いほど、パーティクルの色を薄めるという処理を行なっている。つまり、切り取られのエッジが見えてしまうのは、パーティクル側の絵の内容が突然立ち消えているからそう見えてしまうのであって、これを見えにくく、境界線に向かって色を消す処理をピクセル単位で実行するのだ。

石田氏：「実は地味に見えてソフトパーティクルはピクセル単位でカメラ(ビュー)座標系の深度を計算したり、ピクセルシェーダへの負荷が重い処理なんですよ。ただ、我々のMTフレームワークでは例の4x MSAA(EDRAM)の裏技を使った縮小バッファによる高速化があるので、それで実用レベルでこれを動かせているんですよ」

通常パーティクル。パーティクルと床の交差線が強く見えてしまっている	ソフトパーティクル処理適用。交差線が消え自然に見える

■ 法線マップやHDRテクスチャの圧縮メソッドに対する工夫

　少々地味だが重要な話題も取りあげておこう。

　Xbox 360、PS3などの新世代機では、法線マップ、HDRレンダリングに用いるHDRテクスチャなど、多様なテクスチャを取り扱うが、そうした特殊なテクスチャの圧縮メソッドが今のところまだ標準規格として存在しない。

　Xbox 360 GPUでは法線マップ圧縮メソッドが独自規格として提供されているが、HDRテクスチャの圧縮メソッドはない。

HDRテクスチャや法線マップの標準的な圧縮メソッドが無いので、これを独自拡張実装する必要がある。この問題はXbox 360、PS3の双方にある問題

　MTフレームワークでは、従来の通常の画像テクスチャ圧縮のメソッドであるDXTC(DirectX Texture Compressioin)を応用しつつ、そうした特殊テクスチャを圧縮する技術を実装している。

　ユニークなのは、容量よりも品質を重視した高品位版、そして品質よりも容量を重視した低品位版の2つを実装しているところ。これは、シーンの目立つところに高品位版を使い、目立たないところを低品位版を使って、メモリ容量や帯域消費低減に配慮するため。どっちを使うかはシーンをデザインするアーティストなどが決めるのだろう。

　いずれも高品位版にはDXT5を、低品位版にはDXT1の圧縮メソッドを用いる。なお、DXT1はα値を0か1で固定として圧縮率を稼ぐテクスチャ圧縮メソッドで圧縮率が1/8となる。DXT5はα値もそれなりに圧縮されるメソッドで圧縮率としては1/4となる。MTフレームワークでは、法線マップ、HDRテクスチャなどを圧縮する際に高品位圧縮する場合にはDXT5、低品質容量重視とする場合にはDXT1を用いる。

　法線マップの圧縮では、DXT5の時は法線ベクトルX、Y、ZのうちXをαに、YをGに分離して、なおかつR=1.0と固定して格納するようにする。DXTは不可逆変換な圧縮アルゴリズム(ロッシー:Lossy)なので圧縮することでいずれにせよ品質は低下するが、DXT5のαとRGBは独立した代表値を元に圧縮するために、このケースでベクトルの要素のX、Yを独立して圧縮することになるので品質が高くなる。なお、法線ベクトルは正規化された絶対値1の単位ベクトルなのでZは計算で求められる。

　DXT1の場合は便宜上α=1.0とし、法線ベクトルX、Y、ZのXをRに、YをGに格納することになり、X、Yが分離して格納されないために誤差は大きくなるが、容量自体はDXT5の半分にできる。

　注目すべきはX=R×A、Y=G、Z=SQRT(1.0-X^2-Y^2) という同一シェーダでデコードして利用できてしまうという点。圧縮率が全く違う2つのメソッドで圧縮された法線マップをシェーダを切り換えることなく利用できてしまうのは面白い。

法線マップの圧縮

　HDRテクスチャ(高階調テクスチャ)も、この品質重視、容量重視の2通りで圧縮して、利用時は同一シェーダで取り扱えるというよく最適化されたメソッドを実装している。

　環境マップ用のHDRテクスチャでは、あらかじめ、スケーリング係数となるテクスチャ全体の最大値の逆算をαに持ち、RGBをその最大値で割った答えをテクスチャで持つというアルゴリズムで実装している。法線マップのような単位ベクトルの逆算のようにいかないため、HDRテクスチャのRGB値の全てを圧縮して格納することになり、誤差は小さくはない。また、DXT1ではHDRのダイナミックレンジは失われてしまうが、同一シェーダで処理できるというメリットはある。

　HDRライトマップなど、その他のHDRテクスチャの場合も、ほとんど前述のHDR環境マップの時と考え方は同じだが、テクスチャ全体の最大値は定数として持ち、レンダリング時にこの最大値に配慮して陰影処理を行なう。DXT5の場合は圧縮するHDRテクスチャ自体のRGB値は正規化してしまい(絶対値を1にする)、その絶対値をαに格納する。DXT1ではRGB値自体の絶対値が失われるので階調品質は悪くなるが、ダイナミックレンジを司る最大値は定数として配慮されるので、HDRテクスチャとしての役割は維持される。

　「高品位版と容量重視版の使い分け」、そして「テクスチャ側は使い分けるが、シェーダは1つでOK」というところが、3Dゲームグラフィックスに都合がよいのだ。

HDRテクスチャの圧縮
高階調テクスチャの圧縮

■ まとめ

　PS3、Xbox 360世代のゲーム開発は、特にグラフィックス部分やミドルウェアにおいて、欧米のスタジオに対してやや遅れ気味である……ということがよく言われるが、このカプコンのMTフレームワークを見る限りでは、そういった不安要素は微塵も感じない。

　もちろん、これは「“大手”カプコンの特殊例」という見方もできなくはないが、少なくとも、フルスクラッチビルドの純国産の汎用ゲームエンジンで、世界と渡り合えるクオリティで2つのタイトルをリリースできているという事実は、日本のゲーム開発シーンに大きな希望や夢を与えたと思う。

　一般ユーザーは、ただの既存ゲームの高解像度版が多い中、「本当の次世代機のゲーム」を体感したいのであればぜひとも「ロスト プラネット」に挑戦してもらいたいと思う。

　「デッドライジング」、「ロスト プラネット」という2大Xbox 360タイトルで経験と実績を積んだMTフレームワークは、今後、「デビルメイクライ4」で活躍の場をPS3へと拡大する。そして続く「バイオハザード5」ではPS3、Xbox 360の両プラットフォーム展開が予定されており、これの完成を持ってMTフレームワーク“計画”は、「ひとまずの完成」を見ることになる。

　これからのカプコンのPS3、Xbox 360タイトルは期待大だ。最後に各人のコメントを頂いたので、まとめさせていただいた。

石田智史氏(第二制作部ソフトウェア制作室・プログラマ)：「MTフレームワークのシステムやレンダリングエンジンなどの設計を担当しました。表には出てこないことなんですけど、ツール関係はGUIにこだわって製作しました。あと、これだけは言っておきたいんですが、Xbox 360はとてもいいハードウェアなんです」

澤田泰英氏(第二制作部ソフトウェア制作室・プログラマ)：「DCCツールのエクスポータ、様々な材質のシェーダやフィルタシェーダの設計を担当しました。マテリアルシェーダの組み合わせは全部で500～600種くらいはあります。パララックス・マッピングなどを作ったけど「ロスト プラネット」では結局使われなかったシェーダも結構あったりします(笑)」

上田智広氏(第二制作部ソフトウェア制作室・プログラマ)：「サウンド処理全般、影生成、そして日本版ではカットされたデッドライジングの敵ゾンビの切断表現とかを担当しました(笑)。影はあらゆるシーンで出ているのでちょっと重くなると、みんな影のせいにされるのがつらかったです(笑)」

伊集院勝氏(第二制作部ソフトウェア制作室・室長)：「今回のプロジェクトではプロダクトマネージメントを担当していました。今世代では、特に、研究開発に力を入れており、こうしたフレームワーク環境を整備できたことは、国内メーカーのなかでは結構な最先端を行っていると自負しています。これからもさらなる拡張・発展をさせようと考えており、人材はいくらいてもい足りません! もしこういった先端技術の開発に興味がある・従事したいとお考えの方は、是非カプコンに来ていただけたらと思います」

【ロスト プラネット エクストリーム コンディション】
• ジャンル：アクションシューティング
• 価格：8,379円
  
• 対応OS：Xbox 360
  
• 発売日：発売中 (2006年12月21日)
  
  【デッドライジング】

• ジャンル：ゾンビパラダイスアクション
• 価格：8,379円
  
• 対応OS：Xbox 360
  
• 発売日：発売中 (2006年9月28日)
  
  

□カプコンのホームページ
http://www.capcom.co.jp/
□「ロスト プラネット エクストリーム コンディション」のページ
http://www.capcom.co.jp/lostplanet/
□「デッド ライジング」のページ
http://www.capcom.co.jp/deadrising/

(2007年1月31日)

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