Unreal Engine 4を使って地球を衛る方法
23 likes36,912 views
講演動画：https://www.youtube.com/watch?v=IlSxh3edvIg 2018年10月14日に行われた「UNREAL FEST EAST 2018」における株式会社ユークス様の講演で使用されたスライドです。 ●公式サイト https://unrealengine.jp/unrealfest/ ＝＝＝ 大人気シリーズ"地球防衛軍"の新作である"EARTH DEFENSE FORCE: IRON RAIN"をUnreal Engine 4を使用して開発中です。本セッションでは、大量のキャラクターやオブジェクトが登場するゲームを開発する際に得られた、問題点とその改善方法、制作手法に関するノウハウをお話しさせて頂きます。
Unreal Engine 4を使って地球を衛る方法
- 2. はじめに ディースリー・パブリッシャー様から2019年に発売予定の、 大人気タイトル「地球防衛軍」シリーズの最新作 EARTH DEFENSE FORCE: IRON RAIN (以降、EDF:IR/本作) を開発しています。ナンバリングタイトルとは全く別の新しい世界観で、戦い 続ける兵士たちをリアリティをもって描く、もう一つのEDFとなっています。 https://www.d3p.co.jp/edfir/
- 3. はじめに
- 10. 最適化資料 ■Unreal Engine 4 のレンダリングフロー総おさらい https://www.slideshare.net/EpicGamesJapan/cedec2016-unreal- engine-4 EGJ篠山様のスライドです。2016年のCEDECで発表された内容です。 負荷の原因となる部分を特定するための必須知識が盛りだくさんの神スラ イドです。
- 15. 機能要件
- 18. 略語について 下記のように定義させて頂きます。 ・Static Mesh = SM ・Skeletal Mesh = SKM ・Destructible Mesh = DM ・StaticMesh Component = SMC ・SkeletalMesh Component = SKMC ・Destructible Component = DC
- 19. プロトタイプ
- 24. 作ってみた
- 30. 実機で動作確認 ■ 具体的には… ・CPU処理負荷 : 120 ～ 450ms ・GPU処理負荷 : 45 ～ 55ms ・ロード時間 : 246秒 ・メモリ使用量 : メモリの食い過ぎでそもそも起動しなかった → コンソールのデバッグメモリを有効にしてなんとか起動
- 31. 全然成立してまへんがな！
- 36. 実機で起動するまで ■ 96,000に膨れ上がった原因 ・Modular Assetsを採用したことにより、1つの建物辺り600～800の Actorが必要になった ・800m*800m四方のエリアに配置する建物は軽く100棟を超える ・単純計算でも 平均700/建物 * 100 = 70,000 Actors ・当然ながら、レベルに配置されるものは建物だけではない
- 39. 実機で起動するまで ■Modular Assetsのデメリット ・Modular Assetsを採用する=採用しない場合に比べてActorが増え る、という当然の図式 ・また、Modular Assetsはパーツ1つ1つのポリゴン数はそこまで多くない ことから、LODを作成しにくく(=GPUパフォーマンスを稼ぎにくい) ・更に、LODを作成した際にもシルエットが崩れ易いという問題も
- 40. 実機で起動するまで ■Modular Assetsのデメリット ・破壊可能な建物もDM ActorをModular Assetsにして作成したが、 こちらは話にならなかった ・先述のCPU処理負荷450msというのは建物破壊時の処理負荷だった ・外壁は当然のことながら、密度を上げようと建物内部にまで格子状の DM Actorを詰め込んでいたのも多くなった原因で、建物1棟当たり 2,000ものDM Actorを使用した
- 41. 実機で起動するまで ■さらば、Modular Assets ・色々な理由を鑑みた結果、Modular Assetsは使用しないことにして、 建物ごとにメッシュを1つ作成するごく普通のスタイルに変更
- 42. 実機で起動するまで ■ レベルの作り直し ・アーティストにお願いし、Modular AssetsをまとめたSMを建物ごとに 作成後、SM Actorを再配置して貰い、このタイミングでLODも追加 ・まずは最低限のものを出すために、建物破壊はいったん脇において考える
- 43. 実機で起動するまで ■ レベルの作り直し ・結果、同じ見た目でActorは96,000 → 1,200に ・実機にて起動したところ、負荷が大幅に改善！CPUの処理負荷は30～ 45FPS程度は達成できるくらい下がり、ロード時間も40秒ほどになった ・ちゃんと作ればちゃんと動く → この時点においては、UE4でActorが多いステージは問題が多いと いうことで結論付ける
- 45. プロトタイプまとめ
- 46. プロトタイプまとめ ・ターゲットプラットフォームでの検証は、開発初期で時間を取って行うべき ・後回しにすればする程原因が折り重なっていき、わけがわからなくなる ・エンジンビルドが必要とはいえ、タイトル側の対応なしにゲームコンソール 向けパッケージの作成が一撃でできるUE4はすごく頼りになる → Third Person Templateをゲームコンソールで起動するところを スタート地点に！
- 50. 製品版のクオリティを目指して
- 51. 製品版のクオリティを目指して ■ 製品版のクオリティ ・プロトタイプの後は製品版クオリティを意識した工程に移行 ・その中で実装について工夫した点および発生した問題点、その改善案に ついてご紹介
- 52. 建物破壊
- 59. 建物破壊 ■ポイント1 ・ DCに最初からDMを設定しておくとコリジョン周りで色々と問題が起きる → これは、 SMCとDCを全く同じ位置に配置してあるのが原因
- 65. 建物破壊 ■ポイント2：改善案：アセット容量が増えがち ・ポリゴン数の多さもさることながら、それ以上にメモリを食い過ぎなので、 アーティストと相談しLOD 0ではなく1～2を元にDMを作成してみた → DMの全体が見えるのは破壊フローに突入する一瞬だけであとは破片 となって飛び散るので、見た目的には案外問題ないことがわかった → メモリ容量を8MB～20MBくらいまで抑えることができ、なんとか運用 できそうなレベルになった(それでも相当重いが…)
- 66. 建物破壊 ■ Destructible Troubleshooting Guide 公式トラブルシューティング。ワークフローや表現方法、各種機能について 詳しく記載されている。DMを使用する場合は必見。 https://wiki.unrealengine.com/Destructible_Troubleshooting_Guide
- 67. 建物破壊 ■ Tim Hobson氏 ・DMについては、EGのTim Hobson氏がブログで詳しく色々と情報を公 開している ・色々な表現のチュートリアルがあるのでかなりオススメ ・DM以外の機能に関するチュートリアルも豊富に揃っている http://timhobsonue4.snappages.com/home.htm
- 69. 処理負荷
- 71. Draw Thread
- 74. Draw Thread ■ Draw Thread負荷の計測方法 ・Draw Threadの負荷はstat scenerenderingで確認する ・他にも各種数情報が取れる - Draw Call数 - 現在のDecalの描画数 - レベル上のデカール数 - レベル上のライト数 etc...メチャ便利
- 76. Draw Thread ■ InitViews ・InitViewsはstat initviewsで更に詳細確認可能 ・特にOcclusion Cull項目が重かった ・Occlusion Cullingで描画足切りされる ものは多かったが、その判定処理が重い せいで元も子もない結果に ・最適化前は最大8～9msにも！
- 77. Draw Thread - Culling -
- 78. Draw Thread ■ Occlusion Culling(遮蔽カリング) ・簡単に言うと「カメラ位置から見えないものを描画しない」という処理 ・本作ではカメラから見て建物の裏にある小さなプロップは概ね見えないの で、Occlusion Cullingされる ・その遮蔽判定の処理負荷をInitViewsにあるOcclusion Cull項目で 確認できる
- 81. Draw Thread ■Occlusion Culling ・どうやったらOcclusion Cullingの負荷が下がるのか？ ・もっとも簡単なのは、当然Actorの数を減らすこと ・しかし、Actorを減らせばビジュアル密度が下がり要件を達成しにくくなる ・また、「全体的にものをxx個減らす」という作業はタスクとして曖昧すぎる
- 82. Draw Thread ■Occlusion Culling ・Occlusion Cullingはプロジェクト設定のRendering > Cullingに ある設定項目でOffにすることは可能 ・もちろん、そんなことをすれば当然GPU負荷が上がってしまうので、ボトル ネックの場所が変わるだけに… (これはタイトルの方針次第なので、 場合によっては効果的なケースも)
- 83. Draw Thread ■Occlusion Culling ・ではどうするか？ ・Occlusion Cullingの対象物を減らせればもちろん負荷は下がる ・でも、Actorは無暗に減らしたくない ・Occlusion Cull判定に投入する前に「描画しない」ことを確定させれば 判定対象から外すことができる → Distance Cullingがある！
- 84. Draw Thread ■ Distance Culling(距離カリング) ・文字通り、距離をトリガーとするカリング ・Mesh Componentの派生クラスに 設定可能 ・Desired Max Draw Distanceと いうパラメータがあり、カメラからの距離が これをこえた場合、描画されなくなる
- 87. Draw Thread ■ Distance Culling ・Mesh Componentごとに細かく設定できるのが非常に便利 ・建物はほぼカリングしないが、プロップはかなりカリングしたいというような メッシュの性質を元に設定できる ・当然Actorごとに手作業で設定する必要はあるが、調整次第ではビジュ アルへの影響はほとんど出さずに済む
- 88. Draw Thread ■ Distance Culling ・Mesh Componentごとに設定というのが面倒な場合は、Cull Distance VolumeというActorを設置することで、 Mesh Componentのサイズごとにカリングする距離 を自動的に判定することもできる ・サイズで一律に判別することはできない場合 こちらは使えない可能性も
- 89. Draw Thread ■ Distance Culling ・本作ではサイズではなく、主にプロップの種類ごとに設定したかったので、 外部パラメータ化してしまいBeginPlay時にMesh Componentごとに 自動的に設定するようにしているためCull Distance Volumeは不採用 ・パラメータ化&自動設定処理により、そこそこの手間で大きな恩恵を受け ることが出来ている
- 90. Draw Thread ■ Distance Culling ・遠くのものを足切りで描画しないということで、 Desired Max Draw Distance近辺でメッシュが突然描画されなくなるという問題は残る ・特に見通しが良いステージでは顕著なので、ステージのビジュアル要件次 第ではあまり使えないケースもある ・得られる効果と見た目のバランスが良いので、本作では積極的に使う方 針
- 91. Draw Thread - Decal -
- 99. Decal ・見た目への影響は最小限で、大幅に負荷を下げることができた！ ※ 左列が設定前、右列が設定後 設定前後でデカールの総量(Decals in scene)は変わらず、見えている 範囲のデカール数(Decals in view)は激減した
- 101. Draw Threadまとめ
- 103. GPU
- 104. GPU ・ウォークスルーにおけるボトルネックはDraw Threadに集中しており、そ ちらを改善することでGPUの負荷もそこそこ減ってくれたので、あまり集中的 にGPU向けの最適化は行っていない ・例えばDistance Cullingで描画するメッシュを足切りする → GPUに 投入するメッシュが削減されBasePassの負荷も下がる等
- 106. GPU ■Dynamic Resolution ・また、4.19からはDynamic Resolutionという動的に画面解像度を 変更してくれる機能が入ったため、GPUの最適化についてはかなり優しい 状況になりつつある ■公式ドキュメント：Dynamic Resolution https://docs.unrealengine.com/en- us/Engine/Rendering/DynamicResolution
- 107. Game Thread
- 109. Game Thread - Tick -
- 112. Tick ■ 本作での例：プロップ ・プロップは破壊されるまではTickは走らず、ただ描画されているだけ ・破壊された後にTickが有効になり、自分の状態を監視し始める ・Was Recently Renderedにて描画状態を監視し、描画されていな かったら自分を削除する ・それ以降は、プロップ1個分もろともTick処理が完全になくなるという仕 掛け
- 115. Game Thread - Collision -
- 117. Simple
- 118. Complex
- 123. Collision ■Collision Complexity ・注意点2：これにはTrace系の関数に用意されているTrace Complex フラグを有効にした上で、実行する必要がある ・全ての弾のトレースでTrace Complexを 有効にすると、毎回ポリゴン単位での判定が 走ることになり、Traceがボトルネックとなる
- 125. Collision ■Collision Complexity ・改善案：これにより、普段の処理負荷は抑えつつ、着弾先の物理マテリ アルによってエフェクトが変わる、リッチな表現を得ることができた
- 128. Collision ■Generate Overlap Events ・SM ActorのSMC OFF ・追加したSMC ON ・SKM ActorのSKMC OFF ・追加したSKMC OFF ・DM ActorのDC ON ・追加したDMC ON 何故かデフォルト値はバラバラ
- 130. Game Thread - Spawn -
- 131. Spawn ・ゲームプレイ中にリアルタイムに発生するSpawnによる処理負荷もバカに ならない ・本作では動的にSpawnするActorとして下記があった - Strike - Particle - Decale - SFX
- 133. おおすぎる
- 135. Object Pool
- 136. Object Pool ■ Object Poolって？ ・UE4独自の概念ではなく、色々な界隈のプログラミングに使われるデザイ ンパターンの１つ ・メモリアクセスの速度の関係上、オブジェクトの生成/破棄時のコストはバ カにならない ・最初にたくさんのオブジェクトを生成して保持(Pool)しておき、あとはそれ を使い回すことで生成/破棄コストをまるごと回避するという素晴らしいもの
- 137. Object Pool ■ 本作における実装について：準備 ・ObjectPoolManagerという管理するクラスとPoolableObjectとい う管理されるインターフェースクラスを用意 ・ Strike/Particle/DecalそれぞれのクラスにPoolableObjectを(多 重)継承させる ・ゲーム開始時にそれぞれのクラスからゲームに必要な最大数分Actorを 作成し、 ObjectPoolManagerで保持しておく
- 138. Object Pool ■ 本作における実装について：実装 ・ObjectPoolManagerにて、下記の関数を実装 - Use() // PoolされたActorの使用権を得る - Unuse() // 使用中Actorの使用権をPoolに戻す
- 139. Object Pool ■ 本作における実装について：実装 ・PoolableObjectを継承した各クラスにて、下記の関数をオーバーライ ドしそれぞれで必要な処理を実装 - Start() // 使用開始(Activate) - Stop() // 使用終了(Deactivate)
- 140. Object Pool ■ 簡単なイメージ：使用時 void AWeapon::Shot() { AStrike* pStrike = Cast<AStrike>( UObjectPoolManager::Use<AStrike>() ); // Strikeの使用権を1つ確保する this->AddShot(pStrike); // ゲーム処理 }
- 141. Object Pool ■ 簡単なイメージ：使用時 template<class T> AActor* UObjectPoolManager::Use () { T* pActor = Cast<T>(UseFromPool()); AddUsingList(pActor); // 使用リストに追加 pActor->Start(); // 使用開始 }
- 142. Object Pool ■ 簡単なイメージ：使用終了時 void AStrike::Tick() { if( !IsHit() ){ return; } m_pOwnerWeapon->RemoveShot(this); // ゲーム処理 UObjectPoolManager::Unuse(this); // 使用権を戻す }
- 143. Object Pool ■ 簡単なイメージ：使用終了時 void UObjectPoolManager::Unuse(PoolableObject* pObj) { pObj->Stop(); // 使用終了 RemoveFromUsingList(pObj); // 使用リストから外す }
- 144. Object Pool ■ ポイント ・PoolableObjectを継承した各クラスでは、エンジン側で勝手に DestroyされないようにあえてSuper::Destroyをコールしない空の Destroyをオーバーライドしておく bool Destroy( bool bNetForce = false, bool bShouldModifyLevel = true) override { return false; } // あえて何もしない
- 148. Object Pool ■ 採用事例 ・Object PoolはEGのVRゲームRobo Recallでも採用されており、 EGJ岡田様のスライドにて軽く触れられています ■ Robo Recallで使われている最新のVR開発テクニックをご紹介！ https://www.slideshare.net/EpicGamesJapan/robo-recallvr ・Robo Recallはソースコードも見れるようになっているので是非参照して 頂ければ
- 150. 物理アセット
- 153. 物理アセット ・そこで、用途によりボディ数が異なる物理アセットを複数用意 - 当たり判定用に使用するゲームプレイコリジョン用 - 完全に物理挙動に処理を任せる際のラグドール制御用 - ある程度モーションの動きを含めつつも物理的な挙動をしてほしい 場合の物理アニメーション用
- 155. 物理アセット ・死亡して物理シミュレーション状態になったエネミーがレベル上に増えてくる と、Game Thraedが130mも負荷を計上する問題が発生 ・物理アセットのボディが多いため、Physicsの計算が増え過ぎ、Tick GroupのDuaringPhysicsがなかなか終わらず、Game Threadがス トールしていた ・しかし、仕様上 死亡後のエネミーをレベル上に長時間残す必要があった ため、死亡後すぐに消すといった対応は取れなかった
- 159. Spawned Actor List
- 163. まとめ