Download to read offline
![historia Inc.
事前のパフォーマンス検証 (3/7)
パフォーマンス検証について-事前のパフォーマンス検証- 28
• 企画時点の仕様
8 x 7[m]のスペース
50 x 50 x 50[cm]のブロックで
床や壁を作る
一辺のブロック数
16[個] ≒ 8[m]
256個のブロックで
検証レベルを作成](https://image.slidesharecdn.com/pmqyoguradistrev2-200325090228/75/2019-Oculus-Quest-VR-28-2048.jpg)
Uploaded byhistoria_Inc
【出張ヒストリア2019】Oculus Quest フリーロームVRを実現するための技術的知見
全スライドをDocswellで公開中！ https://www.docswell.com/s/historia_Inc/57EDJK-2019oculus-quest-vr-230838116 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 「出張ヒストリア！ ゲーム開発勉強会2019」（https://historia.co.jp/archives/12449/）で行った「”アスレチックVR PAC–MAN CHALLENGE（パックマンチャレンジ）”制作事例 ～Oculus Questを使用した我々の挑戦～」講演の技術的なパートの内容に、UNREAL FEST EAST 2019で行った講演内容を書き加えたものです。 マーカーキャリブレーションの解説及びサンプルプロジェクトは以下のURLからDLできます。 https://historia.co.jp/distribution/docs/PC_MarkerCalibration.zip 講演者： 小倉 裕貴（エンジニア） 以下、セッション概要より抜粋。下記のセッションの技術パートのみとなっております。 MAZARIA（池袋）にて稼働中のOculus Quest（PCが必要無く、コードが無いタイプの新VRゴーグル）を使用したフィールドVRアクティビティ、”アスレチックVR PAC–MAN CHALLENGE（パックマンチャレンジ）”。 コードが無いというのは自由に歩き回れるというだけではなく、新たな価値を生み出していました。 前半では本タイトルを通じて得た、コードレスによりもたらされた新たなゲームデザインについてお話いたします。 また、後半ではハードウェアスペックとの戦いや、どのように複数人プレイを実現したかなどの技術的知見をシェア出来ればと思います。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
![[UNREAL FEST EAST 2017] VRゲームairtone制作事例 - VRを活かす3つのゲームデザイン的挑戦](https://cdn.slidesharecdn.com/ss_thumbnails/vrairtonevr3forweb-171012133720-thumbnail.jpg?width=640&height=640&fit=bounds)
【出張ヒストリア2019】Oculus Quest フリーロームVRを実現するための技術的知見
- 1. historia Inc. エンジニア 小倉 裕貴 OculusQuest / フリーロームVR を 実現するための技術的知見
- 2. historia Inc. スライド配布について • 一部を配布予定 •プロジェクト配布 – https://historia.co.jp/distribution/docs/PC_MarkerCalibra tion.zip – UE4.22にて動作確認済み はじめに 2
- 3. historia Inc. 略称について • 「UnrealEngine 4」を「UE4」 • 「Oculus Quest」を「OQ」 • 「Head Mounted Display」を「HMD」 はじめに 3
- 4. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 はじめに 4
- 5. historia Inc. 自己紹介 • 小倉裕貴（Ogura Yuki） – エンジニア – historiaブログ管理人 – 宴会ソムリエ はじめに 5
- 6. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 開発環境と実装方針 6
- 7. historia Inc. 開発環境について • OculusVR配布のカスタムエンジン – 最新のOculus SDKsによる実装 – OQ動作要件を満たすために使用 • 最終バージョン UE4.21.2 – 最終的に3回エンジンを変更 開発環境と実装方針 7 時期 Version Distribution プロトタイプ UE 4.20 EPIC Games パフォーマンス検証前 UE 4.20 Oculus VR 最終バージョン UE 4.21 Oculus VR
- 8. historia Inc. 実装方針について(1/2) • Blueprintで実装 –プロトタイプのイテレーションを重視 – エンジン変更時の修正を減らす • コードはプラグインとして実装 – Android固有機能でコードが必要 開発環境と実装方針 8
- 9. historia Inc. 実装方針について(2/2) • 完全なゲームプレイには広いスペースが必要 –常時使用はできない – 使用準備に時間がかかる 開発環境と実装方針 9 スペースでの確認を最小限にする エディタで確認しやすいようにする
- 10. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 フリーロームVRのための機能 10
- 11. historia Inc. 移動スケール(1/2) • 自席や狭いスぺースで実機テストしたい HMDの移動量を増やし、少しの移動で大きく動かす機能 フリーロームVRのための機能-移動スケール-11 Move Scale = 1.0 Move Scale = 4.0
- 12. historia Inc. 移動スケール(2/2) • CameraコンポーネントのLocationを変更できない HMDの移動に応じて 親コンポーネントの位置をオフセット フリーロームVRのための機能-移動スケール-12 Locationを変更できない オフセットのためのSceneを追加
- 13. historia Inc. 移動スケール(2/2) • CameraコンポーネントのLocationを変更できない HMDの移動に応じて 親コンポーネントの位置をオフセット フリーロームVRのための機能-移動スケール-13 親となるコンポーネントの 位置を調整 HMDの位置から オフセットを取得
- 14. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 フリーロームVRのための機能 14
- 15. historia Inc. プラットフォームごとのPawn (1/2) •エディタと実機で同等のゲームプレイ – VR空間のプレイヤーと同じ挙動を再現する 実行時にプラットフォームによってPawnを切り替える フリーロームVRのための機能-プラットフォームごとのPawn- 15
- 16. historia Inc. プラットフォームごとのPawn (2/2) •OQで使われるPawn – VRプロジェクトテンプレートのPawnを改造 • Windowsで使われるPawn – Default Pawnを改造 – PIEではOQのPawnと同等の挙動を行う フリーロームVRのための機能-プラットフォームごとのPawn- 16
- 17. historia Inc. プラットフォームごとに同等の挙動の実現 インターフェースにより異なる処理を同じように振る舞わせる 「手で握る」などの固有の処理は、Pawnごとにテストが必要 フリーロームVRのための機能-プラットフォームごとのPawn- 17 手で握った物に対して 「Pickup」を実行 コリジョンに触れた物に対して 「Pickup」を実行 何であっても「Pickup」されたら このフルーツを取得する
- 18. historia Inc. プラットフォームごとのPawnの切り替え (1/3) 1.実行プラットフォームを確認 フリーロームVRのための機能-プラットフォームごとのPawn- 18
- 19. historia Inc. プラットフォームごとのPawnの切り替え (2/3) 2.実行プラットフォームに応じたDevice Pawn Classを取得 3. Default Pawn Classと異なる場合のみ切り替える フリーロームVRのための機能-プラットフォームごとのPawn- 19
- 20. historia Inc. プラットフォームごとのPawnの切り替え (3/3) 4.Device Pawn ClassをSpawnActor 5. Possess 6. 切り替え前のPawnをDestory フリーロームVRのための機能-プラットフォームごとのPawn- 20
- 21. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 フリーロームVRのための機能 21
- 22. historia Inc. マーカーによるキャリブレーション • アニメーションを残すためにスライドを分割 •スライドは配布プロジェクト内に添付 https://historia.co.jp/distribution/docs/PC_MarkerC alibration.zip はじめに 22
- 23. historia Inc. まとめ(フリーロームVRのための機能) • 制作のイテレーションを止めないために 移動スケールやプラットフォームごとのPawnを制作した •広いスペースにおけるキャリブレーション問題に対し マーカーを用いた高精度で運営負担の少ない キャリブレーション機能を制作した フリーロームVRのための機能 23
- 24. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • パフォーマンス検証について – 事前のパフォーマンス検証 –描画オプション検証 – 終盤のパフォーマンス調整 パフォーマンス検証について 24
- 25.
- 26. historia Inc. 事前のパフォーマンス検証 (1/7) パフォーマンス検証について-事前のパフォーマンス検証-26 • OQで可能なグラフィックス表現の目安 ポリゴン数 テクスチャ枚数 半透明 etc …… 企画の仕様に基づいたモックアップで検証
- 27. historia Inc. 事前のパフォーマンス検証 (2/7) パフォーマンス検証について-事前のパフォーマンス検証-27 • ブランクプロジェクトから開始 Mobile向け Scalable 3D (Mobile HDR off) Multi Viewのみ 有効に変更
- 28. historia Inc. 事前のパフォーマンス検証 (3/7) パフォーマンス検証について-事前のパフォーマンス検証-28 • 企画時点の仕様 8 x 7[m]のスペース 50 x 50 x 50[cm]のブロックで 床や壁を作る 一辺のブロック数 16[個] ≒ 8[m] 256個のブロックで 検証レベルを作成
- 29. historia Inc. 事前のパフォーマンス検証 (4/7) パフォーマンス検証について-事前のパフォーマンス検証-29 • なぜ床だけ？ オクルージョンカリングで 壁に隠れたブロックが消える 床が全て見えるとき 最大の描画負荷 壁がある方が負荷は大きくなる （オクルージョンカリングが有効でないため） 実際には……
- 30. historia Inc. 事前のパフォーマンス検証 (5/7) パフォーマンス検証について-事前のパフォーマンス検証-30 • 計測方法 1. stat fpsの値を計測 2. 2視点の最悪値を記録 3. メッシュとマテリアル の組み合わせを変える プレイヤーの身長ベースの 斜め俯瞰視点 全ブロックが映る 真上からの視点 複数のメッシュと マテリアルの傾向を調べ 現実的なスペックを求める
- 31. historia Inc. 事前のパフォーマンス検証 (6/7) •使用するブロック Verticesなどが異なる12種類 パフォーマンス検証について-事前のパフォーマンス検証- 31 SM1 Triangles:12 Vertices:24 SM4 Triangles:360 Vertices:216 SM6 Triangles:620 Vertices:402 SM12 Triangles:1404 Vertices:816
- 32. historia Inc. 事前のパフォーマンス検証 (7/7) •使用するマテリアル Instructions, Texture Lookupsなどが異なる12種類 BlendModeを変えたものをそれぞれずつ用意 パフォーマンス検証について-事前のパフォーマンス検証- 32 M_Cube01O BlendMode:Opaque M_Cube04O BlendMode:Opaque M_Cube07T BlendMode:Translucent M_Cube12M BlendMode:Masked
- 33. historia Inc. 事前のパフォーマンス検証 (1/6) パフォーマンス検証について-事前のパフォーマンス検証-33 緑のセル：FPS≥70 赤のセル：FPS<40 行：使用マテリアル 列：使用メッシュ
- 34. historia Inc. 事前のパフォーマンス検証 (2/6) パフォーマンス検証について-事前のパフォーマンス検証-34 量が多い床・壁には Opaque TranslucentはOpaqueよりも重い
- 35. historia Inc. 事前のパフォーマンス検証 (3/6) パフォーマンス検証について-事前のパフォーマンス検証-35 ブロックあたりポリゴン数 150～250 「軽量」なマテリアルのとき FPSを維持できる妥当なスペック
- 36. historia Inc. 事前のパフォーマンス検証 (4/6) パフォーマンス検証について-事前のパフォーマンス検証-36 半透明を使うなら Unlit 「軽量」なUnlitなマテリアルは Opaqueなら負荷は低い
- 37. historia Inc. 事前のパフォーマンス検証 (5/6) パフォーマンス検証について-事前のパフォーマンス検証-37 • Texture Lookup(PS)でソートした結果(昇順)
- 38. historia Inc. 事前のパフォーマンス検証 (6/6) パフォーマンス検証について-事前のパフォーマンス検証-38 • Texture Lookup(PS)でソートした結果(昇順) 量の多い床や壁のテクスチャは 1枚 Texture Lookupが1枚以下は 2枚以上より軽い傾向
- 39. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 パフォーマンス検証について 39
- 40. historia Inc. 描画オプション検証 (1/12) パフォーマンス検証について-描画オプション検証-40 OpenGL ES3.1 Vulkan FFR Level Mobile MSAA Mobile Multi-View etc…… 負荷軽減する描画オプションを調査して Mobile HDRを使用する余地を探る Mobile HDRを使用したい……
- 41. historia Inc. 描画オプション検証 (2/12) •検証方法 MARZA様制作のテストレベルを使用 プレイヤー想定の4アングルを用意 描画オプションを変えてFPSを測定 パフォーマンス検証について-描画オプション検証- 41
- 42. historia Inc. 描画オプション検証 (3/12) パフォーマンス検証について-描画オプション検証-42 • Support OpenGL ES3.1 ハイエンドモバイル向けシェーダー機能の拡張 テクスチャ枚数制限の緩和 Angle 1 Angle 2 Angle 3 Angle 4 Disable 43(23.199ms) 40(24.141ms) 27(35.748ms) 72(14.033ms) Enable 38(26.171ms) 37(26.684ms) 24(41.766ms) 71(14.153ms) 結果 有効にすると最大6msほど悪化
- 43. historia Inc. 描画オプション検証 (4/12) パフォーマンス検証について-描画オプション検証-43 • Support Vulkan オーバーヘッドを低減し、描画・電力効率を改善する Mobile HDRが必要? Mobile Multi-View / Mobile Multi-View Directと併用できない? 結果 他のオプションと競合し、 起動しない・画面がチラつくなど 安定して使えない（※検証当時の結果）
- 44. historia Inc. 描画オプション検証 (5/12) パフォーマンス検証について-描画オプション検証-44 • FFRLevel 視点中央から離れるほど解像度を下げる Angle 1 Angle 2 Angle 3 Angle 4 ETiled Multi Res Level Off 43(23.204ms) 41(24.390ms) 25(39.687ms) 72(13.934ms) ETiled Multi Res Level LMSLow 48(20.881ms) 44(22.727ms) 31(32.004ms) 72(13.918ms) ETiled Multi Res Level LMSMedium 50(19.993ms) 48(20.833ms) 36(27.846ms) 72(13.903ms) ETiled Multi Res Level LMSHigh 56(17.628ms) 47(21.276ms) 36(27.845ms) 72(13.924ms) 結果 タイプによって最大8msほど改善
- 45. historia Inc. 描画オプション検証 (6/12) パフォーマンス検証について-描画オプション検証-45 • Disable Vertex Fogging in mobile shaders 有効にするとモバイルで大気フォグを省略する Angle 1 Angle 2 Angle 3 Angle 4 Enable 43(23.204ms) 41(24.141ms) 25(39.687ms) 72(13.934ms) Disable 39(25.505ms) 39(25.526ms) 24(41.774ms) 71(14.117ms) 結果 有効にすると1～2msほど改善
- 46. historia Inc. 描画オプション検証 (7/12) パフォーマンス検証について-描画オプション検証-46 • Mobile MSAA モバイルで使用できるアンチエイリアシング 結果 目立った改善は見られない 見た目も変化なし → 4x MSAA固定? Angle 1 Angle 2 Angle 3 Angle 4 No MSAA 43(23.204ms) 41(24.141ms) 25(39.687ms) 72(13.934ms) 2x MSAA 43(23.44ms) 41(24.366ms) 25(39.443ms) 72(13.925ms) 4x MSAA 41(24.137ms) 41(24.127ms) 24(40.827ms) 71(14.151ms) 8x MSAA 42(23.902ms) 41(24.592ms) 27(36.803ms) 72(13.928ms)
- 47. historia Inc. 描画オプション検証 (8/12) パフォーマンス検証について-描画オプション検証-47 • Mobile Multi-View / Mobile Multi-View Direct CPU負荷を下げるVR最適化用のオプション Mobile版のステレオレンダリングのようなもの Mobile HDRと併用できない Angle 1 Angle 2 Angle 3 Angle 4 Disable 38(26.221ms) 40(25.301ms) 21(48.734ms) 48(20.884ms) Enable 43(23.199ms) 40(24.141ms) 27(35.748ms) 72(14.033ms) 結果 有効にすると最大6msほど改善
- 48. historia Inc. 描画オプション検証 (9/12) パフォーマンス検証について-描画オプション検証-48 • Monoscopic Far Field Rendering 両眼用に2回必要な遠景の描画を1回にまとめる Mobile HDRと併用できない Mobile Multi-View / Mobile Multi-View Directと併用できない? 結果 Oculusカスタムエンジンでのみ 該当のオプションが存在しない
- 49. historia Inc. 描画オプション検証 (10/12) パフォーマンス検証について-描画オプション検証-49 • Mask-based Foveated Rendering – 視点中央から離れるほど解像度を下げる ≒ FFRLevel • Anti Aliasing Method – 使用するアンチエイリアシング手法 ≒ Mobile MSAA • Instanced Stereo – 両眼用に2回必要なレンダリングを1回にする ≒ Mobile MultiView 結果 Mobileでは効果がない（Desktop向け機能）
- 50. historia Inc. 描画オプション検証 (11/12) パフォーマンス検証について-描画オプション検証-50 • Mobile HDR ハイエンドモバイル向けの機能を使えるようにする マテリアルで実現できる表現が拡張される Angle 1 Angle 2 Angle 3 Angle 4 Disable 43(23.204ms) 41(24.141ms) 25(39.687ms) 72(13.934ms) Enable 34(29.721ms) 32(31.534ms) 18(54.909ms) 48(20.655ms) 結果 有効にすると最大7msほど悪化
- 51. historia Inc. 描画オプション検証 (12/12) パフォーマンス検証について-描画オプション検証-51 • Mobile HDRを使用するか？ MobileHDR前提の機能は多い パフォーマンスの低下が著しい • OQのサンプルゲーム「First Steps」を参考に 半透明による発光表現の代替など Mobile HDRなしで可能な表現で作りこむ方針へ
- 52. historia Inc. 最終設定 パフォーマンス検証について-描画オプション検証- 52 オプション名設定 PixelDensity 0.95 MobileHDR False Disable vertex fogging in mobile shaders True Maximum number of CSM cascades to render 1 Support movable light CSM shader culling True Mobile Multi-View / Mobile Multi-View Direct True Support Combined Static and CSM Shadowing False Support Distance Field Shadows False Support Movable Directional Light False Max Movable Point Light 0 Support OpenGL ES3.1 False FFRLevel ETiledMultiRes Level_LMSHighTop
- 53. historia Inc. 目次 • 開発環境と実装方針 •フリーロームVRのための機能 – 移動スケール – プラットフォームごとのPawn – マーカーによるキャリブレーション • グラフィックスパフォーマンスについて – 事前のパフォーマンス検証 – 描画オプション検証 – 終盤のパフォーマンス調整 パフォーマンス検証について 53
- 54. historia Inc. 終盤のパフォーマンス調整 パフォーマンス検証について-終盤のパフォーマンス調整- 54 •中盤も最適化を続ける 頂点数の削減 マテリアルの改善 etc...... 負荷の大きい部分を調査 しかし、部分的に負荷が大きい……
- 55. historia Inc. Merge Actor(1/2) パフォーマンス検証について-終盤のパフォーマンス調整- 55 • 複数のメッシュを1つにまとめる機能 Draw Callがまとまり、Draw負荷が下がる Cullingが効き難くなり、GPU負荷が上がる Merge Actor前 Merge Actor後
- 56. historia Inc. Merge Actor(1/2) パフォーマンス検証について-終盤のパフォーマンス調整- 56 • 複数のメッシュを1つにまとめる機能 Draw Callがまとまり、Draw負荷が下がる Cullingが効き難くなり、GPU負荷が上がる Merge Actor前 Merge Actor後 DrawとGPUの負荷バランスが最良となる Merge Actorの組み合わせを調べる
- 57. historia Inc. Merge Actor(2/2) パフォーマンス検証について-終盤のパフォーマンス調整- 57 • ラウンドのMerge Actor 床・壁を小分けの 区画としてMerge Actor マテリアルLODを設定 ラウンドの床・壁を全て一つにMerge Actor 区画の大きさを変えてもDraw負荷が優勢……
- 58. historia Inc. Software OcclusionCulling (1/2) パフォーマンス検証について-終盤のパフォーマンス調整- 58 • Software Occlusion Culling MobileでOcclusion Cullingを行うための代替機能 遮蔽物となるメッシュを事前にOccluderに設定し Occluderに遮蔽されたメッシュのみCullingする機能 Occlusion Cullingが動作していない
- 59. historia Inc. Software OcclusionCulling (2/2) パフォーマンス検証について-終盤のパフォーマンス調整- 59 Opaque以外のマテリアルが割り振られていたため 床・壁とネオン管のメッシュを 分離する必要がある Occlusion Cullingは断念 終盤での修正は困難…… Software Occlusion Cullingも効いていない
- 60. historia Inc. Use LightmapDirectionalityの無効化 パフォーマンス検証について-終盤のパフォーマンス調整- 60 • Use Lightmap Directionality 負荷が小さくなる ライトマップからのライティングがフラットになる Pixel Shader（マテリアル）の負荷が高い ライティング対象の 一部マテリアルで無効化 見た目への影響は小さかった 描画負荷は僅かに改善
- 61. historia Inc. Texture Sampleの削減 パフォーマンス検証について-終盤のパフォーマンス調整-61 背景の負荷が高め Normal MapとPanner Noiseを削除 シーン全体で1ms改善 Texture Sampleが多い
- 62. historia Inc. Reflection Captureの範囲縮小 パフォーマンス検証について-終盤のパフォーマンス調整-62 背景全域を包むような範囲 Reflection Captureの範囲が広い 範囲を縮小 プレイエリアの外周を覆う程度まで縮小 僅かにパフォーマンス向上
- 63. historia Inc. 大気フォグの代替 パフォーマンス検証について-終盤のパフォーマンス調整- 63 •大気フォグの使用 遠近感を出すために必要 Disable Vertex Foggingを 無効にして使用 天球への焼きこみに代替 Disable Vertex Fogging in mobile shaders の有効化により負荷軽減
- 64. historia Inc. Pixel Densityの変更 パフォーマンス検証について-終盤のパフォーマンス調整-64 • Pixel Densityを0.95に変更 ゲームのどこを見ても72FPSを維持 少しボヤっとした見た目になる よりよいゲーム体験の実現のため 最後の詰めにPixel Densityを調整
- 65. historia Inc. まとめ(グラフィックスパフォーマンスについて) • プロジェクト初期から検証を行い 表現可能な指標を決めてから制作し 現実的に可能な表現を模索した •定期的なパフォーマンスチェックも行いつつ 終盤では最後の詰めとなる調整を行い より良いゲーム体験を実現した パフォーマンス検証について 65
- 66. historia Inc. まとめ • ルームスケールVRという制約の多い制作において 制作の手を止めないためのデバッグ機能や 広いスペースに由来する問題に対処する機能を制作した •Oculus Questという新しいデバイスに対し 事前検証を十分に行い、出来ること・出来ないことを 明確にしてから制作を行った おわりに 66
Editor's Notes
- #2 では、Oculus Quest フリーロームVRを実現するための技術的知見と題しまして、小倉が発表いたします。 [00:09]
- #3 まずスライド公開についてですが、これは確認をとった後に一部を公開する予定です。 [00:14]
- #4 略称についてです。本セッションではUnrealEngine4をUE4、OculusQuestをOQ、HeadMountedDisplayをHMDとさせていただきます。 [00:21]
- #5 本セッションの目次です。まず開発環境と実装方針に触れ、次にフリーロームVR開発にあたって必要になった機能を紹介し、最後にグラフィックスパフォーマンスについてお話いたします。 [00:36]
- #6 自己紹介です。私はhistoriaのエンジニアの小倉といいます。エンジニア以外にはhistoriaブログの管理人も行っております。 [00:45]
- #7 では早速ですが、開発環境と実装方針についてお話いたします。 [00:50]
- #8 まず開発環境についてです。 開発に使用したエンジンですが、本プロジェクトでは3回のエンジン変更を経て、最終的にはOculus VRが提供するUE4.21のカスタムエンジンを使用しました。 これは、OQの動作要件を満たした最新のOVRPluginを使用する必要があったのが、主な採用理由となります。 [01:12]
- #9 次に実装方針についてです。 実装は基本的にBlueprintのみで行う方針にしていました。 これはプロトタイプ制作のイテレーションを重視していたことと、エンジンを変更することが事前にわかっていたため、エンジン変更時のコード修正にかかる時間を極力減らすのが主な狙いでした。 しかし、実際にはAndroid固有機能などでコードが必要な場面もあったため、その場合はプロジェクト非依存のプラグインとして実装しました。 [01:45]
- #10 また、本プロジェクトはフリーロームVRのため、完全なゲームプレイには広いスペースが必要でした。 弊社では会議室などを用いましたが、当然使用できる時間は限られますし、使用前には環境を準備する必要があり、時間がかかりました。[Click] そこで、本プロジェクトではスペースでの確認は最小限に減らし、エディタでもゲームプレイを確認しやすいように制作を行う必要がありました。 [02:16]
- #11 次にフリーロームVRのための3つの機能について紹介します。 [02:20]
- #12 まず自席や狭いスペースで実機確認をするために、移動スケールという機能を制作しました。 移動スケールはHMDの移動量をスケーリングして、少しの移動でキャラクターを大きく動かす機能です。 以下のアニメーションは移動スケールが1倍と4倍のときで、同じぐらい頭を動かしたときのプレイヤーの様子です。 4倍の方が大きく移動していることが確認できます。4倍ではこのぐらいですが、およそ20倍まで上げれば、スペースのどこにでも移動することができます。 [02:58]
- #13 移動スケールの実装について紹介します。基本的には、現在のHMDの視点であるCameraの位置から、移動スケールを掛けた後の位置を計算し、その位置にCameraを合わせることで実現します。 このCameraの位置はCameraComponentのRelativeLocationによって取得することができます。しかし、このRelativeLocationは直接値を変更することができません。そこで、Cameraコンポーネントの親にオフセット用のコンポーネントを追加し、それを変更することで追加の移動を行います。[Click] これがその実装となります。CameraのRelativeLoationに移動スケールの倍率を掛け、そこからRelativeLoationを減算してオフセットを得ます。オフセットはCameraではなく、その親にあたるMoveScalerコンポーネントに加算することで、Cameraコンポーネントの移動を増やしました。 これで自席でも実機テストが簡単に行えるようになりました。 [03:56]
- #14 移動スケールの実装について紹介します。基本的には、現在のHMDの視点であるCameraの位置から、移動スケールを掛けた後の位置を計算し、その位置にCameraを合わせることで実現します。 このCameraの位置はCameraComponentのRelativeLocationによって取得することができます。しかし、このRelativeLocationは直接値を変更することができません。そこで、Cameraコンポーネントの親にオフセット用のコンポーネントを追加し、それを変更することで追加の移動を行います。[Click] これがその実装となります。CameraのRelativeLoationに移動スケールの倍率を掛け、そこからRelativeLoationを減算してオフセットを得ます。オフセットはCameraではなく、その親にあたるMoveScalerコンポーネントに加算することで、Cameraコンポーネントの移動を増やしました。 これで自席でも実機テストが簡単に行えるようになりました。 [03:56]
- #15 次にプラットフォームごとのPawnについて紹介します。 [04:00]
- #16 移動スケールによって実機での確認を行いやすくなりましたが、それでも実機へのデプロイなどにも時間はかかります。ゲームプレイの大まかな確認はエディタで完結した方が開発は早いです。 そこで、VR空間上のプレイヤーと同じ挙動をエディタ上に再現することで、エディタと実機で同等のゲームプレイを実現できないか考えました。 その方法が、実行プラットフォームによって使用するPawnを切り替えるというものです。 [04:34]
- #17 まず各プラットフォームで使用する次のようなPawnを作りました。 OQで使われるPawnは実際のゲームでも使用している黄色い人型のPawnです。こちらはVRプロジェクトテンプレートのPawnを改造して作成しました。 Windowsで使われるPawnは、キーボードで移動しやすいDefault Pawnを改造したものです。このPawnはPIEではOQのPawnと同等の挙動を行うように作りました。 [05:01]
- #18 では実際にどのように同等の挙動を実現したかについてですが、これにはインターフェースを用いました。 例えばフルーツを取得するには、OQのVR空間上では「フルーツを手で握る」といった操作が必要ですが、エディタ上では「Pawnのコリジョンにフルーツが触れる」という操作で実現させることで「フルーツを取得する」という挙動を共通化させました。 ただし、このやり方は「手で握る」、「コリジョンに触れる」などの固有の処理を正しく動作させる必要があるため、その部分はPawnごとにテストが必要になります。 [05:43]
- #19 次に、実行プラットフォームごとのPawnの切り替えをどのように行ったかについて紹介します。 まず実行プラットフォームの認識にはGetPlatformNameとGetHMDDeviceNameを使用しました。 GetPlatformNameは、Windwos上で実行するとWindowsという名前が返り、OQ上ではAndroidという名前が返ります。 同様にGetHMDDeviceNameはHMDを使用しない環境ではNone、Oculus RiftやOculus QuestではOculusHMDといった名前が返ります。 Oculus Riftはあまり開発に使用しませんでしたが、GetPlatformNameとGetHMDDeviceNameの組み合わせによっては、Oculus RiftとOculus Questを区別することも可能です。 [06:18]
- #20 次に、PlatformNameとHMDDeviceNameによって実行プラットフォームを認識して、それに応じたDevicePawnClassを取得します。 もしDevicePawnClassがDefaultPawnClassと違うものだったら、Pawnの切り替え処理を行います。 [06:28]
- #21 Pawnの切り替えは、DevicePawnClassのアクターをSpawn、Posessして、切り替え前のPawnをDestroyします。 簡単な処理ですが、このあたりは少し不安定な実装のため、実機ではなるべく実行されないことが望ましいです。 幸いにもこの切り替え処理はDefaultPawnClassとDevicePawnClassが異なる場合のみ実行されるので、実機想定のPawnをDefault Pawnに設定すれば、エディタでのみ使用する処理にできます。 これで、プラットフォームごとのPawnを切り替えてエディタでの確認が行いやすくなりました。 [07:03]
- #22 最後に、マーカーによるキャリブレーションについて紹介します。 [07:08]
- #24 まとめです。 制作のイテレーションを止めないために、移動スケールやプラットフォームごとのPawnを制作しました。 また、広いスペースにおけるキャリブレーションの問題に対して、マーカーを用いた高精度で運営負担の少ないキャリブレーション機能を制作することで問題に対処しました [16:42]
- #25 次に、パフォーマンス検証について話します。 まず、事前のパフォーマンス検証について紹介します。 [16:50]
- #26 パフォーマンス検証の前に、今回の検証と調整が目指すパフォーマンスについてお話します。 本プロジェクトでは、VR特有の酔いなどを起こさず、自由に動けるゲーム体験を実現するため、ハードウェアが出せる限界のパフォーマンスを目指しました。 OQが出せる最大フレームレートはハードウェアのリフレッシュレートと一致する72FPSになるため、基本的にこのフレームレートの維持を目指して検証と調整を行います。 [17:24]
- #27 まず、事前のパフォーマンス検証についてです。OQ向けの開発はこれが初めてであったため、OQがどの程度のグラフィックス表現が可能なのかまったくわからない状態でした。 たとえばポリゴン数やテクスチャ、半透明はどれだけ使ってもいいのか、といったことを調査し、制作上の大まかな指標を決める必要がありました。 そこで今回は、企画書に示されていたゲームの大まかな仕様を元にした検証用のモックアップを作成し、それを用いてパフォーマンス検証を行いました。 [18:03]
- #28 まず、検証用プロジェクトはブランクプロジェクトから作り始めました。 その後、実機確認に必要な最低限のプロジェクト設定と、Multi-Viewのみを有効にしました。 Multi-ViewはOculusのガイドにて描画負荷を大幅に軽減するためのオプションであることがわかっていたため、実質必須として扱い、ここでは有効にしました。 [18:27]
- #29 次に検証レベルについてです。 企画書にて「8x7mのスペース内に、配置を変えやすい1辺50cmの立方体ブロックでステージを作っていく」ということが事前に決まっていました。 スペースに満遍なくブロックを配置して床を作ると224個のブロックが必要になるため、余裕をもってここでは256個のブロックで床を作ることにしました。 [18:53]
- #30 ところで、企画書には壁の配置も決まっていたのに、なぜ床だけを作ったのか疑問に思われる方がいるかもしれません。 これに関しては、壁が多くなったときにオクルージョンカリングによって消えるブロックが増えることが期待されていたため、 床が全て見えるときが最悪の描画負荷になると考えてこのようにしました。 しかしこれは後で紹介しますが、実際にはモバイルではオクルージョンカリングは有効に機能していなかったため、壁があった方が負荷は大きくなることが後でわかりました。 [19:35]
- #31 最後に、パフォーマンスの計測方法についてです。 まず、先ほど紹介したマテリアルを適用したメッシュを床ブロックとして配置したレベルを作成します。 次に、このレベルをプレイヤー視点に近い俯瞰視点と全ブロックが映る真上からの視点で見たとき、stat fpsによるフレームレートを計測します。 この計測をマテリアルとメッシュの組み合わせを変えて、用意した全ての組に対して計測しました。 [21:08]
- #32 次に、検証に使用したメッシュについてです。 今回は、頂点数やポリゴン数が異なる12種類のメッシュを選びました。 これらのメッシュで床を作ったときのパフォーマンスを見て、現実的に使用できるメッシュのスペックを調査しました。 メッシュの中にはブロック形状でないものもあったので、それらはApproxSizeから計算してブロック形状に近づくようスケーリングしました。 [20:05]
- #33 次に、メッシュに適用したマテリアルについてです。 検証に使用するマテリアルには、InstructionsやTextureLookup、ノード数などが異なる12種類を選びました。 また、選んだマテリアルのBlendModeをOpaque、Masked、Translucentに変えただけのマテリアルをそれぞれ用意しました。 これらのマテリアルを先ほどのメッシュに適用したときのパフォーマンスを見て、どのようなマテリアルが現実的に使用できるかを調査しました。 [20:36]
- #34 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #35 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #36 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #37 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #38 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #39 これがその結果です。列が使用したメッシュ、行がそのメッシュに適用したマテリアルで、その組み合わせの床レベルを見たときの最悪のフレームレートが記述されています。 フレームレートが70以上であれば緑、40未満であれば赤色で塗り分けています。また、OpaqueとMaskedで結果がまったく同じになっているなど、明らかに不要と判断した結果は省略しています。 この表の緑と赤の部分から、現実的に使用できるメッシュとマテリアルのスペックがおおよそわかります。[Click] 例えば、BlendModeをOpaqueとTranslucentに比較したものでは、必ずTranslucentの方が重く、緑の部分も少ないことがわかります。 よって、床や壁といった量が多いメッシュにはOpaqueを使う必要があることがわかります。[Click] また、そのようなOpaqueマテリアルを適用したメッシュで、現実的なFPSを維持できるメッシュのスペックは、1ブロックあたりのポリゴン数がおよそ150~250程度であることもわかりました。 しかし、先ほども述べたように、実際にはオクルージョンカリングなどの問題があったため、最終的に使用できたメッシュとマテリアルのスペックはもう少し低いものになっています。[Click] ところで、この時点で既に「表現上、半透明は必要」という結論が出ていました。 そこで、現実的に半透明を使えるメッシュとマテリアルの組み合わせがどのようなものか調べた結果、Unlitで軽量なメッシュを使えば半透明でも負荷はそれなりに抑えられることもわかりました。 [22:53]
- #40 次に、描画オプションの検証についてお話いたします。 [23:33]
- #41 事前パフォーマンス検証では描画オプションはほぼ変更しませんでしたが、 例えばMobileHDRやVulkanを使った時の影響や、FFR Levelといった挙動のわからないオプションの効果についてはまったく未知数でした。 そこで、それらの描画オプションが見た目や描画負荷にどのような影響を与えるのかを調べ、実際に効果的に扱えるのかを調査することにしました。 [24:01]
- #42 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #43 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #44 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #45 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #46 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #47 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #48 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #49 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #50 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #51 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #52 検証方法です。 この時点で背景制作をお願いしているMARZA様に制作していただいたモックアップがあったため、それを検証用のレベルとして使用することにしました。 負荷の計測方法は、プレイヤー視点を想定した4つのアングルでFPSを計測し、オプション変更前後で結果がどのように変わるか調査しました。 [25:16]
- #53 最後に最終設定と効果無し・存在しない・使用できないといった不明なオプションをまとめます。 こちらは詳しくは紹介しません、もしスライドが公開できた際は参考にしていただければ幸いです。 [27:38]
- #54 最後に、終盤のパフォーマンス調整についてお話いたします。 [27:42]
- #55 ここまでは本制作が行われる前に行ったパフォーマンス検証について話しました。 本制作が始まった後もMARZA様によって最適化は続き、頂点数の削減やマテリアルの改善などが行われてきました。 しかし、これらを続けてもいくつかのラウンドでは処理不可が高い部分もあったため、調査が必要でした。 [28:06]
- #56 ここまでの制作でDrawの負荷が比較的大きいことがわかっていたので、MergeActorによるDraw負荷の軽減ができないか調査しました。 その前にMergeActorについて軽く紹介します。これは複数のメッシュを1つにする機能で、共通のマテリアルのDrawCallをまとめることでDraw負荷を軽減します。 一方で1つにまとまったメッシュはCullingが効きにくくなるため、頂点シェーダーで処理する頂点の増加によりGPU負荷があがるという問題もあります。 すなわち、トレードオフの関係であるDrawとGPUのバランスを調整して、それぞれのスレッドのボトルネックを最小化するようなMergeActorの組みを調べる必要がありました。 [28:52]
- #57 ここまでの制作でDrawの負荷が比較的大きいことがわかっていたので、MergeActorによるDraw負荷の軽減ができないか調査しました。 その前にMergeActorについて軽く紹介します。これは複数のメッシュを1つにする機能で、共通のマテリアルのDrawCallをまとめることでDraw負荷を軽減します。 一方で1つにまとまったメッシュはCullingが効きにくくなるため、頂点シェーダーで処理する頂点の増加によりGPU負荷があがるという問題もあります。 すなわち、トレードオフの関係であるDrawとGPUのバランスを調整して、それぞれのスレッドのボトルネックを最小化するようなMergeActorの組みを調べる必要がありました。 [28:52]
- #58 まずはラウンドレベルに対してMergeActorを行いました。 具体的には、図のように床や壁を小分けの区画としてMergeActorしたり、マテリアルLODの設定などをしました。 しかし、結果としてはGPUよりもDraw負荷の方が高く、これは区画の大きさを変えても変わらなかったため、 最終的にはラウンドの床・壁を全て一つにMergeすることでDraw負荷を軽減しました。 同様の調査を背景に対しても行いましたが、こちらも結果としては全て一つにまとめることが最も負荷を軽減することに役立ちました。 [29:30]
- #59 次に、Occlusion Cullingについて調査しました。 RenderDocやUE4のフォーラムなどで調査したところ、Windowsデスクトップ向けなどで機能している通常のOcclusion Cullingは、Mobileでは動作していない可能性が高いことがわかりました。 その代わり、モバイルではSoftware Occlusion Cullingと呼ばれる代替機能があります。 これは遮蔽物となるメッシュを事前にOccluderとよばれるものに設定し、Occluderよって遮蔽されたメッシュのみをCullingする機能です。 機能自体は早い段階で把握していたので、例えばMergeActorしたラウンドレベルなどをOccluderに設定していました。 [30:9]
- #60 しかし、こちらの機能を設定してもなぜかOcclusionCullingは効いていませんでした。 この問題を調査したところ、原因はOccluderに設定したマテリアルのBlendModeがOpaque以外のときは有効に機能しないことが判明しました。 原因はわかったものの、これを解決するにはOccluderとして指定したメッシュをOpaqueのものとそれ以外のものに分離する必要があり、 例えばラウンドのメッシュの場合は、床壁とネオン管のメッシュをそれぞれ分離する必要がありました。 この問題が判明したのはプロジェクト終盤で、影響範囲を考えると修正は非常にリスクを伴うものでした。 よって、今回は残念ながらOcclusionCullingを諦めざるを得ない形になりました。 [31:57]
- #61 Draw負荷は軽減できたものの、今度はGPU負荷が高く、特にPixelShaderの負荷の割合が高かったため、マテリアルの最適化を行いました。 そこで見つけたオプションが「Use Lightmap Directionality」です。 これは、無効のときライトマップからのライティングがフラットになる代わりに負荷が小さくなるというものでした。 見た目への影響も小さかったため、今回はライティング対象となっているメッシュのほぼ全てのマテリアルで無効化しました。 これにより、見た目はほぼ変わらずに、描画負荷は僅かに改善することができました。 [31:37]
- #62 次に、背景の負荷が高めに見えたので、背景のマテリアルを調査したところ、使用しているTextureSampleが少し多めであることがわかりました。 こちらは見た目への影響があることがわかっていましたが、他に削れる部分も少なくなってきたためNormalMapとPannerNoiseのテクスチャを削除することにしました。[Click] こちらが、削除前と削除後の見た目の比較になります。 この変更により、シーン全体で1msec負荷を軽減することができました。 [32:10]
- #63 調査を続けていると、Reflection Captureの範囲が背景全域を包むような大きさになっていることがわかりました。 こちらは範囲縮小または削除によってパフォーマンスが改善することがわかったため、プレイエリアの外周を覆う程度まで縮小することでパフォーマンスをわずかに稼ぎました。 [32:32]
- #64 最後に、大気フォグを天球へ焼きこむことで代替する調整を行いました。 大気フォグは遠景の遠近感を出すために必要だったため、DisableVertexFoggingを無効にして使用していました。 しかしフォグの負荷は予想よりも大きかったため、今回は大気フォグは削除し、代わりに天球へのフォグの焼きこみで代替しました。 フォグを使用しないことによりDisableVertexFoggingオプションを有効化できたため、これによって追加の負荷軽減を行うことができました。 [33:6]
- #65 そして最後の最後に、Pixel Densityも変更しました。 本プロジェクトではより良いゲーム体験のため、72FPSを維持することを何よりも重視していました。 Pixel Densityはゲームの解像度を変更するためのパラメータですが、 こちらを0.95まで落とすことで、ゲームのどこを見ても72FPSを完全に維持できることがわかりました。[Click] 見た目が変わる部分ではありましたが、最良のゲーム体験を実現するための最後の詰めとしてPixel Densityを下げる決断をしました。 [33:40]
- #66 まとめです。 パフォーマンス検証はプロジェクト初期から行い、表現可能な指標をある程度決めてから制作を始めることで、現実的に可能な表現を模索しました。 また、定期的なパフォーマンスチェックも行いつつ、終盤では詰めとなる調整を行い、より良いゲーム体験を実現しました。 [34:03]
- #67 本セッションのまとめです。 ルームスケールVRという制約の多い制作において、制作の手を止めないためのデバッグ機能や 広いスペースに由来する問題に対処する機能を制作し、問題解決にあたりました。 また、Oculus Questという新しいデバイスに対し、事前検証を十分に行い、 出来ること・出来ないことを明確にしてから制作を行うことで、最良のゲーム体験を実現しました。 以上で本セッション終わります。 ご清聴いただき、ありがとうございました。 [34:39]