オススメ機能
Twitter
お気に入り
記事履歴
ランキング
4Gamer.net
お気に入りタイトル/ワード

タイトル/ワード名(記事数)

最近記事を読んだタイトル/ワード

タイトル/ワード名(記事数)

LINEで4Gamerアカウントを登録
QRコードでLINEの4Gamer
アカウントを友達登録すると
月〜金の週5回,21時に厳選
ニュースをお届けします!
※購読にはLINEアプリが必要です
カプコン独自のゲームエンジン「Panta Rhei」と「deep down」の技術的詳細に迫るCEDECセッションレポート
特集記事一覧
注目のレビュー
注目のムービー
印刷2014/09/27 00:00

イベント

カプコン独自のゲームエンジン「Panta Rhei」と「deep down」の技術的詳細に迫るCEDECセッションレポート

 2014年9月2日,日本最大のゲーム開発者会議「CEDEC 2014」で,カプコンは「『deep down』のグラフィックス表現の技術解説」と題した講演を行った。本稿では,カプコン三嶋 仁氏阿久澤陽菜氏によって行われた講演の概要を紹介していきたい。

 なお,この講演は,CEDEC 2014開幕時には取材NGに指定されていたのだが,CEDEC事務局側の誤解があったためと判明し,結果的には記事化がOKとなった。本稿は,カプコン側の了承を経たうえで記事化をしていることをあらかじめお断りしておく。

三嶋 仁氏(カプコン 技術開発室 プログラマ)
阿久澤陽菜氏(カプコン 技術開発室 プログラマ)


Panta Rhei,そしてdeep downとは


 カプコンは日本でも比較的早くからゲームエンジンの重要性に着目し,独自技術の蓄積とオリジナルエンジンの開発に取り組んできたゲーム会社である。PlayStation 3&Xbox 360時代にはMT Frameworkというカプコンのゲーム開発スタイルに適した独自エンジンを開発し,最終的にはWii,PS Vita,ニンテンドー3DSにまで対応範囲を拡大している。当初は,カプコン内製プロジェクト専用の位置づけだったが,優れた開発効率パフォーマンスが高く評価され,外注先スタジオでのプロジェクトにも使用されるようになっていた。
 続いてカプコンはPlayStation 4&Xbox One時代に向けた新エンジン開発プロジェクトを2011年頃よりスタートさせている。大方の予想に反して,MT Frameworkの新バージョンではなく,名前を「Panta Rhei」(パンタ レイ:万物流転の意)と一新のうえ,完全に新規開発エンジンとして2013年に発表し,業界を驚かせたのであった。

 MT Frameworkからアーキテクチャを一新させたPanta Rheiエンジンは,コンテンツ開発パイプラインにも大なたが振るわれたため,MT Frameworkとの互換性がなくなったとされている。カプコンはPanta Rheiで開発スタイルを一気にジャンプアップさせるつもりなのだろう。
 そんな「次世代ゲームエンジン」とも呼ぶに相応しいPanta Rheiベースの処女作として進められているのが,アクションRPG「deep down」である。

ミドルウェア/開発ツール ミドルウェア/開発ツール
deep downの開発中スクリーンショット
ミドルウェア/開発ツール


Panta Rheiの物理ベースレンダリングエンジン


 Panta Rheiは,物理ベースレンダリング(Physically Based Rendering,以下PBR)を採用している。
 PBRとは,さまざまな材質(マテリアル)表現に際して,入射した光と,その材質で反射して出てきた出射光,吸収された光などのエネルギー総和が等しくなる「エネルギー保存の法則」に則ったレンダリング手法である。材質表現には,入射した光がどの方向にどれくらい拡散しているかを示すBRDF(Bidirectional Reflectance Distribution Function,双方向反射率分布関数)が用いられることが多い。

 Panta Rheiでは「材質表現の質感の高品位化と品質の統一化」のためにPBRを採用したと,三嶋氏は説明している。MT Framework時代には,材質表現に環境マップを組み合わせたものがあったりするなど,「特定シーンでしか利用できない職人芸的な技」が目立っていたため,Panta Rheiでは誰が制作しても一定の品質が得られ,しかもあらゆるシーンにおいて使える堅牢な材質システムを構築するためにPBRが採用されたようだ。
 こうしたコンセプトは,カプコン特有のものではなく,PS4&Xbox One世代におけるゲームグラフィックス設計思想の共通理念となりつつあるものである。

 さて,その具体的なシェーディングモデルだが,Panta Rheiでは,拡散反射項に「Oren-Nayar法」を採用し,鏡面反射項に「GGX(Cook-Torrance)法」を採用しているという。三嶋氏によれば,昨年の東京ゲームショウ出展時点では鏡面反射項には正規化した「Blinn-Phong法」を採用していたが,のちにGGX法に置き換えたとのことだった。

 Oren-Nayar法は,拡散反射項のシェーディング手法としては比較的演算負荷が高いモデルで,その代わり視線依存のハイライトが乗るという特徴があり,粘土のような材質の再現にも対応できるとされる。
 GGX法では,ハイライトの出方がシンプルなグラデーションにならず,中心角付近が鋭く,そこからなだらかに減衰していくという特徴がある。表現対象によっては,Blinn-Phong法よりリアルになるとされ,今世代のゲームグラフィックスでは採用事例が増えつつあるようだ。
 ただ,別にBlinn-Phong法が劣っているということでもなく,実際「Forza Motorsport 5」の物理ベースレンダリングエンジンではBlinn-Phong法が採用されていたりもする。

GGXとBlinn-Phongの質感の違い。ハイライトの出方に大きな違いがある
ミドルウェア/開発ツール

 人肌などのシェーディングについては,拡散反射項に「Pre-integrated Skin Shading」法(参考URL),鏡面反射項にGGXを採用しているとのこと。
 Pre-integrated Skin Shading法とは,人肌に入射した光が「どの範囲」に「どんな色の分布」で出射するかというプロファイルに基づいてシェーディングを行うものだ。この方法では,計算負荷を低減するために,そのプロファイルについては,法線,光源ベクトル,曲率(丸み)のすべての組み合わせに対応する計算結果を事前にデータテーブル化して持つのが一般的だ。曲率に関してもその都度計算していると重いので,各部位の曲率分布を3Dモデルごとに事前計算してテクスチャなどとして持たせることが多い。
 しかし,Panta Rheiでは,3Dモデルの曲率を事前計算で持たせるのではなく,アーティストがシェーダにパラメータとして与える仕組みにしたとのこと。ここは,見映えのコントロールを細かく設定できる日本流らしい実装と言えるのかもしれない。

Pre-integrated Skin Shading法。このテクニックは「BATTLEFIELD3」でも採用されていた。図中の右は,Skin Diffusion Mapと呼ばれる
ミドルウェア/開発ツール


 Panta RheiにおけるPBRの材質再現パラメータは以下のようになっている。

Panta Rheiの材質パラメータ群
ミドルウェア/開発ツール

 物理ベースレンダリングエンジンとしては模範的なパラメータラインナップといえ,他社の物理ベースレンダリング採用エンジンとの共通点も多い。今世代のゲームグラフィックスはこうしたパラメータ構成が主流となっていくのだろう。
 なお,「Glossiness」は,シリコンスタジオの「Mizuchi」でいうところの「Shininess」に相当するもので,一般的なPBRで使われるRoughnessの補数に相当する。
 自発光成分を表す「Emissive」というのは少々特徴的なものだ。反射光(BRDF)以外に透過や自発光による放射光を考慮することで,レンダリング方程式は完成するが,自発光は多くのシステムで省略されることが多い項目である。蛍光などの表現で活用されるものと思われる。

 三嶋氏によれば,Panta Rheiでは,人間のような有機体についてはAlbedo(拡散反射率)にのみ色を付けてReflectance(鏡面反射率=光沢反射率)には色を付けない仕組みとし,一方で,金属物質ではAlbedoには色を付けず,Reflectanceに色を付けるようにしているという。現実世界の材質でたとえると,人間の肌に光を当てると,光沢のハイライトはその光源色になる。一方,金(Gold)は,何色の光を当てても,黄色に寄った光沢が出る。こうした特性をPanta Rheiでも実装しているのだ。
 実のところ,これは理に適った実装で,Unreal Engine 4をはじめとした多くのグラフィックスエンジンで似たような仕組みを採用している。

 なお,Panta Rheiでは,「Reflectanceが高ければ高いほど,その分強制的にAlbedoの支配率が弱まる」ような調整を入れてあるという。このほうが材質感が現実世界のものに近くなるようだ。

 ところで,この新材質システムの採用によって,材質設計のパイプラインが一新されたために,deep down開発チームのアーティスト達が戸惑う場面があったという。これについては,Panta Rhei上で表示される質感をリアルタイムに確認しながら作業できる仕組みを「3D-Coat」や「Maya」上で構築して対応したとのことだ。

MT FrameworkとPanta Rheiとの違い
ミドルウェア/開発ツール
 三嶋氏はPanta Rheiおけるシェーダ制作についても言及した。
 MT Frameworkでは,アーティストは,プログラマが制作したシェーダパーツを組み合わせたり,パラメータチューニングしたりするようなスタイルで作業していたが,Panta Rheiでは,自前でゼロからシェーダを制作できる仕組みを採用したとのことだ。制作したものは即座にコンパイルして,プレビュー画面で陰影の出方などを確認できる仕組みになっている。

実際にアーティストが制作したシェーダの例
ミドルウェア/開発ツール
ミドルウェア/開発ツール
シェーダはノードをリンクでつなぐ方式
ミドルウェア/開発ツール
制作したシェーダは即座にプレビュー可能

 下の映像は,実際にアーティストが制作した水のモンスターのシェーダ例だという。アーティストは,この3Dモデル上の各頂点を流れるように揺らす表現を自作したそうで,MT Framework時代ならばプログラマが制作しなければならなかったような表現も,Panta Rheiのシェーダ制作システムであれば,アーティストが作れるようになったというわけだ。


 このアーティスト用のシェーダ制作システムでは,画面座標系で行うポストエフェクトのようなシェーダも制作可能で,その実例が下の映像になる。プレイヤーの位置から遠方に向かって発光しながらゲーム世界が描かれていく表現が見てとれるだろう。
 これは,背景の深度値をキーにして背景と交叉するこのエフェクト用の3Dテクスチャを読み出し,3Dモデルに対してこのエフェクトを適用しながらを表示していくことで実現されている。
 「とても重いエフェクトなので,常に出すことはできないが,こうした,ワンポイントエフェクト的な活用であれば許容できるものだったのでdeep down本編でも採用されている」とのことであった。アーティストが,こうしたポストエフェクト表現まで制作できるというのはとてもユニークである。


 三嶋氏は,Panta Rheiで,複数の材質を3Dモデル上のどこに割り当てるかの設定をレイヤーマスクで与える仕組みについても紹介した。
 例えば,衣服や鎧における部位ごとの材質の違い,鎧の金属材質の傷から見える錆のような異なる質感のディテール表現はこのシステムによって再現される。


このレイヤーマスクの仕組みはカプコン内部では「Detail Layer」と呼ばれているという
ミドルウェア/開発ツール

 三嶋氏は,ここまでのまとめとして,アーティストがゲーム本編の細部表現からキー表現に至るまでのシェーダ設計が行えるようになったPanta Rheiの特徴に対し,利点と課題を挙げた。

 利点はアーティストが自身の目で確認しながら効率よく制作できるところ。試行錯誤がスピーディに行え,実機と同様の表現を制作画面で確認できることはアーティストから高い評価を得たと自負しているようだ。
 課題として挙げられていたのは,アーティストが高い自由度でどんなものでも作れてしまう結果,表現を追い求めすぎると,とても高負荷なものができてしまうことだという。最終的にゲーム機実機に載せたときにどの程度重くなるのかは,アーティストには予見できない部分もあるので仕方がないことではある。

ミドルウェア/開発ツール
新シェーダ制作システムの利点と課題


deep downのレンダリングパイプライン


 続いて三嶋氏はdeep downにおけるライティング技術やレンダリングパイプラインについての解説を行った。

ミドルウェア/開発ツール
deep downのレンダリングパイプライン
ミドルウェア/開発ツール
deep downのテクスチャ仕様。基本的には新世代テクスチャ圧縮のBC4以上が使われているが,一部,省メモリ目的でS3TC方式の「BC1」(DXT1)が採用されているほか,1チャネルテクスチャはBC4,法線マップなどはBC7,HDRテクスチャ圧縮にBC6Hを使用しているとのこと

 deep downはプロシージャル生成されるダンジョンでの冒険がテーマであるため,アーティストがデザインしたマップではなく,ゲーム世界自体が自動生成されるシステムを採用している。そのため,事前計算でライトマップテクスチャを適用しておくことができない。基本的に,すべてのライティングが動的かつリアルタイムで行われることとなった。

ミドルウェア/開発ツール
ライティングはすべてランタイムで,かつリアルタイムに行われる
ミドルウェア/開発ツール
deep downではSF的な設定パートもあり,そのような近未来シーンの制作ではライトマップも使われたとのことである

 レンダリングメソッドはタイルベースの「Deferred Rendering」(ディファードレンダリング)を基本とし,半透明オブジェクトや前出の皮膚材質などでは特例的に「Forward Rendering」(フォワードレンダリング)が用いられる。
 タイルベースDeferred Renderingとは,画面を適当なタイルに区切って,Deferred Renderingを行う手法だ。なお,Imagination TechnologiesのPowerVRがハードウェアで行う技術も同名だが,それとは違うものなので注意したい。

 さて,なぜわざわざタイルに区切って行うのだろうか。
 Deferred Renderingは,動的光源を無数に置けることがメリットだが,画面上の全ピクセルに対して,シーン内に置かれた動的光源の影響下にあるか/ないかをいちいち判断しながらシェーディングするのは冗長なので「どの光源が画面内のどのタイルに影響しているのか」を事前に調べて対応リストを作ってしまえというのが,タイルベースDeferred Renderingの基本発想なのである。
 deep downで行われているのは,画面(視界内)を16×16に分割するタイルベースDeferred Renderingだが,視点から奥行き方向に向かって32個の空間にも分割する実装スタイルなので,いわば「立体的なタイル分割Deferred Rendering」となっている。あえて言えば,レイトレーシングでのVoxel分割や,Chalmers University of TechnologyのOla Olsson氏らが発表した「Clustered Deferred Shading」(参考URL)のテクニックに近いといえるのかもしれない。

deep downのタイルベースDeferred Renderingでは,立体的なタイルを作成して有効光源リストを作成する
ミドルウェア/開発ツール

 三嶋氏はセッションで,この立体的なタイルによる有効光源リストの作成アルゴリズムについて詳細に解説した。この説明を図示したのが下の動画だ。
 見ると,立体タイルを奥行き方向に1,2,3,……32と分割したとして,各光源がどの立体タイルに掛かってくるかを判定し,タイルに掛かった「光源番号」と,何番目の立体タイルに掛かったかに対応するビット値を「1」として記録するメカニズムとなっていることが分かる。なお,この処理は「Compute Shader」(GPGPU)で行われているとのこと。


 実際のシェーディング処理もピクセルシェーダではなくCompute Shaderで行われるという。16×16の各タイルに対して並列実行し,有効光源リストから有効な光源を取得しつつ,シェーディングを行っている。
 なお,並列実行効率を上げるために,点光源,平行光源,スポットライトなど,光源の種類ごとに分けて処理しているという。当初は1ループですべての種類の光源を処理できるようなプログラム構成としていたが,光源種別ごとにループを分けたほうがGPUコアでの並列実行率が上がり,パフォーマンスが向上したとのことだった。

シェーディングはCompute Shaderで計算
ミドルウェア/開発ツール

 特例的な材質,具体的には皮膚のような半透明体を処理する際には,前述したようにForward Renderingを実行する。Panta Rhei以外のDeferred Renderingベースのレンダリングエンジンでも,特殊材質のためにForward Renderingパスを組み込むことはよくあることである。
 ところで,立体タイルを作って立体的な有効光源リストを作っていたのは,この特例材質のForward Renderingのためでもあり,これにより,特例材質のシェーディングを有効な光源だけを用いて行うことができる。有効光源リストを前段で作成してからForward Renderingを行うというコンセプトは,AMDの提案した「Forward+ Rendering」(参考URL)のアーキテクチャを部分的に取り入れているといってもいいかもしれない。

特例材質のレンダリングにはForward Renderingを採用
ミドルウェア/開発ツール

 画像本体のレンダーターゲットには,各チャネル16bit浮動小数点数(FP16)の64bitバッファが採用され,ガンマ補正なしのリニア空間でのレンダリングが行われる(もちろん,ディスプレイやテレビに表示するためにトーンマッピングを行った場合はガンマ空間に圧縮される)。
 一方,Deferred Renderingでは,最初に,ライティングやシェーディングに必要な中間パラメータを「G-Buffer」と呼ばれるバッファにレンダリングするが,deep downでは,以下のような仕様となっている。

レンダーターゲットはFP16。レンダリングメソッドはPS4&Xbox One世代で採用事例の多い方式で,モダンな主流技法といえる
ミドルウェア/開発ツール
G-Bufferの仕様
ミドルウェア/開発ツール

 およそ,材質システムで解説されたものが書き出されている感じだが,いくつか特徴的なものがある。
 三嶋氏が時間をとって解説したのは,拡散反射項のAlbedoと,鏡面反射項のReflectanceについてだった。deep downではG-Bufferへの書き出しデータ量削減のため,テレビやビデオ映像の伝送方式である色差表現のYCbCr方式を採用している。つまり,輝度値のYはフル解像度で記録されるが,色信号の色差信号はピクセルラインの偶数ラインと奇数ラインとで青色差(Cb)と赤色差(Cr)を交互に記録する方式にしたというのだ。
 このフォーマットはビデオ用語でいうところのYCbCr=4:2:0方式に相当し,Blu-rayソフトや地上波デジタル放送などと同じフォーマットになる。色解像度を落とすのは人間の視覚メカニズムが輝度解像度のほうに敏感で,色情報には鈍感なためだが,ゲームグラフィックスでこの方式をとるのはなかなかユニークだ。

 これでデータ量の削減はできたが,HDRレンダリングで高輝度値になった場合などに黒に近い暗色が正しく表現されない「偽色」問題に直面したそうだ。
 三嶋氏の分析では,偽色の発生は「量子化誤差が正しく吸収できていないためかもしれない」とのこと。deep downでは,Albedoを「RGB(材質入力)→YCbCr(G-Buffer)→RGB(Deferred Renderingから復元したAlbedo)という変換プロセス出力しており,最後のRGB各8bit出力のところで精度不足が起きているのではないか,と考えているようだ。
 この偽色現象を回避するため,最終的には,材質やテクスチャ側の色を調整したり,色のエンコード部分に手を入れたりして対処したとのことだが,三嶋氏は「適切な四捨五入の導入などにより演算精度を改善することでも低減できるのではないか」とも述べていた。
 三嶋氏は「普通にRGBを使ったほうがよかったかもしれない」と冗談ぽく振り返り,笑いを取っていた。「RGBを使いつつG-Bufferのデータ量削減を図るならば『Metallic』の考えを採用したほうがいいかもしれない」とも述べていたが,このMetallicというキーワードに対しては少々補足解説が必要かもしれない。
 Metallicの考え方は,Unreal Engine 4やMizuchiでも導入されているもので,鏡面反射項の色味については金属度(Metallic度)パラメータの高さに応じてベースカラーの色を拝借してくるというものになる。

 そのほかのG-Bufferの内容を見てみると,PreLightingでのR,G,Bは,マグマやクリスタルなどの自発光表現のためのパラメータで,ライトマップが使われる一部のシーンではライトマップの値とAlbedoの値を乗算した値が格納される。
 また,Optionsの部分には,デカールテクスチャや前出の皮膚材質などの特例処理のための情報が書き出されている。Reflectivityには反射率が入れられており,ここがゼロだとライティングがオフになる特例処理にしているとのこと。

 直接光ライティングに用いられる光源は,古典的な点光源だけではなく,大きさを持ったいわゆる面光源も利用できるようになっている。ここも新世代ゲームグラフィックスの新基準を採用したといえる部分だ。現状は球型の面光源のみの対応ながら,強さ,大きさがカスタマイズ可能で,物理法則に従った距離の二乗減衰をサポートする。

球型の面光源をサポート。ちなみに,ほかのエンジンでは球型に加え,カプセル型や四辺形型の面光源をサポートするものも出てきている
ミドルウェア/開発ツール
光源の大きさによってハイライトの出方も変わる。この面光源の導入も,実は新世代ゲームグラフィックスの特徴の一つである
ミドルウェア/開発ツール


deep downの間接照明


 間接照明(大局照明)については,「Irradiance Volume」(以下,放射輝度ボリューム)と「Parallax Corrected CubeMaps」(以下,視差補正環境マップ),「Screen Space Reflection」(Realtime Local Reflection)が採用されている。
 間接照明での拡散反射項に関しては,優先順位が高い順に「放射輝度ボリューム」「視差補正環境マップ」「通常の環境マップ」(視差補正なしの無限遠扱いの環境マップ),「あればそれを使う」という実装のアルゴリズムとなっている。
 鏡面反射も同様に,優先順位が高い順に「Screen Space Reflection」「視差補正環境マップ」「通常の環境マップ」で「あればそれを使う」という仕組みだ。

deep downにおける間接照明の要素採用優先順位
ミドルウェア/開発ツール

 放射輝度ボリューム(参考URL)は,Valveの「Half-Life 2」時代から実用化されている古典的な間接照明テクニックで,シーンを立方体で区切り,その立方体の頂点単位での全方位の照明情報を事前計算で取得しておき,ランタイムではその全方位の照明情報をシェーディングに利用するというものだ。
 deep downでは,ゲームマップが動的生成されるので,放射輝度ボリュームをゲーム制作時に計算しておくことができない。そこでマップ生成時にランタイムでこの放射輝度ボリュームを計算することになる。

 その手順だが,まずシーンを256×256×256の固定Voxelで分割し,ゲーム世界を直接光だけでレンダリングする。そのレンダリング結果からカラー情報とオクルージョン情報をリスト化して対応するVoxelに注入し,別途用意した128×128×128の放射輝度ボリューム観測点(プローブ)の各点から全天周12方向に対する「Voxel Cone Tracing」(ボクセルコーントレーシング)を実行する。Cone Tracingの対象とするVoxelは,もちろん前出の256×256×256のものだ。

 ちなみにCone Tracingについての詳細はこちらを参照してほしいのだが,簡単に解説すると,これはレイトレーシングの一種である。レイトレーシンクで放たれるレイは光“線”なので,照明情報(ライティング結果)の回収範囲が狭い。それに対して,Cone Tracingでは円錐(Cone)を使う。進むごとに光が広がるので,広範囲の照明情報を取ってくることができる。光線よりは大ざっぱになるが「拡散反射項の間接照明に利用する照明情報は大ざっぱでも実害はない」という判断でこうした手段を使うのだ。

 こうしてできあがった放射輝度ボリュームは128×128×128の3Dテクスチャ3セットに格納される。記録形式は互いに直交する4方向の色情報として記録しているとのこと。その形式を採用した理由については,「データ利用と品質のバランスが良かったため」と三嶋氏は説明している。

シーンをまず256×256×256でVoxel化して,各Voxelに対して直接光ライティングの結果を注入
ミドルウェア/開発ツール
そのVoxel情報を用いて128×128×128のプローブ地点で全天周12方向に対するコーントレーシングを実行して放射輝度ボリュームを作成
ミドルウェア/開発ツール
ミドルウェア/開発ツール
直接照明のみ(上)と放射輝度ボリュームによる間接照明効果を加えた結果(下)の対比。中距離付近の明るさに違いが見て取れる
ミドルウェア/開発ツール

 Screen Space Reflectionは,画面座標系で局所的なレイトレーシングを行って,比較的鮮明で正確な鏡像を出すテクニックで,Crytekによって発明され,一気に業界内で浸透した。deep downでは,水面などの完全な鏡面反射に近い部分にだけ用いられている。


deep downにおけるScreen Space Reflectionは,水面などの鏡面に近い部分で使われる
ミドルウェア/開発ツール

 視差補正環境マップも,最近では必須レベルで採用事例が多いテクニックだ。
 視差補正環境マップとは,ある地点で事前に作成しておいた環境マップを各オブジェクトに適用するときに,これから描画するオブジェクトの位置から見たときの映り込み表現として不自然に見えないように補正して環境マッピングするテクニックである。
 キューブ環境マップを光源的に取り扱う「Image Based Lighting」(イメージベースドライティング,以下,IBL)では必須のテクニックで,広めたのは現EA DICEのシニアレンダリングプログラマであるSebastien Lagarde氏だ(参考URL)。

 deep downでは,放射輝度ボリュームやScreen Space Reflectionが適用されない部分での拡散反射項と鏡面反射項の双方で視差補正環境マップを使用している。
 もともとdeep downでは,1シーン中に96個の環境マップが置けるように設計されており,その解像度は128×128テクセルだ。MIP-MAPによって64×64,32×32,……2×2テクセルの縮小版までを持つ。
 高解像度版から低解像度版までを生成しておく理由は,表現する材質の面の粗さ(G-BufferのRoughness)に応じて適当なものを採用できるようにするためで,綺麗な鏡像が出るツルツルの材質では高解像度版を使い,鈍い光沢感になるザラザラした材質では低解像度のものを使うイメージだ。

ミドルウェア/開発ツール
直接照明のみ(上)と視差補正環境マップによる間接照明効果を加えた結果(下)の対比。金属の質感に大きく貢献しているのが見て取れる
ミドルウェア/開発ツール
環境マップをMIP-MAPで持つのはIBLでは定番の方式だ
ミドルウェア/開発ツール
放射輝度ボリュームの生成と同様に,環境マップもゲームマップ生成時に行われる。ここでもCompute Shaderが活用されている
ミドルウェア/開発ツール


deep downの影生成


 deep downでは影生成法としてシャドウマップ(デプスシャドウ)技法を採用している。全方位に光を放つ点光源では6方向キューブマップのシャドウマップを生成し,スポットライトでは1方向のシャドウマップを生成する。
 一方,平行光源のようにシーンの広範囲に影生成が及ぶ場合は,近景から遠景までに,3枚のシャドウマップを割り当てて影を生成する3カスケードシャドウマップを生成している。
 ソフトシャドウ用のフィルタには,カスケードシャドウマップのみ「Poisson Disk Sampling」(ポワソン・ディスク・サンプリング)法,それ以外については「Percentage-Closer Filter」(パーセンテージ・クローザー・フィルタ,PCF)法を適用しているとのこと。

左のスクリーンショットが,実際のシャドウマップの内容となる。影生成用のシャドウマップは巨大なものを1枚確保し,そこに書き出すような仕様になっている
ミドルウェア/開発ツール

 三嶋氏によれば,オブシェクト全部に対してまじめに影生成するとかなりの高負荷になるため,なんらかの最適化方策を模索することになったという。
 deep downでは,ゲーム中,それほど光源が動かないことに着目し,動かないことが分かりきっている静的オブジェクトの影は専用一時バッファに書き出して保存しておき,これを影生成用シャドウマップにコピーしてから動的オブジェクトの影生成を行う仕組みを導入したという。静的オブジェクトのシャドウマップレンダリングが事実上,一時バッファからのコピーだけで済むようになり,高速化が図られたのであった。
 もちろん,光源の増減のような変化が起きたときには,静的オブジェクトのシャドウマップ生成をやり直し,念のため,フレームごとに1個の光源について,一時バッファへの影生成をやり直しているとのこと。

シャドウマップ作成に対する最適化処理
ミドルウェア/開発ツール


deep downにおける体毛表現


 最後に,阿久澤氏によって,deep downに登場するモンスターの体毛表現についての解説が行われた。


 体毛表現は,当初,毛の断面図を積層させてレンダリングするシェル法や,ポリゴン片の毛を植え込むフィン法(バナナリーフ法とも)などが検討されたが,シェル法は視線が積層した毛をかすめて見たときに分断して見えてしまうこと,フィン法は毛ポリゴンの植え込みが大変だということで見送られたという。
 結局,DirectX 11世代GPUの特徴的な機能であるテッセレーションステージを活用し,ポリゴンでできた線分を生やす方法を採用した。毛髪をテッセレーションステージを活用して実装した例としてはスクウェア・エニックスの「Agni's Philosophy」(参考URL)がある。

 deep downでは,アーティストがモンスターをモデリングするときに,「どこに」「どれくらいの密度で」「どれくらいの長さの」毛を生やすかを設定できるようになっており,モデリング段階では実際には毛を植えない。
 その代わり,ランタイムにモンスターが読み込まれたときに,「モンスターの表皮上の毛の発生源」の座標をCompute Shaderで計算して生成し,レンダリング時にはこの発生源からテッセレータを用いて,ポリゴン(実際にはクワッドとのこと)で構成される線分(ポリライン)の毛を生やしている。

テッセレーションステージを活用して,線分としての体毛を生やす手法を採用している
ミドルウェア/開発ツール
毛髪の発生源はモンスターの3Dモデルを構成しているポリゴン単位で行われる
ミドルウェア/開発ツール
モンスターがアニメーションして姿勢を変化させたり部位を曲げたりすれば毛髪の発生源はそれに伴って移動する
ミドルウェア/開発ツール
毛髪は半透明オブジェクトなので,描画順にシビアな材質だ。したがって,後ろから前にソートを行ってからレンダリングを行うことになる
ミドルウェア/開発ツール
テッセレーションステージでポリラインベースの毛髪をソート順に描画する
ミドルウェア/開発ツール

 実際のライティングだが,毛髪は半透明オブジェクトとしているため,毛髪同士の重なりによるカリングは行われない。そのため,この手法による毛髪をピクセルシェーダでシェーディングしようとすると,毛髪を構成するピクセルにおいて重複的にピクセルシェーダが走ることになる。これが比較的大きなパフォーマンスインパクトになっていることに気がついた阿久澤氏は,テッセレーションステージのドメインシェーダでライティングを行う方針を選択したという。

 頂点シェーダによるライティングでは粗すぎ,ピクセルシェーダによるライティングでは負荷が高すぎるという場合にしばしば用いられるのが,テッセレータによって細分化されたポリゴンに対する各種処理を受け持つドメインシェーダによるライティングだ。
 この最適化の導入で,ハイライトの出方の解像感は下がったものの,パフォーマンスは向上したため,これを最終仕様として採用したとのことである。

ライティング高速化のため,ピクセルシェーダによるライティングをやめて,ドメインシェーダによるライティングに切り換えた
ミドルウェア/開発ツール
ピクセルシェーダによるライティングとドメインシェーダによるライティングの対比。ハイライトの出方に違いは見受けられるが,パッと見た感じで品質の優劣は付けがたい。アーティスト達からはむしろドメインシェーダ版の柔らかい陰影のほうが好評だったとか
ミドルウェア/開発ツール

 これでフサフサした毛足の長い毛を1本1本植えることができた。よりリアルに見せようと,阿久澤氏はモンスターの体の動きに合わせて毛を動かすことを考えたという。
 それっぽく見えれば十分ということで,阿久澤氏は簡易的なシミュレーションの実装に取り組むことにした。毛髪の生成元である3Dモデル上の各点の座標が,前フレーム時の位置座標から現在フレーム時の位置座標までどのくらい移動したかを単純な差分で計算し,これを仮想的な速度としてみなすこととしたのだ。
 ここで算出された速度を考慮し,テッセレーションステージで生成した毛髪に対してドメインシェーダで毛の位置座標を更新する。すると,毛は体の動きに翻弄されるような三次元的な動きを見せるようになり,見映えが驚くほど向上したとのことだった。


 いかがだったろうか。
 deep downは,カプコンが誇る新世代ゲームエンジンPanta Rheiを,かなり効果的に活用しているように思える。また,最近,徐々に分かってきた,日本の他社製エンジン,海外のゲームエンジンなどが採用してきている今世代ゲームグラフィックスのトレンドをかなり研究し,カプコンとして使いやすいように改良,改善して吸収しているということも伝わってくる。
 そんなPanta Rhei採用第一タイトルのdeep downの正式リリースが楽しみなのはもちろんだが,バイオハザードシリーズをはじめとしたカプコンの看板タイトル達がPanta Rheiベースになって登場する未来も待ち遠しいものである。

「deep down」公式サイト

  • 関連タイトル:

    ミドルウェア/開発ツール

  • 関連タイトル:

    deep down

  • この記事のURL:
line
4Gamer.net最新情報
トピックス
スペシャルコンテンツ
注目記事ランキング
集計:06月27日〜06月28日
タイトル評価ランキング
88
82
ARMS (Nintendo Switch)
82
NieR:Automata (PS4)
75
鉄拳7 (PS4)
2016年12月〜2017年06月