西川善司の3Dゲームファンのための「GRAVITY DAZE」グラフィックス講座 ～可視テストの遅延問題への取り組み)

　GPU側で行なう「3DオブジェクトのAABB可視テスト」は、いくらレンダーターゲットへの書き出しは行なわれないとは言え、実際にレンダリングパイプラインは駆動されるため、それなりに時間の掛かる処理だ。このため、オクルージョンカリングの結果を受けて順送り式に本番レンダリングに取りかかっていたのでは時間が掛かりすぎる。

　そこで開発チームは「GPU側で行なう3DオブジェクトのAABB可視テスト」の処理時間の“隠蔽”に取り組むことになった。マルチスレッドプログラミングにおける「処理時間の隠蔽」を考えると真っ先に思いつくのがスレッド切換や別処理のオーバーラッピング動作という事になる。

　そこで開発チームは発想を変えて、発行したオクルージョンカリングの結果を、次のフレームのレンダリングに活用するという形のオーバーラップのさせ方を採択したのだった。オクルージョンカリング実行中はGPUで実践される可視テストでGPUが占有されるため、実際の描画プロセスは行なえなくなる。よって、この期間は、CPU側のスレッドにはゲームロジックの更新処理に従事させる。

　現在フレーム基準で考えれば、1フレーム前のオクルージョンカリング結果は得られているので、この情報を元に実際の描画準備をCPU側のスレッドで進めておく。オクルージョンカリングが完了するとGPUが空くので、進めておいた描画準備を実際にGPU側に発行する。GPUはこれを受理して描画を実践する。この辺りの流れをタイムライン図として示したのが下図になる。

【描画タイムライン】

描画タイムライン

現在時間Tにおける描画は、T-1のオクルージョンカリングの結果を用い、T-1の視界(カメラ)で現在時間Tのゲーム世界の描画を行なう

現在時間Tの視界(カメラ)で現在時間Tのゲーム世界に対してオクルージョンカリングを発行する。このオクルージョンカリングの結果はT+1で利用される。時間T+1では、時間Tのオクルージョンカリングの結果と時間Tの視界で、時間T+1のゲーム世界をレンダリングする事になる

　ここで注意点として特記しておきたいのは、前フレームの視点(カメラ)からのオクルージョンカリングの結果情報を利用して、現在時間の視点(カメラ)からのゲーム世界を描画させているわけではないという点だ。

　これをやってしまうと、オクルージョンカリングの結果と、視界の不一致が出てしまうため、遮蔽物の背後から3Dオブジェクトが徐々に見えてくるときや、3Dオブジェクトが手前にある3Dオブジェクトの背後に完全に遮蔽されるときなどにおいて、その出現/消失が唐突となるポッピング現象が視覚されてしまう。そこで「GRAVITY DAZE」では、視点(カメラ)の状態だけを1フレーム分遅らせる手法をとったというわけだ。

【描画タイムライン】

レンダリング用いる視界(カメラ)を1フレーム遅らせることでポッピング現象への対策を行なった

　つまり、“現在”のゲーム世界を、“前”フレーム時のオクルージョンカリングの結果情報を用いて、“前”フレーム時の視点(カメラ)でレンダリングするというわけだ。言い換えると、現在時間においてプレーヤーが画面に見るのは「前フレーム時のカメラで捉えた現在時間のゲーム世界」ということになる。

　この手法だと動かない背景オブジェクトに関しては、オクルージョンカリングの結果に矛盾は起こらないので、ポッピング現象は完全に回避できる。

横川氏：この手法だと、単純にレンダリングをダブルバッファ・パイプライン化して１フレーム遅らすのに比べて、3Dオブジェクトの位置情報や姿勢情報を余分に保持しておく必要がありません。このため、数十MBの省メモリの副次効果もあります。

宮前氏：ご想像の通り、この手法は、動く3Dオブジェクトが含まれていると、そのオクルージョンカリングの結果は不正確という事になりますが、実際には、適用しちゃっています。実際のプレイで違和感がないのでこれでよしとしています(笑)。

土蔵利威氏(SONY COMPUTER ENTERTAINMENT WORLDWIDE STUDIOS JAPANスタジオ インターナルデベロップメント部 テクノロジーグループ テクニカルディレクター)。1997年入社で、本作ではプレーヤーアクション制御、アニメーション周辺技術の開発を担当。「サルゲッチュ」シリーズの1、2、3の開発にも従事した

　プレーヤー基準でみると、プレーヤーは1フレーム前の時間軸の視界で、現在のゲーム世界を見て操作入力をすることになる。ただ、遅れているのは視点(カメラ)座標だけなので、映像を見てプレーヤーが取った行動に対するインタラクションの遅延はない。しかし、視点(カメラ)を移動させる操作に対しては1フレーム分の遅延が発生していることになる。ただ、これも「GRAVITY DAZE」のゲーム性から考えるとそれほど大きな問題になることはないと判断されたようだ。

土蔵利威氏：プレーヤーのスティック操作を受けてのプレーヤーキャラクタに対する挙動更新は、現在の視界情報に対する方向情報で決定しているので、プレーヤー視界(カメラ)の動きが連続していれば、プレーヤーの操作に対してこの仕組みは破綻しません。問題が出るのは、イベントシーンなどで起こりうる唐突な方向転換時です。こうした唐突な方向転換後のプレーヤーのスティック操作は(わずか1フレーム分の時間内ではあるが)、表示映像とのズレが出てしまいます。そこで、そうした状況下では「ズレを抑える」対処を行なっています。具体的には、視点(カメラ)がアニメーションで動くような状況では、カメラアニメーションデータから1フレーム分先のカメラ状態を読み出して設定するといった感じのことをしています。

2段構えのカリング(5)～そのパフォーマンスは?

　この2段構えのカリングシステムの導入前、導入後の効果を比較した結果が下図になる。

　カリングなしでは約5,800オブジェクトをもGPUに入力しなければならなかったシーンにおいて、1段目の視錐台カリングの適用で半分以下の約2,100オブジェクトに削減できている。さらに2段目のオクルージョンカリングの適用で、さらに約1/6に削減され、GPUへの入力オブジェクト数は約360にまで減る。

【カリング適用によるオブジェクトの削減】

テストシーン

一切のカリングなし

視錐台カリングのみ適用時

視錐台カリング+オクルージョンカリング適用時

　処理所要時間で比較すると、CPU側で行なわれるレンダリングのための準備処理の所要時間が視錐台カリングのみ時で約52.5ms、オクルージョンカリング併用時で約23.6msとなっている。GPU側のレンダリング所要時間の方は視錐台カリングのみ時で約54.0ms、オクルージョンカリング併用時で約33.1msとなっている。この値は丁度毎秒30コマ(30fps。1フレームあたりの表示期間33.33ms)の範囲に収まる値である。

【カリング適用時におけるCPU/GPU時間】

視錐台カリングのみのCPU時間

視錐台カリング+オクルージョンカリング適用時のCPU時間

視錐台カリングのみのGPU時間

視錐台カリング+オクルージョンカリング適用時のGPU時間

　前編はPSVitaに特化したグラフィックスプログラミングよりの話題に終始したので、後編では、「GRAVITY DAZE」のビジュアルテイストを特徴付けているグラフィックステクニックにスポットをあてていきたい。