Meta Quest 2の性能を最大限生かしたリッチなグラフィックを実現するには

Meta Quest 2の性能を最大限生かした リッチなグラフィックを実現するには

アジェンダ ● 会社・登壇者紹介 ● DYSCRONIA:CAについて ● 対象端末 ● GPUパフォーマンスチューニング方針 ● CPUパフォーマンスチューニング方針 ● まとめ 2

会社紹介 設立 2016年4月 資本金 50,000,000円 (累計資金調達額 13億円) 従業員数 約50名（正社員のみ） 事業内容 VRゲームの開発及びパブリッシング、ライツ事業、マーチャンダイジング事業 主な作品 東京クロノス ALTDEUS :Beyond Chronos DYSCHRONIA :Chronos Alternate 2019年3月 2020年12月 EpidodeⅠ- 2022年9月

登壇者紹介 尾上 明広 Senior Game Engineer 2022/3月～ 山本 順也 Graphics Engineer 2022/4月～ MyDearestのゲーム開発エンジニア。 新卒でカプコンに入社し、AAAタイトル含め複 数の開発に携わり、システムの基礎設計から リリースまで一貫して担ってきた経験を持つ。 MyDearestのグラフィックスエンジニア。モバ イルVRのパフォーマンスを最大限引き出すた めの最適化などを得意とする。前職のスマー トフォンゲーム開発会社ではテクニカルリード を務めた経験も持つ。

DYSCHRONIA: CAについて MyDearest初となる、VR空間上を自由探索できるゲーム性を採用。 「掴む」「投げる」「覗き込む」といった身体的な動作を伴う VRならではのインタラクションが可能になった。

DYSCHRONIA: CAについて 一方で、探索可能なマップ数や触れられるオブジェクト数が膨大に。 その為、ゲームプレイを飽きさせない、かつVR酔いを低減できる グラフィックスやモーションの強化が必要不可欠に。

対象端末

Meta Quest 2 モバイル Meta Quest2 OS iOS/Android Android SoC いろいろ Snapdragon XR2 メモリ いろいろ 5GB FPS 30 / 60 72 / 90 解像度 大体Full HD以上 1600 x 1440 x 2枚 Androidで、２画面(両目)を、秒間72回描く必要がある

Meta Quest 2 モバイル Meta Quest2 OS iOS/Android Android SoC いろいろ Snapdragon XR2 メモリ いろいろ 5GB FPS 30 / 60 72 / 90 解像度 いろいろ 1600 x 1440 x 2枚 対象端末は一つだけ！ しかもそれなりに速い(Snapdragon 865相当) メモリは潤沢

GPUパフォーマンスチューニング方針

チューニング方針 ブルームを導入する SFの空気感を演出するため、ブルームを導入したい →ブルームを導入するために、計算リソースを空ける必要がある ある程度以上の、高解像度を維持する VRではエイリアス問題がとても目立つため、解像度感を高く保つ必要がある 「フィル」と「解像度感」のバランスをとればOK

バランスの良い解像度を探す 計測条件 ● R11G11B10 HDRバッファへの描画 ● Bloomを有効化 ● FFR無効 ● GPU実行時間は10ms～11msを最大値として設定する

バランスの良い解像度を探す 描画解像度を変更してみる →密度の高いシーンでは、 72FPSに届かない VRC違反

バランスの良い解像度を探す MSAAレベルを変更してみる →MSAAなしにすれば、密度の高いシーンで 72FPSがキープできる →エイリアス問題が大きく、品質に問題がある

バランスの良い解像度を探す MSAA=2で、Render Scaleを変更してみる →0.95で72FPSがキープできるが、 GPU実行時間がぎりぎり →0.9だと余力がある ＝ 0.9を採用 VRC違反

エイリアス問題を回避する 解像度をあげる以外でも、「解像度感」を高めることは可能 UVのシームを大きくとる Mipmapsの影響で、UVの際の部分にジャギーがでないよう、シームを大きくとります

エイリアス問題を回避する 鋭いハイライトをださない よくある疑似リムライトや Matcap等では、鈍く光らせる

半透明を極限まで減らす 半透明描画は、やはり顕著に重い 空に2枚の半透明ポリゴンを置く →GPU実行時間が約2.2ms増加

半透明を極限まで減らす 出来得る限りポリゴン化する

SetPassの最小化 重いシーンでも 115程度と、ほぼ問題とならなかった →SRP Batcherすごい

FFR GPU負荷が高いときに、視野外周の解像度を下げる機能 DYSCHRONIA:CAでは、QA直前までFFR無しで調整し、最後の最後で有効化 ● ブラッシュアップ工程で、必ず重くなる ● 意図しない半透明の重なりが QAで見つかる ● QA工程でリソース削減はつらい →FFRはかなり効くので、最後の特効薬としてへそくりすることを推奨

GPU側は思ったよりいける CPU側の方が実際つらい

CPUパフォーマンスチューニング方針

チューニングの基準 何故つらいのか プラットフォーム要件として、 72FPSを死守する必要がある。 →落とすとリリースできない

チューニングの前提 そもそもDyschronia:CAのゲーム内容は非常にシンプル →物を触る、持つ、置く、手をかざす、で完結する ゲームのコアロジックとして複雑で重い処理は存在しない →真っ当に作れば普通に収まるはず ・・・という予想

チューニングの方針 収まっていなかったのでチューニング開始 ・瞬間的なスパイク ・恒常的に時間を取っている処理 セオリー通り、計測しながら上記の目立つところを潰していく方針

チューニングの対象 GCアロケーション プロファイラーで見て出ているところを削っていく 毎フレーム出ているものは確実に処理 シーン遷移時や、低頻度な操作で出るものはある程度許容 これを削っていく

チューニングの対象 ログ出力 低頻度であってもスパイクになってしまう +GCしやすいので、 基本的にすべて抑制 文字列の絡んだ処理全般がそもそも厳しめな印象

チューニングの対象 uGUI ・Canvas自体や要素を移動させるとレイアウトの再計算処理が走る →VRだとすべてが 3D空間に置かれた GUIのため、 事実上プレイヤーが動くとすべての GUIに再計算が走ることになる →許容できない重さになる →uGUIをすべてSpriteや不透明のMeshに置き換えていく ImageのFillAmount等、uGUI固有の機能は Sprite用のシェーダー上に新たに実装してもらい対応

チューニングの対象 内製LookAt処理(AnimationJobs) Burstに対応させることでかなり軽量化 →パフォーマンスの向上度合いを見ると、 AnimationJobsのBurst対応は必須になりそう

チューニングの対象 XR Interaction Toolkit 公式パッケージだから問題ないだろう・・・と思いきや 激重 内部を読むと ListからListへの無駄な移し替えが沢山走っている →互換性のため？ 不要な処理をバッサリ削り、半分以下の処理時間に （毎フレーム0.8ms→0.3ms程に軽量化）

チューニングの結果 ・上記の対応でメインスレッドは大丈夫 →極まった最適化を施さなくても少し気を付ければ動いてくれる ・パフォーマンス悪化の原因は一つではないので根気よく潰す必要はある 72FPS死守は基準としては厳しいが、 無理な基準では全くない ちょっとサボったり、明らかに物量が多すぎたりすると無理、くらいの温度感 →CPU自体はつらいことはつらいが思ったよりはつらくない

並行して ・上記の対応でメインスレッド ”は”大丈夫 →メインスレッドしか使ってなかったためチューニングとしては事実上終了 ・しかし、そもそも手つかずのコアが余っていて非常にもったいない →まだまだこのハードのポテンシャルを活かしきっていない

魚群

基本技術 Burst + JobSystem GPU Instancing Vertex Texture Animation

Burst + JobSystem ・魚の挙動は完全に並列化してワーカースレッド側で処理 →BurstとJobSystemが非常に優秀 魚群のJob

GPU Instancing ・Graphics.DrawMeshInstancedでインスタンシング描画 ・1023匹ずつまとめて描画リクエストを投げる →MaterialPropertyBlockに魚ごとに違う情報を詰め、 複数種類の魚を 1度のリクエストで描画 色の違う群れを一度に描画

Vertex Texture Animation ・テクスチャに頂点の位置を焼き付けてアニメーションとして扱う ・頂点単位で制御するため、頂点位置をアニメーション側で変えて焼き付けることで ある程度違う種類の魚に見せられる

魚群自体の実装 ・一般的なBoidの実装を少し簡略化し、 最初に所属した群れから離れないように ・他の群れとは衝突判定を行わない →衝突判定の回数を削るためと、狙い通りの動きをさせるため 色の違う群れ同士は お互いに感知しない

つまずいたポイント とりあえず適当に空いてそうなタイミングに Jobを発行してみたところ、 想定以上に性能が出なかった

処理のタイミング エンジン側と実行時間を取り合ってしまうタイミングがある いきなり実行時間が跳ねあがる

タイミングの試行錯誤 プロファイラーとにらめっこしながらタイミングを模索 ・Updateの後 →Animation関連とバッティング ・LateUpdateの後 →長くなると描画関連とバッティング ・Updateの先頭 →長くなるとAnimation関連とバッティング

試行錯誤の結果 最終的にはUpdateの先頭とLateUpdateの後に分散して配置 どちらかだけでも収まることは収まるが、 不定期に実行時間が跳ねるので分散 念のため余力を残して少し分散

CPU側のまとめ ・余っているCPU資源を活用することでかなり表現のレベルを上げられた ・Burst + JobSystemは軽く書くだけでも通常の C#とは段違いの性能を叩きだしてくれるので、 使えるシチュエーションがあったら積極的に使った方が良さそう ・工夫次第でできることは非常に多いハードという印象

まとめ

まとめ Meta Quest2での開発は、モバイルと比べてそう大変なものではない • Meta Quest2自体はかなりポテンシャルが高いハード • 得意なことに徹底すれば驚くような絵が出せる VR環境特有の注意は必要 • プラットフォームの FPS要件がキツイ • エイリアス問題は、 NonVRゲームよりもシビア