［CEDEC 2015］VR用ゲームエンジン開発はここに注意せよ。「The PlayRoom VR」エンジンを開発したSCEジャパンスタジオが秘訣を伝授

　ソニー・コンピュータエンタテインメント（以下，SCE）が開発を進めている仮想現実対応型ヘッドマウントディスプレイ（以下，VR HMD）の「Project Morpheus」（以下，Morpheus）。SCEが世界各地に擁するグループスタジオでは，Morpheusをアピールするために技術デモの数々が開発されており，それらは，Game Developers ConferenceやE3，東京ゲームショウといった展示会やイベントで公開されるたびに，体験者から高い評価を受けている。

　そうしたデモの中でも，SCEジャパンスタジオが開発したThe PlayRoom VRシリーズの技術デモは，VRの楽しさや新しい可能性を指し示すような，斬新なものばかりだ（関連記事1，関連記事2）。
　そんなThe PlayRoom VRの裏側を解説するセッション「The PlayRoomエンジンをVR化する：Project Morpheusを導入するための手引き」がCEDEC 2015で行われたので，本稿ではその概要をレポートしたい。セッションを担当したのは，SCEジャパンスタジオのシニアプログラマーである横川 裕氏である。

講演を担当した横川 裕氏（右）。PlayStation Vita用アクションゲームの名作「GRAVITY DAZE」で，リードプログラマーを務めたことでも知られる

VR向けレンダリングエンジン設計における注意点とは？

　The PlayRoomのことを知らない人がいるかもしれないので，一応説明しておこう。このアプリはもともと，PlayStation 4（以下，PS4）にプリインストールされていたもので，PS4用のカメラデバイス「PlayStation Camera」を活用する拡張現実（AR）アプリである。本セッションのテーマであるThe PlayRoom VRは，The PlayRoom開発チームが独自開発したゲームエンジン――本稿ではThe PlayRoomエンジンと呼ぶ――をベースに開発されたもので，いわばMorpheus対応版The PlayRoomエンジンといったところか。

　横川氏は初めに，The PlayRoomエンジンをMorpheusに対応させていくまでの過程を解説した。
　最初に行われたのは，1フレーム分の映像をレンダリングする時間内に，右目と左目の位置に置いたカメラから，2回レンダリングできるように，エンジンを改造することだった。簡単そうに聞こえるかもしれないが，意外に面倒な作業だったという。
　原理的には，視点位置を変えて2回レンダリングするだけというシンプルなものだが，単純に2回の描画パスを実行するのではなく，片側の目に表示する映像を描画したあとで，もう片側の描画を行うときに，先の描画に使ったリソースを積極的に再利用するといった工夫をこらして，描画時間を短縮する必要があったそうだ。

VR向けの改造は，3D立体視描画への対応から始まったという

　また，横川氏は，テレビ画面向けのグラフィックス描画とVR HMD向けのグラフィックス描画とでは，要求仕様が異なるという課題も挙げた。
　テレビ画面向けのグラフィックスでは，目標となるフレームレートは30〜60fps。一方のVR HMD向けでは，60fpsは最低ラインにすぎない。そのうえ，プレイヤーによる操作から，それを反映した映像が表示されるまでの遅延は，最大でも20ms以下にすることが求められる。

テレビ画面向けとVR HMD向けでは，グラフィックスに求められる仕様も変わってくる

　さらに，ある程度離れて見るテレビ画面向けの描画と違って，VR HMDの場合は目の前10cm程度という至近距離で対象物を表示することも可能であるため，オブジェクトを近くで見たときのディテール表現が重要になってくるという。そのため，法線マップ（ノーマルマップ）による疑似凹凸表現を多用するよりも，実際にポリゴン数の多い3Dモデルでオブジェクトを表現したほうが良いそうだ。
　そのほかにも，テレビ画面向けの描画では，画面の見た目がリッチになるポストエフェクトを多用する傾向が強いが，VR HMDでは陰影がリアルに表現される高品位なライティングを重視したほうが，優れた映像体験をユーザーに提供できると横川氏は述べていた。

VR HMD向けでは，オブジェクトが，より近づいてきたときの表現に気を配るべきと横川氏

　テレビ向けでは気にならないようなグラフィックス表現も，3D立体視やVR HMD向けでは表現の“ウソ”が露呈しやすいため，使用には注意が必要であるという。たとえば，平板（スプライト）にテクスチャを貼り付けたビルボード表現や，画面座標系のポストエフェクトといった2.5次元的なテクニックは，両眼視差による視覚では，フェイクであることがバレやすいのだ。
　また，左右の目で見る2枚1組の映像では，左右の絵でアンチエイリアス（ジャギー）やシャドウ・アクネ（影のエッジに出る毛羽立ち）の表現が異なっていると，立体視として視覚したときに不自然さを与えてしまうという。

3D立体視やVR映像表現で注意を払うべき要素

　横川氏は，これらの点を注意深く避けながら，The PlayRoomエンジンのMorpheus対応を進めていったそうだ。

The PlayRoom VRエンジンのスペック

　なお，HMDの光学系で生じる歪みに合わせて変形（ディストーション）させる処理系は，Morpheusのソフトウェア開発キット（以下，SDK）に含まれる機能をそのまま使用している。

VR光学系の歪みに合わせて変形させるディストーションは，Morpheus SDKの標準機能をそのまま使う

　また，MorpheusおよびDUALSHOCK 4やPlayStation Move（以下，PS Move）といったコントローラの向きや位置の検出も，Morpheus SDKに含まれるライブラリ「VrTracker」を利用しているという。VrTrackerで取得したMorpheusとコントローラの3D位置情報を，ゲーム世界の座標系に変換すれば，VRの基本的なセットアップは行えるわけだ。

Morpheus SDKに含まれるVrTrackerは，MorpheusとDUALSHOCK 4，PS Moveの位置や向き（回転）を取得できる。指定時間を与えれば，予測位置や予測回転状態も取得可能

VrTrackerライブラリを利用することで，Morpheusや各種コントローラの位置を取得できる

VrTrackerで取得した現実世界におけるMorpheusやコントローラの3D位置をゲームの座標系に変換する

　一方で，プレイヤーの操作を仮想世界に反映させて，ゲームを進行させる「ゲーム設計」（プレイヤーコントロールの設計）は，最適解というものがないと横川氏は指摘する。そのため，ユーザーが酔ったり気分が悪くなったりしないように，十分に配慮しながら開発を進めていくべきであるとのことだ。

技術的な正しさや先進性は，VRゲームの快適さとはリンクしない場合がある。プレイして気持ち悪くならないゲームを作るように気を使うべし

　これまでに挙げた機能を盛り込んだVRコンテンツを作成してみても，実際に動かしてみると，状況によっては激しく画面がぶれる現象に見舞われてしまう。これは，主にフレームレートが安定しないときに起きる現象で，HMDで表示される映像がHMDの向きと合っている場合（フレームレートが規定以上）と，合っていない場合（フレームレートが規定未満）が入れ替わるときに起こる現象だ。

基本的な実装しか行っていないVRコンテンツでは，映像の振動が頻発する。その理由はフレームレートの低下にあるという

　こうした現象を起こしにくくするには，「リプロジェクション処理」が有効であると横川氏は説明する。リプロジェクション処理――Oculus VRの用語では非同期タイムワープ処理――とは，フレームレートが落ち込んで，HMDの向きや位置に合った映像が表示できないときに，前に表示したフレームを加工して，表示されるべき映像フレームを生成する処理系のことだ。テレビの倍速駆動で補間フレームを生成するロジックと，考え方は似ているといえば，分かりやすい人もいるだろう。

リプロジェクション処理で生成されるフレームは，前に表示したフレームの映像表示位置を，その瞬間のカメラ姿勢（VR HMDの向き）に整合させるだけで，映像に描かれる動きそのもの（キャラクターの動きなど）は補間されない

　ちなみに，PS4とMorpheusでは，リプロジェクション処理を非同期Computeタスク，つまり，グラフィックスレンダリングとは別にバックグラウンドで処理されるGPGPU処理系で実行しているそうだ。あくまで筆者の予想なのだが，この仕組みは，PS4にAPUを提供しているAMDが，自社GPU向けに開発したVR向けSDK「LiquidVR」での実装に近いものではないかと思う。

Morpheusの開発キットには，リプロジェクション処理の機能が含まれている

　ただ，横川氏は，「リプロジェクション処理はあくまでも救済措置であり，フレームレート低下や遅延（レイテンシ）の根本な解決にはなりえない」と警告している。そのうえで，VRコンテンツ制作において，「フレームレートの維持」「低レイテンシ」は，グラフィックスエンジンやゲームエンジンの基本設計段階から意識して開発をすべきだと強調していた。
　ちなみに，フレームレート向上は，グラフィックス処理系を簡略化することで容易に対策できるが，低レイテンシはゲームエンジンの基幹設計部分から手を入れないと修正が難しくなることも多いため，レイテンシ問題に気が付いたときには最も優先して対策すべきであるとも述べていた。

レイテンシの低減を後回しにすると，対策しにくい問題になる可能性もある

リプロジェクション処理の効果を発揮するにはレイテンシの把握が不可欠

　さて，ここまではあくまで理想論というか，エンジン開発に当たっての目標のようなものだ。実際のVRコンテンツでは，どんなに処理を並列化したところで，ある程度の処理時間はかかってしまい，それが積み重なるとレイテンシとして表面化してしまう。ゲーム処理（入力）と描画処理（出力）が逐次実行される以上，レイテンシは避けられないものだ。

　VrTrackerは，Morpheusの現在位置や姿勢を取得するだけでなく，現在の情報をもとに，指定時間後の予測される姿勢を取得する機能も備える。つまり，レイテンシが避けられないのであれば，レイテンシ分の時間が経過した状態におけるMorpheusの姿勢，つまり，「絵が表示されるときに頭はどこを向いているのか」を予測して，描画したりリプロジェクション処理をしたりすれば，よりレイテンシの影響が少ない映像を表示できる可能性がある。

ゲームループにおけるレイテンシを正しく把握して，レイテンシに配慮した描画やリプロジェクション処理を行うことが重要だ

レイテンシ低減の指針

　ここで横川氏は，The PlayRoom VRエンジンにおける処理の流れを示しながら，実際の処理系におけるレイテンシ隠蔽の仕組みを解説した。ここからは，下に示すスライドを見ながら，読み進めてもらいたい。

The PlayRoom VRエンジンで生じるレイテンシを示したスライド

　まず，処理開始時点がスライド左にある「いまここ」で，Morpheusの画面中央に映像が表示されるまでの総遅延時間を「ゲームレイテンシ」とする。スライド左上の「Update」は，ゲーム処理を行うタスクで，コントローラからの入力処理や，キャラクターの処理を行う。
　描画を始める前には，ゲームレイテンシを考慮して，現時点（いまここ）にゲームレイテンシ分を加算した時点におけるMorpheusの予測姿勢を，VrTrackerから取得する。そして，Morpheusの予測姿勢から計算できるカメラビュー情報――仮想世界における視点の向きや角度――で，グラフィックス描画コマンド（スライドでは「GfxCmd」）を形成するのだ。

　グラフィックスコマンドが用意できたら，GPUに描画を行わせるわけだが（スライド中の「GPU Render」），この直前にもう一度，描画に要する時間を考慮して，Morpheusの予測姿勢をVr Trackerで取得するのだという。具体的にいうと，GfxCmd終了時点に，スライド下側の「ゲームレンダリングレイテンシ」分を加算した時点におけるMorpheusの予測姿勢を取得するということだ。
　そして，2回めの予測姿勢から計算されるカメラビュー情報を使って，GPUは実際に映像を描画する。つまり，GPUが映像を描画するまえに，2回もVrTrackerを呼び出して，最新の予測姿勢を取得しているのである。

　実際に描画が終わると，リプロジェクション処理を経て表示になるわけだが，リプロジェクション処理中にもレイテンシは発生する。そこで，リプロジェクション開始時点にスライド中の「リプロレイテンシ」分を加算した時点におけるMorpheusの予測姿勢を，VrTrackerで三度（みたび）取得するのだという。ここで取得した予測姿勢を使って，実際のリプロジェクション処理を行い，ようやく実際に表示される映像が完成するわけだ。

　このように，The PlayRoom VRエンジンの実装形態では，ゲームレイテンシとゲームレンダリングレイテンシ，リプロレイテンシという3種類の遅延時間を正確に予測したうえで，VrTrackerを活用することで，理想にかなり近い高品位なVR映像を実現している。横川氏は，「各レイテンシの見積もりが大きく誤まっていたり，あるいはフレームによってレイテンシの増減が大きかったりすると，いくら姿勢予測をともなったリプロジェクション処理を行っても，安定した表示にはならない」と注意すべき点を挙げていた。

レイテンシをいかにして正確に見積もればいいのか？

　VR向けのゲームエンジンを制作したとして，実際問題，レイテンシはどの程度おきているのだろうか。
　横川氏は，VRコンテンツ開発におけるレイテンシの量を可視化するテクニックを披露した。それはシンプルなもので，上述した処理系を使い，HMD画面上に2Dの座標系で点や十字を描画し，この状態でHMDをかぶって，頭を動かす実験をするというものだ。

　各レイテンシが大きかったり，予測したレイテンシが不正確であったりするほど，頭を動かしたときに，ドットや十字が大きくぶれて見えるようになるという。レイテンシが大きかったり，予測レイテンシとのズレが大きかったりすると，姿勢予測の誤差を反映したはずのリプロジェクション処理によって描かれたドットや十字が移動してしまうためだ。予測レイテンシが正確であれば，姿勢予測付きのリプロジェクション結果は理想に近くなるなので，ドットや十字はぶれることなく，ほぼ静止した状態として見えるのである。

レイテンシを可視化するための手順。描画用視点の姿勢とHMDの姿勢が完全一致していれば，リプロジェクション処理でブレは起きない。ブレの大小は，すなわち描画用の姿勢とHMDの姿勢がどれだけずれているかによって変化する

　レイテンシ確認のデモを動画で撮影してきたので，こちらを確認してみると分かりやすいのではなかろうか。


　話は変わるが，横川氏が開発に携わったThe PlayRoom VRシリーズのVRコンテンツのうち，「Magic Controller」というインタラクティブデモ（関連記事）は，リアル120fps表示を実現しているそうだ。これは，かなりアグレッシブに最適化を進めた結果として，どうにか達成されたものだったという。

120fps表示を実現した，Magic Controllerにおける各タスクのタイムライン

120fpsを実現するには，ゲーム処理から描画完了までをわずか8.34msで実行しなければならず，PS4の性能ではかなり厳しい挑戦となったという

　Magic Controllerのほかにも，The PlayRoom VRエンジンを使ったVRコンテンツには，「Bedroom Robots」「Monster Escape」といったものがあるのだが，これらはいずれも60fpsベースでレンダリングを行い，120fpsに倍速化したうえで，リプロジェクション処理を行う手法を採用している。ちなみに，これらのVRコンテンツでは，VrTrackerによるMorpheusの予測姿勢検出を，ゲーム処理開始時とリプロジェクション処理直前の2回しか行っていないそうだ。

60fps表示のVRコンテンツにおける各タスクのタイムライン

　横川氏によると，60fpsから120fpsへとリプロジェクション処理したVR映像は，窓の外を流れる背景を見たときや，高速に移動する動体を首の動きで追うようなときには，ブレやカクつきが見えてしまうのは避けられないとのこと。リプロジェクション処理というものは，頭部の動きに追従した映像を補間生成するものであり，映像中にある動きを滑らかに見せるものではないためだ。

リプロジェクション処理は完璧なものではなく，向き不向きがある

Morpheusの隠し機能を駆使したMonster Escapeの秘密

Monster Escapeのイメージ

　The PlayRoom VRエンジンに関する話題は以上のとおり。だが，横川氏のセッションではほかにも，非常にユニークな技術に関する解説があった。それは，先にも名前を挙げた「Monster Escape」で，VRゲームとしてはかなりユニークな，非対称ゲームメカニクスを採用したゲームである。

Morpheusのビデオ出力ユニットであるPU（写真はGDC 2014で公開されたもの）

　Morpheusには，「Processor Unit」（以下，PU）と呼ばれるインタフェースボックスがある。PUは，Morpheusに映像を出力すると同時に，PS4からの映像をテレビに出力する機能も備えているデバイスだ。
　このPUのテレビ出力機能には，Morpheus装着者が見ている映像をテレビ表示用に歪みを補正して出力する「Social Screen Mirrorモード」と，Morpheusに表示されるものとは別の映像を出力する「Social Screen Separateモード」（以下，Separateモード）の2モードが搭載されていることが，横川氏から正式に発表されたのである。
　といっても，これらの機能が存在することは，E3 2015でThe PlayRoom VRのデモが披露された時点で判明していたことではあるが。

Social Screen Mirrorモードは，Morpheusと同じ画面をテレビに映す表示モードだ

　とくに注目すべきは，Morpheusとは別の映像を表示できるSeparateモードのほうだ。このモードは，PS4側で描画した別視点の映像を，PS4 GPU内蔵のH.264エンコーダで圧縮してUSB経由でPUへと転送し，PU側で映像にデコードしてからテレビへと出力するという仕組みであるという。
　非対称型ゲームメカニクスを採用したMonster Escapeの場合，このSeparateモードを活用して，Morpheusを装着する怪獣側の視点は一人称視点で，テレビ画面を見ながらプレイする戦隊ヒーロー側は，三人称の後方視点で画面が描画される。この機能は，The PlayRoom VR開発チームがMorpheus開発チームと連携して実装したものだそうで，SCEとしても，かなり期待度の大きい機能とのことだ。

「Social Screen Separateモード」。Morpheusとテレビとで異なる映像をテレビに出すモードだ。Morpheusの画面はHDMI経由，テレビ向けの映像はUSB経由で伝送される。USBで生映像は流すのは帯域的に厳しいので，H.264の圧縮ビデオストリームにして流すという手間がかかる

非対称型ゲームメカニクスを採用するMonster Escapeは，1つのゲーム世界を怪獣側とヒーロー側という2つのカメラで捉えている

　横川氏は，Monster Escapeのグラフィックス仕様も公開した。それによると，Morpheus側は1920×1080ドットの60fpsで描画しているが，テレビ側は1280×720ドットの30fpsになっているという。
　この組み合わせだと，Morpheus単体での描画負荷と比べて，テレビ向け描画を加えてもピクセル描画負荷が22％ほど増加するだけだった。頂点パイプラインの処理負荷や，影生成の描画負荷などを含めても，GPUの処理負荷は50％増加する程度で済んでいるそうだ。

Monster Escapeでは，PS4のGPUでMorpheus向けの映像を1920×1080ドット/60fpsで，テレビ向けの映像を1280×720ドット/30fpsで描画している

　Monster Escapeの描画タイムラインも説明された。描画コマンドは，Morpheus用とテレビ画面用を並列で一気に形成し，まずはMorpheus向け映像を描画する。そして，それをMorpheusに出力した直後に，テレビ向け映像の描画を開始しているという。テレビ向け映像の描画中は，Morpheus向けの映像出力が実行中であるが，60fpsから120fps表示への変換を行うので，1回めはそのまま出力し，2回めはリプロジェクション処理を行っての出力となっている。
　一方のテレビ向け映像は，描画が終わったら順次テレビへ出力される。ただ，こちらは30fps表示なので，Morpheus向けと比べて，描画のコマンド形成回数が半分になっている点は注意すべきだろう。

Monster Escapeにおける各タスクのタイムライン。テレビ向け映像描画は30fpsなので，Morpheus向けと比べて，2回に1回ペースで行えばいい

　50％の負荷増をどう捉えるかは，ゲームによりけりだろうが，横川氏は「＋50％のGPU負荷で，5人が遊べる新しいゲームが実現できると考えれば十分挑戦する価値のあるテーマではないか」と述べていた。

Separateモードは，VRゲームの新形態を提案できると横川氏。ゲームによっては，活用し甲斐のあるモードだろう

　セッション終了後に，MorpheusのSeparateモードについて気になったことがあったので，横川氏にいくつか質問してみた。
　まず，SeparateモードではPS4 GPUの内蔵H.264エンコーダを使うのだが，これを使うということは，同じようにH.264エンコーダを使うシェア機能が使えなくなるのではないか，という質問だ。これについて横川氏は，「ゲーム録画機能は利用できなくなるが，ストリーミング配信機能は利用できる」と答えていた。

　また，Monster Escapeではテレビ側の描画が1280×720ドットの30fpsとなっていたが，960×540ドットで60fpsといった，同程度の負荷で解像度を下げてフレームレートを上げるといった手法は可能かとも質問してみた。これも「基本的には可能」（横川氏）とのこと。ただ，H.264エンコードされた映像は，解像度が下がるほどMPEGノイズが目につきやすくなるので，ベストバランスは1280×720ドットの30fpsではないかとのことだった。
　ほかにも，H.264エンコーダを使うことで，ストリーム映像が出力されるまでの遅延に影響が出ないのかも聞いてみたが，「Monster Escapeにおける30fpsのゲーム性という範囲では，影響はない」そうだ。

　セッションレポートは以上のとおり。VRゲームに向けたグラフィックスエンジンの開発指針や，リプロジェクション処理の細かい活用事例といった情報は，これまでなかなか外部に出てこなかった情報だけに，貴重な知見といえよう。
　また，非対称型ゲームメカニクスに利用できるMorpheusのSeparateモードも，ユニークで新しいゲームの可能性を見出せる機能として注目に値する。ただ，GPU負荷が1人用VRゲームと比較して1.5倍になるというのは，なかなかハードルの高い要求ではある。120fps表示を実現したMagic Controllerの手法も，最適化の苦労を考えると，一般的なVRゲームで真似ることは難しそうだ。

　いずれにしても，机上の空論ではなく，VRゲーム開発現場の人物が話す濃密なセッションであり，今後のVRゲーム開発に役立つ情報が多いセッションであった。

CEDEC 2015 公式Webサイト