| 【Watch記事検索】 |
| 最新ニュース |
|
【11月30日】 【11月29日】 【11月28日】 【11月27日】 【11月26日】 |
|
| ||||
|
3Dゲームファンのための「3DMark 05」エンジン講座(後編) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
■ プログラマブルシェーダ1.xベースのGPUは足切りに!
「3DMark 05」の3Dグラフィックス処理系では、DirectX 7時代までの固定機能の活用を極力活用しない方針になっており、根幹となる陰影処理においては積極的にプログラマブルシェーダを活用する方向で設計されている。ちなみに、「3DMark 03」ではGame Test1がマルチテクスチャベースのDirectX7時代の処理系を採用していたが、今回の「3DMark 05」ではそうしたテストは廃されている。
処理系を構成するシェーダプログラムは、最低でもプログラマブルシェーダ2.0仕様が必要と言うことになり、これがそのまま3DMark 05の動作条件となっている。今でもユーザー数が多いATI RADEON 8500～9200シリーズ、NVIDIA GeForce4Tiシリーズは、プログラマブルシェーダ1.xベースのGPUであるため、3DMark 05を動作させることができない。事実上の足切りをくらった格好になるわけだ。
動作条件を細かく見ると「プログラマブルピクセルシェーダ2.0が必要」ということになり、「それではプログラマブル頂点シェーダは無くて良いのか」ということになるわけだが、それはその通り。インテルのグラフィックス統合チップセットi915G系にはハードウェアとしてのプログラマブル頂点シェーダは実装されておらず、プログラマブル頂点シェーダの処理系はCPUエミュレーションで代行される。しかし、プログラマブルピクセルシェーダの方は2.0相当のものがハードウェア実装されているので、ギリギリ、「3DMark 05」が動作できるのだ。
2004年10月現在、動作条件でここまで厳しい足切りを設定した3Dゲームは存在しない。なかなか大胆だが、これを機会にグラフィックスハードウェアの買い替え需要が少なからず起こるかもしれない。
■ プログラマブルシェーダ3.0仕様への対応はどうなったか?
 |
| これは3DMark 05を有償登録すると設定変更が可能になる「Benchmark Settings」画面。ベンチマーク実行の際、頂点シェーダとピクセルシェーダをそれぞれどのバージョンで活用するかを設定できる |
 |
| プログラマブルシェーダ3.0対応化パッチを適用して実行した「FarCry」の画面。上に「SM30 Path Beta」の文字が現れている点に注目。ビジュアル的な差異はプログラマブルシェーダ2.0仕様の通常時と一切なし。変わるのはパフォーマンス |
このような状況下で、業界標準の3DMark 05がどのような対応方針を取ったかは、確かに注目されるところである。結論から言えば、これについては少々、微妙な対応状況にある。順を追って説明するとしよう。
各種マテリアル表現を行なうためのシェーダはマイクロソフトが提供するシェーダプログラミング言語HLSL(High Level Shader Language)ベースで書かれており、シェーダプログラムの長さやシェーダ構造は基本的にはプログラマブルシェーダ2.0仕様の範囲に収まるような設計になっている。その意味では「3DMark 05はプログラマブルシェーダ2.0仕様ベース」といってもいいと思う。
ところがそうとも言い切れないのが、3DMark 05では、そうしたHLSLで書かれた各シェーダプログラムを、実際のベンチマークテスト実行前にランタイムコンパイラでコンパイルしていることだ。そのコンパイル時に、どのプログラマブルシェーダ2.0/2.0a/2.0b/3.0タイプに対応させるかを指定することで、各世代のGPUにて最高のパフォーマンスが得られるような方針を取っているのだ。
プログラマブルシェーダのバージョン番号は大きければ大きいほど、シェーダプログラムに使える命令バリエーションが増え、プログラム長に対する制限が緩和される(プログラマブルピクセルシェーダ2.0aと2.0bの関係は微妙だが)。よって同一のシェーダプログラムでもコンパイルする際に、どのプログラマブルシェーダ仕様に適合させるかで、そのシェーダプログラムの実効パフォーマンスは変わってくるのだ。
3DMark 05では、デフォルトではそのシステムのGPUにて使える最良のプログラマブルシェーダ仕様が自動選択されるようになっている。例えばGeForce6x00シリーズであればプログラマブルシェーダ3.0が採択され、RADEON X800シリーズならばプログラマブル頂点シェーダに2.0、プログラマブルピクセルシェーダには2.0bが採択されることになるわけだ。なお、このコンパイル時のシェーダ仕様の選択は3DMark 05を有償登録することでユーザーが明示的に変更できるようになる。興味のあるユーザーは試してみると良いだろう。
結局、3DMark 05は、「プログラマブルシェーダ3.0に対応している」といえなくはないが、少なくとも「3.0のポテンシャルを活かしきった活用ではない」ということができるだろう。
プログラマブル頂点シェーダ3.0には、テクスチャへのアクセス能力が備わり、これを応用することで、限定的な定数領域の制限を超えた高度なスキニング処理や、3Dモデルを自在に変形させてモーフィング表現などを可能にする「ディスプレースメントマッピング」等が出来るようになったが、こうした新技術を3DMark 05では活用していないのだ。3DMark 05におけるプログラマブルシェーダ3.0仕様の活用は「シェーダプログラムの最適化手段止まり」ということになる。
これを「期待はずれ」、「手抜き」、「2.0に踏み留まったATIに配慮した?」と責め立てることもできるが、NVIDIAが広告塔として前面に押し出した新世代3Dシューティングゲーム「FarCry」(UBI SOFT/CRYTEK)も、6月にリリースされたプログラマブルシェーダ3.0仕様パッチは高速化目的の3.0対応化であった。また、2004年9月までの筆者の取材でも「プログラマブルシェーダ3.0仕様は当面、2.0ベースシェーダの高速化や最適化目的で活用していく」とするゲームスタジオが多く、その意味では3DMark 05の取った方針はあながち間違いでないのかもしれない。
それではさっそく各Game Testに目を向けてみることにしよう。
■ Game Test1:Return To Proxycon
タイトルを見ても分かるように、シナリオ的には3DMark03の「Game Test2:Battle of Proxycon」の続編にあたるものらしい。貨物船が宇宙海賊に襲われたという設定で、宇宙海賊対貨物船側の警備隊との激しい銃撃戦が繰り広げられる。Futuremark側としては、このテストを「3Dシューティングゲームを想定したベンチマークテスト」としている。
ハイダイナミックレンジ(HDR)レンダリングについての詳細は後述するが、ハイライト部分から光が溢れ出る「ライトブルーム」表現が見て取れる。これはできあがったフレームをプログラマブルピクセルシェーダによりポストプロセスを行なって付加した効果だ。こうした擬似的なHDR表現は、もはや最近の3Dゲームでは当たり前になりつつある。
天井には無数のライトが敷き詰めてあるという設定で、これは並行光源の設定で近似している。シーン内の影生成は前述したPSM技法によるものだが、この並行光源からの光でのみ、影が生成されている。この影生成には前述したように2,048×2,048テクセル解像度のシャドウマップが用いられている。
この他、シーン内には点光源がいくつも設定されているが、これらのほとんどは影生成に関与していない。廊下側のライトは例外的にそれぞれが影生成に影響する点光源になっており、これら光からの影は6面体のシャドウマップを生成して行なう全方位シャドウマッピングによって生成されている。
ベンチマークテストの結果は、Pentium4/3.2GHz+RADEON X800XTで15.6fps(測定オプションはデフォルト、以下同)。同GeForce6800Ultraで17.8fpsであった。
 |
 |
| 宇宙船内ということで、セット内の3Dモデルの表面は金属で出来ていると言う設定になっている。この金属材質の表現には最も基本的な鏡面反射モデルであるブリン・フォン(Blinn-Phong)反射モデルが採用されている | 床やその他の小道具オブジェクトのディテールの多くは法線マップ(バンプマッピング)によるもの |
 |
 |
| 各フレームのハイライト部分や強く光る光源体には、その光が溢れ出て見えるようなHDR表現を加えている。こうした表現は最近の3Dゲームではよく見かけられるようになってきた | 回廊のシーン。ここで人物キャラから落ちている影は回廊側に設置された点光源からの全方位シャドウマッピングによるもの。地味なシーンなので、その優位性があまり目立っていない。床に落ちているやわらかい影は、背景へ焼き込まれたもののようで、リアルタイム生成されたものではなさそうだ |
■ Game Test2:Firefly Forest
 |
| 背の低い草の淡い影は並行光源として設定されている月光からの光によるPSM生成された影。点光源として設定された蛍からの光からの鮮明な影は全方位シャドウマッピングによって生成されたもの |
 |
| 近似モデル化した光散乱シミュレーションは最近のGPUにとってはそれほど負荷が高くなく、それでいて得られるフォトリアリスティック度は高いため、今後はメジャーなポストプロセスとして、様々な3Dゲームに採用されていきそうだ |
全体的に暗いシーンなのでわかりにくいが、このシーンには無数の植物が配置されており、これらが「柔らかいそよ風に揺れている」という設定で、各自バラバラのタイミングで動いている。
特筆すべきは、ここでも影の表現で、現存する3Dゲームでは前例のない、すべての植物に影がセルフシャドウ付きで表現されている。しかも蛍の光は、点光源として植物の影を全方向に投射しており、これも同時に配慮されている。影生成はもちろんPSM技法によるもの。針葉樹に射影される影にジャギーが出ているが、暗いシーンなので幸い目立たない。
さて、無数の植物表現を行なった3Dゲームとしては「FarCry」(Ubisoft)が記憶に新しいが、「FarCry」でもさすがに植物1つ1つの影生成については省略していた。3DMark 05はベンチマークソフトであり、技術デモでもあるため、実際のゲームと比べられないが、将来的には実際の3Dゲームの屋外シーンでもこのような表現が出来るようになるのかもしれない。
植物の配置は、視線の向きに応じてその都度マップデータを元に動的に配置されており、視線からの距離に応じて、3Dモデルを切り換えるLOD(Level Of Detail)処理が行なわれているという。このあたりは実際の3Dゲームに近い処理系を模したものになっているようだ。惜しむらくは、プログラマブルシェーダ3.0仕様と一緒に追加されたジオメトリインスタンシングに対応していない点。このテストのように同一植物モデルを無数に配置する場合などは、ジオメトリインスタンシングに対応させればかなりのパフォーマンス向上が期待できたはずなのだが……。
材質表現のシェーダーは基本的にはGame Test1と似ており、鏡面反射と拡散反射の組み合わせ比率の違いで岩や樹木、草木の質感をコントロールしている。
注目したいのは霧の表現というか空気遠近表現。これは視点からの距離だけで色を背景色に沈み込ませていくいわゆる普通のFog機能ではなく、光散乱(Light Scattering)シミュレーションにて行なわれているため、開けた空域が強く白く霞み、シーンの複雑なジオメトリ構造に依存した形での空気遠近となっており、高いリアリティを生み出している。なお、光散乱シミュレーションについては本連載の「鬼武者3」エンジン講座にて解説しているので、詳細についてはそちらを参照して欲しい。
影生成については月光を並行光源として設定、2,048×2,048テクセルのシャドウマップを使ったPSM技法で動的なリアルタイム影生成を行なっている。そして主役の蛍は点光源として設定され、512×512テクセルの6面体シャドウマップによる全方位PSMによる影生成を行なっている。
ちなみに、シーンとしては短いが、RADEON X800XTで12.5fps、GeForce6800Ultraで12.4と、全テスト中最も重いテストとなっている。
 |
 |
| 草や樹木が鬱そうと生い茂る原生林のシーン。その1つ1つに動的な影生成が行なわれている。3DMark 05のGame Test中、最も地味ながらもっとも重いテストになっている | |
 |
 |
| 画面ショットだけでは分かりにくいが、針葉樹の枝を蛍が通り抜けるとき、蛍を取り巻く枝の影が全方位に投射され蛍の動きに合わせて影も動く。これが全方位PSM。実際の3Dゲームの屋外シーンで、ここまでの影生成を行なって60fpsがキープできるようになるのはいつの日か | 左下の岩には月光からのPSM生成された樹木の淡い影が投射されているが… |
 |
 |
| 蛍がやってくるとその影は蛍の光でかき消され、岩の上には、その蛍の光が作り出す、背の低い草の葉の影が強く出るようになる | 静止画では分かりにくいが、月光からの光のPSMによる影と、蛍の光からの全方位PSMによる影が同居している瞬間。どちらの技法による影も、その投射距離が長くなるにつれて色の濃さを薄くするテクニックが盛り込まれており、いわゆる、疑似ラジオシティ(相互反射)っぽい効果になっている |
■ Game Test3: Canyon Flight
 |
| 遠方の渓谷を構成する岩肌の材質表現は3DMark 05のシェーダでは最も重い部類に入る。ただし、詳しい説明が無いので具体的な処理系は不明だ |
一番目を引く水面の処理は、さざ波表現を法線マップ(バンプマッピング)で行ない、さらにその水面を構成する各ピクセル単位において、その屈折と反射の具合をフレネル項(反射と屈折、そしてその割合を視線と水面の位置関係で変化させる仕組み)に配慮して調整している。水面に対して視線角度が浅ければ浅いほど(視点から遠いほど)水面への背景の映り込みが強く出て、視線角度がきついほど(視点に近いほど)映り込みが淡くなる表現になっているのはそのためだ。
 |
 |
| 水面のさざ波表現そのものは動的な法線マップのようだが、水面全体に周期的パターンが感じられ若干「いかにもCGの水面」という感じがするのが残念だ。このあたりはNVIDIAのデモなんかの方が上手な感じがする | |
このシーンは晴天ということもあり、光源は太陽に模した並行光源を1つ天空に設定している。この並行光源は太陽と言う設定であるため、ハイダイナミックレンジな光源として設定されており、陰影処理の結果、一定以上の明るさを持つ部分の周囲にはライトブルーム効果がポスト処理で描き込まれている。全体的に眩しい情景になっているのは、この効果のおかけだ。
HDRレンダリングといえば、強く光っている箇所をαチャンネル等にマーキングしつつレンダリングを進めていき、できあがったフレームに対して、ポスト処理でその強輝度部分をブラーさせて合成する疑似HDRレンダリングが最近の主流だが、3DMark 05におけるHDRレンダリングは、HDR光源を設定して、陰影処理もHDR処理する“本当の”HDRレンダリングが行なわれている。3Dゲームにおいてはそのコストパフォーマンスの高さから疑似HDR表現でも必要十分という意見も多いのだが、3DMark 05はベンチマークソフトなのであえてオーバーキルな手法を採択したようだ。
3DMark 05では、HDR並行光源を設定し、シーン内の主要な陰影処理を浮動小数点実数(FP)次元でHDRレンダリングしているという。各シェーダの演算精度は、度重ねた実験結果に基づいて決められており、描画結果に影響が少ない演算については極力速度が稼げる16ビットFP精度を活用しているとのことだ。ちなみに、Benchmark Settingで全シェーダを32ビットFP精度で行なうように変更できる。GPUに負荷を掛けるだけ掛けてベンチマークを計測したい場合にはこの機能を活用すると良いが、その描画品質に差異はほとんど現れない。
 |
 |
| 「SplinterCell」シリーズは疑似HDRレンダリングを行なっている3Dゲームのの代表格といえる。これでも十分それっぽく見える | 床の光が、その手前にあるはずの手すりにまであふれ出している。これはカメラのレンズ内反射や睫毛による光の回折現象などを模した効果。物理的な正確性よりも「目で見たときのリアリティ」を高めるための効果だ |
 |
 |
| これは、HDR光を受けて、強く輝いている部分から光があふれ出すライトブルーム(ライトブリーディング)効果を後処理(ポスト処理)で付加することで実現されている | ポスト処理を禁止すると途端にこのようなつまらないビジュアルになる。HDR効果は絶大だ |
そして、もうひとつ印象的な、空からの溢れように降り注ぐ光の感じは、Game Test2同様に光散乱シミュレーションによるものだ。DEMOモードではこのGame Test3のセットを背景にスタッフロールが流れるが、ここでの夕焼け効果は光散乱シミュレーションの結果として空が青紫から美しい赤へのグラデーションを形成している。
シーン全体にかかっている空気遠近の感じは、特別なボリュームフォグ処理にて表現されているとFuturemarkは説明しているが、光散乱シミュレーションの効果を別な切り口で説明しているだけのようだ。ちなみに、この光散乱シミュレーションの演算に利用する、視点から見たシーンの奥行き情報の格納には贅沢にもD3DFMT_R32F形式の32ビットFPテクスチャを使用しているとのこと。
こうした処理系の効果で、シーンのジオメトリ構造に起因したきめ細かな濃淡の霞みが現れるようになり、薄霧に沈み込んでいる箇所においても3Dオブジェクの立体感や、シーンの正確な遠近感が感じられるようになっている。これはいわゆる通常のZ距離フォグでは実現できない効果だ。
 |
 |
| 日が徐々に暮れていくにつれて空が赤みを帯びていく様子は光散乱シミュレーションによるもの。別シーンへ切り換えていくのではなく、こうしたプロシージャルなアプローチでシーンを生成する手法はデータ量の削減になるだけでなく、説得力のあるビジュアル表現にも結びつく | |
 |
 |
| 奥が霞んで見えるこうした空気遠近の効果も光散乱シミュレーションによるもの。単にFog機能を使ったものではない | |
 |
| 船尾エンジンの影はそれほどでもないのに、気球末端の尾翼の影はひどいエリアスが発生している |
さて、PSM技法は屋外シーンに適合したシャドウマッピング技法のはずなのだが、遠方の岸壁の凹凸の影や、近場でも一部の影に激しいフリッカーとジャギーが見て取れる。これはなぜか。
まず、最も単純な理由となるのが、さすがにここまで広大かつ見通しの良いシーンでは、2048×2048テクセル程度の大きさのシャドウマップでは解像度不足となるという事だ。 そして、光源方向と3Dオブジェクトの位置関係で、その影が極端に長く伸びる箇所では、シャドウマッピング技法系の最悪ケースとなるため、どんなにシャドウマップ解像度を上げても描画結果が最も厳しくなる。近場で見られるフリッカーやジャギーはこうしたケースが発生した箇所だと思われる。
根本的にはシャドウマップ解像度を無限大に上げれば解決できる問題であるが、それを実際に行なうのは言うまでもなく無理な話。3DMark 05では、現行GPUで処理できるギリギリの線でPSM技法を実装したわけだが、まだまだこうしたシーンを完璧にこなすためには、GPU側の進化やアルゴリズムの改良が必要なのだ。
念のために言っておくと、このフリッカーやジャギーはドライバの改善でどうにかなるものではない。また、DST形式でPSM技法を実行するGeForce系と、D3DFMT_R32F形式でPSMを実行するRADEON系で、フリッカーやジャギーの出方が違うことを議論してもあまり意味がないことも付け加えておく。
ちなみに、このテストはRADEON X800XTで27.0fps、GeForce6800Ultraで19.9fps。全Game Test中、最も軽いのがこのテストになっている。これはこのテストで全方位PSMが利用されていないことが大きいのだろう。
 |
 |
| 静止画だと分かりにくいが派手なフリッカーが出る2大シーン。その様子は実際に自分の目で確認して欲しい。2048×2048テクセル程度の解像度のシャドウマップではたとえ屋外シーンに適合したPSM技法とはいえ、限界が感じられる | |
 |
 |
| 水面下を泳ぐ海竜の、水に沈み込んでいる表現は、「深度フォグ(Depth Fog)」なるテクニックを採用していると説明されている。これは水面から見て、水底方向に行けば行くほどフォグを強くしていく(≒透明度を下げていく)処理系なのかと思いきや、こちらも32ビットFP精度の深度情報に配慮しているとのこと。ほんとか? | |
■ いよいよビデオメモリ1GB時代の到来か
3DMark 05のグラフィックスエンジンは影生成関係を除けば、材質表現のシェーダー周りを初めとして、それほど先進的ではなかったように思う。
とはいえ、レンダリング結果への多量のポストプロセス処理、そしてPSM技法の実践や光散乱シミュレーションにおける、膨大な量のビデオメモリへの読み書きのために、「処理の重さ」という観点では、現行の3Dゲームよりも数段上(?)を行なっているのは事実だ。
これを踏まえた上で、逆に、3DMark 05のスコアを上げるためにGPUをどう進化させていけばいいかを考えるとすれば、それは直接的にはビデオメモリ・アクセス速度の向上とビデオメモリバス幅の拡張が近道になると思う。もちろんそれに見合ったGPUコアの処理速度の向上も必要になるわけだが。
そして、3DMark 05は、やたらビデオメモリを贅沢に使用する設計となっており、特に巨大な作業バッファ(シャドウバッファ)を確保する新採用のPSM技法はその代表格だ。この「ビデオメモリを大量に活用する」という傾向は、実際の3Dゲームのエンジンの設計方針にも波及しつつある。
2006年に完成を予定しているUnreal Engine3.0も高解像度のキューブマップをライトマップとして投射する効果を採用しているし、同エンジンのキャラクタのディテール表現用の法線マップは2,048×2,048テクセル解像度が基本になると言う。その意味では、3DMark 05のエンジンのやたらビデオメモリを消費する設計方針自体は、それほど最近の3Dゲームの設計トレンドを逸脱したものではないといえる。
今でこそハイエンドGPUでも256MB止まりだが、ここ1,2年以内にはローエンドで256MB、ハイエンドでは1GBという時代がくることだろう。 その時には、果たして3DMark 05のスコアはいくつをマークするのだろうか。1万を超えるのだろうか。
□Futuremarkのホームページ
http://www.futuremark.com/
□「Deus Ex:Invisible War」の公式ページ
http://www.futuremark.com/products/3DMark 05/
□関連情報
【5月20日】3Dゲームファンのための「Unreal Engine 3」講座 Ver.2.0
2006年以降の3Dグラフィックスはこうなる!
http://game.watch.impress.co.jp/docs/20040520/3due3.htm
(2004年10月22日)
[Reported by トライゼット西川善司]
GAME Watchホームページ |