テクノロジー推進部・リードR&Dエンジニア、岩浩氏中でもコンテンツパイプライン上でのデータのやりとりはボトルネックになりやすく、開発効率に直結します。スクウェア・エニックス オープンカンファレンス2012で11月23日、テクノロジー推進部の岩浩氏は、「ランタイム＆パイプラインの構築と最適化」と題して、この問題をどのように解決したか、講演しました。
『Agni's Philosophy』コアメンバーの面々■プロジェクト中盤で顕在化し、一気にあふれ出した
プリレンダーCGとリアルタイムCGの違いの一つは、そのデータ量にあります。『Agni's Philosophy』でも、無数の虫が骨にむらがって召喚獣を生み出すシーンでは、頂点数が500万、テクスチャサイズが1GBにものぼりました。リアルタイムCGの標準を遙かに凌駕していることがわかるでしょう。
これらのデータはビジュアルワークス部からテクノロジー推進部に渡され、『Agni's Philosophy』のランタイム上で再生されましたが、データの一部をコンバートする必要がありました。ポストエフェクトのパラメータを調整など、ルミナススタジオLuminous Studioのカットシーンエディタ上で作業をする必要が、一部の素材で発生したからです。Mayaのシーンデータを一度、FBX形式に変換し、さらにルミナス用データに変換して読み込まれました。
しかし、ここで大問題が発生しました。Mayaのデータを開いたり、MayaからFBXデータにエクスポートするのに、尋常ではない時間が必要になったのです。先ほどの召喚獣のシーンでは、Mayaでデータを開くのに6分、FBX形式にエクスポートするのに45分、FBXからルミナス用データにコンバートするのに、なんと1時間半（読み込みに50分、コンバートに40分）もかかってしまったのでした。
しかも、これらの問題がプロジェクトの終盤になって顕在化したのです。ビジュアルワークスからシーンデータが量産され、テクノロジー推進部にどんどん送り込まれるに従って、ワークフローで交通渋滞が発生。作業効率が指数関数的に悪化し、一時は完成さえ危ぶまれました。何とかなるだろうと思っていたが、何ともならなかったのです。
■最適化・最適化・最適化・・・
そこで岩氏がボトルネック解消に乗り出しました。まずMayaデータを開くときに、いちいちShaderのビルドが走っていたため、バイナリデータの再利用を行いました。またライトなど頻繁に調整するパラメータは、Mayaデータをライトとシーンのデータに分割。Maya側でライトのファイルを開き、カットシーンエディタ側でシーン全体のデータを開いて、ライブエディットで結果がわかるようにしました。
次にFBXファイルからルミナス用データへのエクスポート問題については、同一シーン内のMayaファイルをエディット単位で分割し、ランタイム側で再統合するように工夫しました。もっともシーン全体のエクスポートに時間がかかるという問題は残ったままでしたが、複数PCで分散するという力業で乗り切りました。中には4台のPCで4時間以上かかるシーンもあったといいます。
またデータの再配布でも問題が生じていました。バージョン管理ツールのPerforceが一時期、非常に重くなったのです。PerforceのMetaDataをNFS上においていたことが原因で、サーバのローカルストレージに移動したら快適になりましたが、それでも完全な解決には至りませんでした。Perforceのノウハウがチーム内で不足していたのが原因です。また中には一晩たってもアップが終わらず、管理を諦めたものもありました。
■ポイントはDrawCall数削減
パイプラインに続いて問題となったのが、実行環境下での最適化です。『Agni's Philosophy』は市販のハイエンドPCで実行されるコンテンツとなっています。つまり、どんなにリッチなコンテンツでも、処理負荷が重すぎて満足に実行できなければ、意味がなくなるのです。マシンスペックはCPUがCore i7-3770K 3.5GHz、メインメモリが32GB、GPUがGeforce GTX 680（1枚）となっています。
このうち、実際にCPUやメモリには余裕があり、GPUの処理能力だけが問題になりました。中でも処理負荷がかかったのが半透明（Opaque）で、冒頭のシーンでは9042マイクロ秒と圧倒的でした。
これに対して、効果が最も高かったのがDrawCall（描画命令）の削減です。冒頭シーンで3375回もあったDrawCallを、同じマテリアルのものをまとめて描画するなどして最適化した結果、452回にまで削減することに成功。これにより40％くらい高速化することに成功しました。他に▽頂点サイズを小さくする▽インデックスの並びの最適化▽Pre Skining−−などの最適化も行われています。
一方でシェーダーやアセットの最適化は行われませんでした。特にアセットについては、プリレンダー用のCGデータを流用したため、一見すると無駄が多すぎるように思われました。しかし実際には頂点数を減らしても、ほとんど効果がないことが判明。地形データなどの静的なものに限れば、実行時に頂点数が問題にならないレベルにまで、ハードウェアが進化してきました。
同様にレベルオブディティールやオクルージョンカリング、最適化目的でのテッセレーションなども行われませんでした。というのも、DrawCall削減をはじめとした最適化だけで、目標をクリアしてしまったからです。CPUに対して、多少無駄に計算させても、ストール（処理待ち）をさせるよりはまし。むしろ今後はメモリ使用量やストリーミング、作業効率の方が問題になるのではないか、と岩氏は語ります。
■ゲームエンジンの威力を再確認
プロジェクトを振り返って、岩氏はワークフローではデータサイズ対策、実行環境ではGPUのストール問題が大きなポイントだったと指摘。またエクスポートの時間短縮については、エクスポートの範囲を指定したり、再エクスポートしない、などの対策も必要だと言います。
ともあれ、開発終盤になって顕在化したこれらの問題は、岩氏の手によって、手遅れにならないうちに解決。開発効率の劇的な向上に大きく貢献しました。
本作のお披露目は6月5日のE3イベントと早期の段階で決定されており、動かすことはできませんでした。一方で次第に増え続ける物量が現場をむしばみ、ゴールデンウィークの頃は押しつぶされそうになっていました。これが最適化の結果、最後の2週間でクオリティアップに大きく貢献。プロジェクトを主導した橋本善久氏は「開発環境の有無が1000倍以上の違いを有む」として、開発チーム全体がゲームエンジンの威力を再確認したと締めくくりました。
【関連記事】
まるでゲームAIの大統一理論／次世代ゲームAIのアーキテクチャとは？
リーダーは泥まみれになる覚悟をもて！橋本善久氏のプロマネ講座
失墜した信頼は取り戻せるか？『FFXIV』吉田直樹プロデューサーが講演
スクエニ、開発者向け「オープンカンファレンス2012」を11月23日・24日開催
