［GTMF 2012］「GRAVITY DAZE」開発スタッフが語る，アートコンセプトをPS Vita上で実現した手法の実際

GRAVITY DAZEのメインビジュアル。2012 Into the Pixel Collectionを受賞している

　2012年7月4日，都内で開催された「Game Tools ＆ Middleware Forum 2012」において，ソニー・コンピュータエンタテインメント Worldwide Studios JAPANスタジオによる「PlayStation VitaにおけるGravityDazeグラフィックフレームワークの設計と実装の試み」と題した特別講演が行われた。

　「GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動」（以下，GRAVITY DAZE）は，重力を自在に変化させることで，これまでになかったようなアクションを取り入れた意欲作だ。独特なアートワークと合わせて，PlayStation Vitaを代表するゲームとなっている。
　GRAVITY DAZEについては，以前紹介した「PlayStation Vita Game Conference 2012」でかなり詳しく解説されていたのだが（関連記事），今回は主にプログラム部分を中心にトピックを絞った解説が行われた。


　講演では，ゲームのコンセプトやアートとプログラムの方針などが紹介されたあと，

• キャラクター
• 背景シーン
• 描画のランタイム処理
• 線描とフォグ・空

についての実装の手法が解説された。全体的な流れとしては，まず，アートディレクターの山口由晃氏が基本コンセプトを紹介し，続いてリードプログラマの横川 裕氏が，そのコンセプトを具体化するための手法を解説していくという順序で進行していた。

左：山口由晃氏　右：横川 裕氏

こだわりの動きと入念な管理が目立つキャラクター処理

　まずはキャラクターの処理について。
　最初にキャラクターの概要が紹介された。モーション数は800種類程度で，使用しているジョイント数はメインキャラで180本，NPCで30前後。LOD（詳細度別モデルデータ）は2個から3個ずつ持っているとのこと。
　キャラクター管理上の工夫では，ジョイントなどの命名規則やルール付けは初期段階で規格化し，リグ（身体の各部を動かすコントローラ）はできるだけシンプルに保つよう心がけていたほか，モデルデータ用のチェックツールを用意したり，Excelをツール化するなどの手法を使っていたという。どういう部分をチェックしていたのかが気になるところだが，スライドに示されたツールのウィンドウを見ると，checkタブの部分に，

• スケルトンに0以外の角度は無い？
• 必要なノードのチェック
• chara_typeのチェック
• 同名ノードのチェック
• LODのチェック
• model_topのtexturefileNodeリスト
• キーフレームのチェック
• dm_だけどウェイトが付いてるjoint

といったチェック項目が並んでいた。キャラクターモデルを多く扱うゲームだけに，こういった部分は念入りに管理していたようだ。


　浮遊中のモーションについては，デザイナーが作成した基本形が8種類用意されており，そこに重力や空気抵抗などで各関節に力を加えて作っていったとのこと。FK（フォワードキネマティクス）が使われていることは以前の記事でも紹介したとおりだが，これは関節などの拘束ありきで作られるIKやラグドールの動きを嫌って，見た目に面白い動きを優先したためのようだ。GRAVITY DAZEでは，よく見ると関節がありえない方向に曲がっているような動きも許容しているとのこと。そのほうが面白い動きになるからだ。
　手付けのポーズへのFKの影響度を決定するブレンド比率は，コントローラの入力値などによって変化させることで，操作へのレスポンスを行うとともに，シンプルな仕組みで無限のモーションを作り出すことに成功している。

実在感のあるオープンワールドはいかにして作られたか

　「Living Background」というキーワードのもと，GRAVITY DAZEのプレイ空間はこだわりの仕様となっている。バンドデシネ調の独特な空気感が取り入れられ，インタラクティブであることが重視されたため，影の焼き込みを行わずすべてリアルタイムで陰影処理され，ある程度の大きさのオブジェクトはすべて壊せるといったフィーチャーが用意されている。講演では，それらを表現するための各種課題と解決手法が示された。

　まずは，オープンワールドの実現の部分から。ゲームのマップは，広さが2km四方で上下が8kmの空間であり，中層の4つの街と世界の柱，下層の街で構成されている。街は，80m立方のエリアに分割されており，階層的に建物などのデータが管理されている。一つの街は12〜32個のエリアで構成されているとのこと。


　世界を構成するモデルデータは，以下のようなデータで構成されているという。

• メッシュ（ポリゴンデータ）
• マテリアル
• LOD情報
• 子モデルへの参照（窓など）
• AABB情報

　AABBというのは，Axis Aligned Binding Box，つまりxyz軸に平行な辺で構成された，物体を囲む最小の直方体を意味する用語だ。オブジェクトのある範囲を大雑把に判定する際などに使われる。

AABBを可視化すると，なにもない空間も実に多くのエリアに分かれていることが分かる

　モデルデータは3段階のLODで用意されており，エリアに入ったときにハイポリゴンのデータと接触判定情報，エリアから出たときにローポリゴンデータを読み込んでいるとのこと。ただ，移動が速すぎると読み込みが間に合わないので，キャラクターの位置を判定して読み込みを調整するといった工夫がされている。


　リファレンス（各種データファイルの参照関係をまとめた構造体）としては，モデリングツールとして使われているMayaのものと独自のものの2種類を併用しているという。ただし，Mayaのものもそのまま使っているわけではなく，インタフェース部分を改良して，誰がどのファイルで作業しているかなどをMaya上から確認できるようにしたり，ファイルの内容を右クリックで簡単にプレビューできるようにしたりしているとのこと。
　一方で，独自に作成したというリファレンスでは，加工された中間データを参照したり，再帰的な参照に対応したりするなどの工夫が行われているという。GRAVITY DAZEの開発では，Maya側でも実機と同等のシェーダを使うように設定されているのだが，独自のリファレンスを用いないと実際のゲーム時と同じマテリアルでの描画にはならないようだ。独自リファレンスを使うプラグインが作られたことで，MayaのViewportで，ほぼ実機と同じ画像が確認できるようになり，アート制作の効率化に大いに役立ったとのこと。


　次にコリジョン（衝突判定）関係。宙を飛んであらゆる部分に着地できるゲーム仕様もさることながら，さまざまな部分が破壊できるということで，GRAVITY DAZEでは衝突判定は重要な意味を持つ。ちなみに，コリジョンと破壊ではミドルウェアとしてHavokが使用されているそうだ。
　以前作ったゲームでは，コリジョン専用の担当者を置いて衝突判定エリアの設定などをしていたそうなのだが，今回は専任者を置かず，デザイナーがそれぞれコリジョン設定を行っていったという。これには，このゲームのコンセプトでもある“Living Background”が関連してくるのだが，単なる形だけを作るのではなく，デザイナーがゲーム内で生きた小物を作ることを意識させるという意味があったとのこと。


　ゲームの舞台はかなり広大な空間で，オブジェクト数も多く，1シーン内のモデル数は3000〜8000に及ぶという。これをそのまま表示しようとすると，とてもではないが重すぎてゲームにはならなくなる。そこで行われるのがカリング（表示オブジェクトの最適化）である。
　GRAVITY DAZEでは，視錐台カリングとオクルージョン（遮蔽）カリングの二つの手法が使われている。視錐台というのは，視点とスクリーンの四隅を結んだ線を延長してできる四角錐の空間のことで，およそ目に見えるものはすべてその内部に入っている。つまり，そこに入らないものは，表示処理をしなくても問題はない。そういう考え方で，視錐台にかすりもしないオブジェクトを処理対象から外すのが，視錐台カリングである。
　判定には，オブジェクトのAABB情報を使い，AABBの直方体が視錐台の外にある場合は処理対象から除外，中にある場合は表示，交差している場合は，子階層のAABB情報を判定していくといった流れで処理しているとのこと。

　これで明らかに見える可能性のないオブジェクトは排除できたのだが，GRAVITY DAZEの街はかなり入り組んでいるため，それだけではまだまだ重い。そこで，ほかのオブジェクトの後ろで見えないオブジェクトを取り除こうというのがオクルージョンカリングである。
　幸いPS VitaのGPUであるPowerVR SGX543MP4＋には，ポリゴンが見えているかどうかをチェックする可視テスト機能が搭載されているので，それを使って実装しているとのこと。
　これらのカリングを適用することで，描画オブジェクト数を激減させることができる。ゲームのパフォーマンスを支える技術となっているようだ。

このようなシーンでのカリングの様子を見てみよう	街全体のオブジェクトは膨大
視錐台に入らないオブジェクトを削ったところ	さらに，ほかの建物の陰になるオブジェクトを削るとこうなる

　可視チェックは，すでに見えている物体については5フレームに1回，見えていない物体については毎フレームで行っているという。ただし，処理のレイテンシの問題で，1フレーム期間で完了させることは無理とのことで，描画を1フレーム遅らせているとのこと。なお，可視チェック用には，専用のモデリングデータを用意している。


　続いてシャドウについて。
　前述のように，インタラクティブ要素が強いこのゲームでは，あらかじめ焼き込んだ影は使えない。すべてをリアルタイムで処理する必要がある。その半面，リアルタイム処理ならばインスタンシングとの相性がよく，シャドウマップを読まなくてよいといったメリットもある。とはいえ，これだけ込み入った街で思い通りかつ高品位の影を実現するのも難しい。
　とりあえず，影の投影には，オーソドックスなLight Space Perspective Shadow Mapの手法が使われているとのこと。使用するモデリングデータは，影生成専用に作られたものを使う。また，影を生成する部分は，視錐台の最低限のエリアに限定しているという。手前のあたりで視界が終わっていれば，その向こうにあるものは処理する必要はない。


　影のエッジ部分は，PCF（Percentage Checked Filter：影処理している周囲のピクセルから影をサンプルしてぼかす手法）でぼかされているものの，別途オートフォーカス処理が施されるため，全体としてはシャープな輪郭になっている。ただ，遠景では負荷軽減のため，PCFを使わずに距離によって影をフェードしているほか，フォグをかけて影自体が目立たなくなるようにしているとのこと。

3スレッド処理の描画ランタイム

　このような描画処理自体をどのようにしているかという部分についても解説が行われた。GRAVITY DAZEでは，CPUコア3個（PS Vita自体はCPUコアを4個内蔵しているが，ゲームで使えるのは3個）を使った3スレッドの処理を行っているという。
　各スレッドの処理内容は，スライドで示された図のとおり。


　メインスレッドでシーンを解析しつつ，スレッド1では描画中間コマンドを生成し，スレッド2では遮蔽処理が行われている。前述のように，遮蔽処理だけが現フレームの情報で処理され，描画処理は一つ前のフレームの情報を使っているはずだ。

　描画中間コマンドというのは，シェーダの種類と使用する定数をまとめたもので，実際の描画コマンドよりも高速に実行できるのだという。まあ，リアルな描画コマンドも生成しないといけないので手間自体は増えているのだが，増えた手間の部分は別のCPUコアで実行されるので，結果として並列化が効き高速になるわけだ。また，描画中間コマンドをシェーダの種類でソートすることで，描画時のシェーダ切り替えをなくすという最適化も同時に行えるので一挙両得なのだそうだ。

フォグと空，描線の処理

　GRAVITY DAZEを特徴付けるグラフィックスで，重要な役割を担っているのがフォグと空，そして描線の処理だ。
　コミック調のタッチを目指しているので描線は必須であり，ただそれだけだと絵が硬い。フォグを加えると背景の情報量が極端に落ちる。そこで背景に描線を加え，さらにブルームを加えてと，処理を重ねて独特な風合いを実現している。背景部分にはテクスチャなどは貼っていないので，高速化にも一役買っているとのこと。

フォグなし	フォグあり
フォグ＋描線	フォグ＋描線＋ブルーム

　描線は2種類のものを使い分けているという。背景用には，描画時に視線とポリゴンの成す角を内積で求めておき，そのデータからソーベルフィルタで輪郭抽出を行うことでラインを生成している。キャラクター用には，モデリングデータをちょっと拡大したものをポリゴンの表裏を反転して輪郭線の色で描画し，普通のモデルをもう一度描画するという，この手の処理ではわりと一般的な手法が使われている。

　空とフォグについては，以前の講演では単に空の色でフォグを作っているという話だったと思ったのだが，実際にはフォグの色は距離によって変化するという，少し複雑な実装だったようだ。


　プラットフォームの立ち上げ時に短期間少人数で新規タイトルを制作する必要があったためか，全体に効率的な開発を目指す方向でツールの整備やデータの管理に配慮がされていたことがうかがえる講演だった。
　GRAVITY DAZEの開発を始めたときに，PS Vita用のゲームエンジンは存在しなかったので，今回はすべて自前でシステムを作り上げているのだが（PS Vita自体が存在していなかったのだがHavokが使えたことがむしろ不思議か），既製品のエンジンを使っていては，このタイミングでこの性能は出せなかっただろうと山口氏は語った。ハードなチャレンジがいくつもあったにも関わらず目標を達成できたのは，結果的に作業順とプライオリティ付けがよかったためではないかと横川氏は振り返っていた。とはいえ，難題を次々とこなしているプログラムチームの力量には驚くばかりだ。
　なお，8月に開催されるCEDECでは，今回よりもっと詳細な解説が行われる予定だという。そちらの講演にも期待したい。