UE4における大規模背景制作事例最適化ワークフロー編

V F X S T U D Y G R O U P©2019 SQUARE ENIX CO., LTD. All Rights Reserved.
株式会社スクウェア・エニックス
斎藤修吉岡国登須山稔明
UE4における大規模背景制作事例
（最適化・ワークフロー編）

スライドについて
・PowerPointファイルをEpic様より公開いただいています
https://epicgames.box.com/s/mwl9a7kv7b0n9q2kfbghxcsgdwrdbbfj
・スライド内の動画はPowerPointファイルのDLにてご確認ください

略称について
・『Unreal Engine 4』をスライド内では『UE4』と記載しています

お品書き
レギュレーション
LOD
インスタンス
カリング
ストリーミング
ロード時間
ディスク容量
ワークフロー
Houdini
自己紹介/初めに

斎藤修
テクニカルアーティスト
• 背景の作り方とか考えたりサポートしたり
• 処理負荷を見たり対応したりしてます
吉岡国登グラフィクスプログラマ
• グラフィックス全般のサポート
• グラフィックス担当での参加は初めて
須山稔明グラフィクスプログラマ
• 背景のグラフィック案件のサポート
• 描画関連の不具合調査・対応

• 初めに
今回の事例では UE4.17.2 を使用しています。
その為最新verでは変更や修正が行われている可能性があります。
また、様々なエンジン改造を行っている為、
状況が再現できない可能性があります。

• 次に
今回、なるべく多くの事例を共有したいと思っております。
その結果、数多くの方が関わられた事もあり、
特殊事例の羅列になってしまいました。
詳細に関してはまた、Q&Aや個別にご質問頂けましたら幸いです。

• 最後に
今回の背景制作事例に関しては数多くの方の、
様々な助力によって達成されました。
以下、発表事例に関して快くご協力頂けました皆様に深く謝意を表します。
後藤保中道雅史中健吾松岡英樹吉田武史
松本章波能智人望月紀嗣木村洋一中村大作
森田英明河崎幸治（敬称略）

背景画面内トライアングル数 300万以内
Drawプリミティブ数 3000以内
（エディタではなく実機で）

ライト複雑度
ライトの重なりは基本2個まで
画面内が青～緑になるように
オレンジ以降はNG

ライトマップ密度
基本的に青局所的に緑まで
赤はNG
UVにリークや歪みが無いか確認

ステショナリーライトのオーバーラップ
重なり2個まで
3個からは完全にNG
（動的影がワースト時にハネるので）

シェーダー複雑度
画面内8割は緑を目指す
マテリアルのインストラクション数は
300まで

LOD遷移チェック
LOD設定がされているか
正しい距離で遷移しているか確認

頂点数チェック
SQEXで拡張
現在の頂点数に応じて色分けされる
赤は10000頂点以上、オレンジは5000頂点以上なので
頂点密度を確認する

シャドウフラスタム
意図してない動的影を
落とすものがいないか確認
また、フラスタムをまとめられないか確認

リフレクションキャプチャ
4個以上の重なり禁止（可能な限り…）
リフレクション調整は重ならないように
配置してからオフセットする
1マップ30～40個程度を上限（メモリ対策）
解像度は64に下げています（メモリ対策）

PLV
密度とめり込みを確認
不必要な箇所にできていないかも確認

PLV
スフィアを並べるBPを使用して
変な色を拾ってないかなどを確認する
（Direct Lightingの表示を切っておく）

コリジョン
プレイエリア外は消しておく
必要以上のプリミティブ分けや、
意図しないLODコリジョンの確認をする

各セクションごとのGPU予算内訳
背景
25ms
キャラ
4ms
VFX
4ms

各パスの予算配分は以下の通り（あくまで目安です）
Shadow
Depth BassPassPrePass Pre
Lighting Light UI
Translu
censy
FOG Post
Process
3ms
SQEX
AfterLight
SSR
Reflection
デカール1ms
SSAO1.5ms
カプセルシャドウ1.5ms
2ms 5ms 4ms 2ms 1ms 3ms1ms 2ms 2ms1ms

プレパスには全投入しています。
（なので描画ポリ数やdraw数が厳しかったです…。）
PrePass
3ms 2ms 5ms 4ms 2ms 1ms 3ms1ms 2ms 2ms1ms

GPUの負荷チェックには
「SqexGPU」という
リアルタイムプロファイリングツールを
作成して頂きました。
（パス拡張などの理由で
STAT GPUが使えなかったので）
Test版でも確認できるので、
アーティストは必ず実機で「SqexGPU」で
予算超えしてないか確認して、
予算を超えていたらTAがプロファイラで
詳細確認、対応する、
というフローを組んでいました。

また、CPU負荷は「SqexCPU」
という、
各スレッドごとの状況が
リアルタイムで確認できるツールを
こちらは基本的にはPGさんが
確認していました。
（どのレベル、どのアクタが原因で
処理落ちしてるか、くらいまでは
TAが見ることもありました。）

特定レベルの出し消し、
ロードアンロードを行える
ツールも作成して頂きました。
処理負荷が高い場合は、
とりあえずこれでレベルを
順次アンロードすることで、
どのレベルがネックかなどが
分かってとても便利でした。

また、特定のアクタだけを
表示非表示、デストロイできるツール
も作成して頂きました。
レベルを出し消しして
犯人がいる場所が分かったら
直接デストロイして突き止める、
というフローがTAやアーティストでも
可能でとても便利でした。

また、各セクションごとに
タグやオブジェクトIDを判定して
表示非表示を切り替える機能も
これにより、各セクションの予算が
適切に守られているか、というのが
とても確認しやすくなりました。

また、午前中の
「自動プレイの
ポストモーテム」
でも触れられたかと
思うのですが、
これらの処理負荷は日々
定点チェックが行われて
おり、Kibanaでグラフと
該当箇所のスクショが
ビジュアライズされていて
とても便利でした。

また、カットシーンにおいては
総数が200を超え、見るのに
10時間以上かかります。
こちらも自動プレイで
全カットシーンをチェックし
一定以上の処理落ちで
スクショやカットシーン番号、
時間などが記録されるので
とても便利でした。

GPU
テクスチャプール
実行ファイル動的バッファ
アニメーション
PhysX
マテリアル Uオブジェクト
UI リザーブ
その他
サウンド
メモリ配分は以下の通りです。（あくまで目安です）
メッシュAI
350
MB
800
MB
500
MB
200
MB
100
MB
150
MB
150
MB
150
MB
150
MB
350
MB
100
MB
200
MB
300
MB 1500
MB
全体5000MB

UI
レンダー
ターゲット
プール
キャラ
VFX 背景
リザーブ
GPU
PhysX
UI リザーブ
その他
サウンド
メッシュAI
350
MB
800
MB
500
MB
200
MB
100
MB
150
MB
150
MB
150
MB
150
MB
350
MB
100
MB
200
MB
300
MB
全体5000MB
500
MB
50
MB
50
MB
100
MB
200
MB 600
MB

レンダー
ターゲット
プール
GPU
PhysX
UI リザーブ
その他
サウンド
メッシュAI
350
MB
800
MB
500
MB
200
MB
100
MB
150
MB
150
MB
150
MB
150
MB
350
MB
100
MB
200
MB
300
MB
全体5000MB
背景に関わるのはこの辺りです。
UIキャラ
VFX 背景
リザーブ
500
MB
50
MB
50
MB
100
MB
200
MB 600
MB

メモリも
「SqexMemory」
「SqexAssets」
「SqexTexturePool」
という3種の
リアルタイム確認ツールを

「SqexMemory」は
タグ分けされた各メモリを
リアルタイムに確認できます。
それぞれの予算配分は
先程のレギュレーション通り
です。

各タグは拡張したマクロを仕込むことでメモリに追加されています。
メモリに4byteのフッターを追加しており、
タグ（1byte）、メモリ破壊防止タグ（3byte）が含まれています。
フッダーとすることでパディング領域分で、最小限のメモリ増加でタグ記録が可能です。

LLMは試したのですが
使用しませんでした。
メモリ計測に
多くのメモリが必要で
計測する実機に
制限があったからです。
また、動作が重かったのも
難点でした。
https://www.unrealengine.com/ja/blog/unreal-engine-4-18-released?sessionInvalidated=true

「SqexAssets」は
今メモリに乗っている
アセットのリソースサイズが
確認できます。
アーティストは主に
こちらを見ていて、
「SqexMemory」で
予算を超えていた場合に、
どこにネックがあるかなど
チェックするのに使いました。
アセット単位での
CSV吐き出しも可能です。

「SqexTexturePool」は
テクスチャプールの状況を
見ることができます。
STAT TextureGroup や
STAT Streaming などでも
確認可能ですが、
より見やすくまとめて頂いた
ものになります。
テクスチャプール状況の
CSV吐き出しも可能です。

LODは主に「Simplygon」を
使用しています。
レギュレーションは
100% 66% 33%
100% 75% 50% 25%
のどちらかを目安に、
可能な限り削減しています。
UE4内での自動作成や
MAYAでのプラグインでの作成
どちらも使用しています。
LOD

また、LODの設定は
プロパティマトリクスで見る事ができないので、
CSVにエクスポートする機能を追加して頂きました。
LOD

また、LODは
UE4内で生成した場合は
LOD間のライトマップを
共有してくれるのですが
外部からインポートすると
別々のライトマップを
生成されてしまいます。
↓
LOD間でベイク結果が
異なったりメモリが
増えたりして困ります。
LOD

そこで、LOD間で必ず
ライトマップUVを共有する
オプションを追加して
頂きました。
（手作業でLODを作成する
場合は、必ずUVを
一致して頂きました。）
LOD

これにより、ベイクエラーの回避と
ライトマップの削減を
行うことができました。
LOD

HLODも使用しています。
ただ、作成と保守のコストが
とても高いので
処理負荷的に厳しいマップで
のみ使用しています。
メモリを多く食うのも
ネックの一つでした。
LOD

HLODの生成は
オートメーションツールで
自動化して頂きました。
LOD
登録したレベルまとめて
HLOD作成して
サブミットまでしてくれます。
これがないと数多のレベルを
手作業で一つずつ
HLOD作成してサブミット
しなくてはいけません…… つらい!!

また、HLODは
パーシスタントレベルのみで
編集作業が可能です。
今プロジェクトでは
右図のように背景は作業用に
別のパーシスタントレベルで
作業を行い、
正規パーシスタントレベルに
全レベルをぶら下げるという
フローを取っていました。
LOD
背景作業用
パーシスタントレベル
エリアA
エリアB
エリアC
ライティング
正規
背景作業用
パーシスタント
レベル
エリアA
ライティング
エリアB
エリアC
ゲームフロー
エネミー
VFX

何かの子になっている
レベルはHLODを
作成できません。
LOD
背景作業用
エリアA
エリアB
エリアC
ライティング
正規
背景作業用
レベル
エリアA
ライティング
エリアB
エリアC
ゲームフロー
エネミー
VFX

その為、別途HLODを
作成する為だけのレベルを作り、
HLOD作成を対応しました。
https://udn.unrealengine.com/questions/381355/view.html
LOD
背景作業用
エリアA
エリアB
エリアC
ライティング
正規
背景作業用
レベル
エリアA
ライティング
エリアB
エリアC
ゲームフロー
エネミー
VFX
HLOD作成編集専用
エリアA
エリアB
エリアC

また、ストリーミングを
行っている場合、
レベルが捨てられると
HLODも捨てられてしまうので
HLODのメッシュだけを
置いたレベルを
最終LODレベルとして
すげ替えて残しました。
LOD
元メッシュ HLOD
元メッシュ HLOD
レベルA
HLODのメッシュだけ
レベルA レベルB

しかし、
プレイヤーの挙動が早く
レベルBからレベルAの元メッシュに
即切り替わってしまう事があり
テクスチャ遅延を招く事が
ありました。
LOD
元メッシュ
レベルA
レベルB
元メッシュは
大量のテクスチャを
参照しているので
いきなり切り替わると
表示が間に合わない

そこで、レベルAを読む際は
参照しているテクスチャの
読み込み待ちをしてから
表示を切り替える、という仕組みを
PGさんにご対応頂きました。
LOD
元メッシュ
レベルA
レベルB
レベルAが使用している
テクスチャを
事前に登録しておいて
それらの読み込み待ちをする
事前登録はPGさんが
自動で行ってくれました。

また、
HLOD再生成の際に
以前のデータが消えず
ゴミとして残ってしまう
事がありました。
こちらはクラスタ削除をし
再度アクタ登録をし直して
HLOD再生成しないと
消えませんでした…。
LOD
クック後にも残りますつらい!!

また、HLODは生成の度に
個別のマテリアルが作成されるのですが、
ディザ遷移や色調整を
行いたかったので
専用の親マテリアルを作成して
運用しました。
いくつかのHLODに関しては
生成時にどうしても色が合わないので
ProxyReplaceで調整したりも
しました。
LOD
つらい!!

また、カットシーンにおいては
いきなりカメラが飛ぶことで
LOD遷移が間に合わない事が
ありました。
こちらは、専用のBPノードを
対象LODモデルにタグを仕込み、
カット単位で適宜オンオフすることで
対応しました。
LOD

インスタンス化は
マーケットプレイス販売の
プラグインを使用しています。
https://www.unrealengine.com/
marketplace/instance-tool
インスタンス
4.20よりインスタンスコンバートツールが
デフォルトでつきましたが
インスタンスとHインスタンスを指定できたり
スタティックメッシュに戻せたり
各種オプションが便利だったりします

インスタンスは
「HierarchicalInstancedStaticMesh」
「InstancedStaticMesh」
両方使用しています。
なるべくは
「InstancedStaticMesh」を使用して
LODが個別で欲しい場合のみ
を使用しています。
インスタンス

Foliageも使用していますが、
なるべく使用を避けて
で配置しています。
インスタンス
フォリッジはバグが多く、
何をどれだけどこに置いてるかも把握しづらく
置いていたフォリッジがズレたり
消えたり、原点に集約したり
レベルごと壊れて開かなくなったりなどあった為

また、フォリッジから
スタティックメッシュへの
変換ツールも拡張して頂きました。
インスタンス

「HierarchicalInstancedStaticMesh」は
それぞれアクタごとにLODの距離や
クラスタの数などを調整できるように
拡張して頂きました。
インスタンス
デフォルトではアクタ個々での設定ができず、
意図しないLODの切り替わりや
非効率的なクラスタリングをされていたので
それぞれ個別調整できるようにして頂きました。

また、HoudiniEngineを用いての
インスタンス化も行いました。
任意形状をボクセル化
するような場合に
すぐ結果が見れて便利でした。
インスタンス

カリングは
・事前カリング
・距離カリング
・オクルージョンカリング
全て使用しました。
カリング

事前カリングは局所的に使用しました。
ビルドが長く、メモリも食い、
さらにカリングが壊れた時のエラーが
ひどい為、運用には気を使いました。
カリング

また、HLODの例と同じく
事前カリングも
パーシスタントレベルでしか
ビルドができず、
非常に苦労しました。
カリング
背景作業用
エリアA
エリアB
エリアC
ライティング
正規
背景作業用
レベル
エリアA
ライティング
エリアB
エリアC
ゲームフロー
エネミー
VFX
ここでビルド
すると壊れる
こっちでビルド
しないと駄目

HLODでは
別のパーシスタントで
作業する事で回避しましたが
事前カリングは不可能でした。
他セクションと連携を取り、
特定のマップのみ、
正規パーシスタントレベルで
ライトビルドと
事前カリングビルドを
行いました。
カリング正規
背景作業用
レベル
エリアA
ライティング
エリアB
エリアC
ゲームフロー
エネミー
VFX
こっちでビルドしました。
ライトビルドも同時に
行う必要があるので
間違ってベイク対象に
なってるものがないかなど
プランナーさんにかなり
ご協力頂きました。

また、事前カリングボリュームは
デフォルトだと
サーフェスコリジョン上にしか
セルを作成せず
隙間だらけになります。
なのでPGさんに
ボリューム内をセルで埋める
オプションを追加して
頂きました。
カリング

事前カリングは、ストリーミングに非対応であったり
使用できる箇所は限定的でしたが
効果が大きい場所では
500～のDrawPrimitiveが削減され
オクルージョンカリングによるdrawハネを
～3msほど改善できたりしました。
ただし最大5~60MBほどのメモリを使用しました。
カリング

距離カリングはほぼ必ず
使用しています。
CullDistanceVolumeも
使用しましたが
最終的にはほとんど
アクタ単位でMaxDrawDistanceで
調整していたかと思います。
カリング

距離フェードマテリアルも
使用したりしましたが
基本見えない距離でパカっと
消しました。
キャラの移動速度が早く、
フェードしている間に
距離を詰められるので
消してしまった方が
見た目が良かった形です。
カリング

オクルージョンカリングは
UE4のデフォルトそのままです。
フレーム遅延などは
バウンズ調整したり、
要所でカリング切ったりしました。
室内で壁がカリングされて
ブルームが爆発するものには
目立たないよう黒い板を
置いたりしました。
カリング

ストリーミングは「レベル制作事例」でも
紹介されていましたが、局所的に使用しました。
レベル設計がストリーミングに向いていないものや
メモリや処理負荷の問題が少ないところでは使っていません。

ストリーミングの実装は
「マップセット」と呼ばれている機能で
実装しました。
主にプランナーさんが実装していて
レベルの組み合わせをエクセルで
管理し、切り替えをBPで実装しています。

ストリーミングが
使えなかったところでは
「アクターマネージャー」と呼ばれる
距離に応じてアクタ単位で
Tickや表示、コリジョンの
オンオフをする機能を使用しています。
ストリーミングと併用もしています。

背景の方では
ストリーミングに際しては
いきなり消えないように
レイアウトの調整や
レベルの分割、移動などを
行ったりしました。
ストリーミングのヒッチ対応の為に
アクタのマージや、レベル構成の変更も行い、
安定するまで中々苦労した印象です。

また、レベルストリーミングと並行して
テクスチャストリーミングでも苦労しました。

テクスチャ遅延は
カットシーンで顕著に発生しており、
（カメラがカットごとに移動する為）
また、カットシーンが長尺で
様々な箇所を写すので
事前にメモリに載せておく事も
できませんでした。

また、テクスチャストリーミングが
カメラの画角に非対応だった点も
問題となりました。
こちらは致命的だったので
画角対応を入れて頂きました。
TextureInstanceView.cpp
テクスチャが
来ない

ただ、結果として、
望遠時には大量のテクスチャリクエストが
かかることとなり、
これもまたテクスチャ遅延を
悪化させました。
（カットシーンでは望遠が多用されました。
一桁レベルの画角もありましたが、
これらの問題から最低二桁になるよう対応して頂きました。）
画面に写ってないものも
高MIPのリクエストが
かかってしまう

そこでカットシーンでは
カット単位でテクスチャのリクエストを
上書きする仕組みを構築して頂きました。
StreamingTexture.cpp

流れとしては
事前にカットシーンを流して
カットごとに使用されている
テクスチャとMIPを記録。
その記録したデータを使って、
順次先読みをかけていく、という
形です。
TexA
TexB
TexC
TexA
TexC
TexD
TexE
TexF
TexG
TexA
TexF
TexG
TexH
TexI
TexJ
CUT1 CUT2 CUT3 CUT4 CUT5
記録
TexA
TexB
TexC
TexA
TexC
TexD
TexE
TexF
TexG
TexA
TexF
TexG
TexH
TexI
TexJ
先読み
終わったら捨てる

カットごとの使用テクスチャは
「自動プレイのポストモーテム」
でも触れられてたとおり
カットシーン再生だけで
10時間以上かかるので
実機数台に分けて毎日記録しました。
TexA
TexB
TexC
TexA
TexC
TexD
TexE
TexF
TexG
TexA
TexF
TexG
TexH
TexI
TexJ
記録
TexA
TexB
TexC
TexA
TexC
TexD
TexE
TexF
TexG
TexA
TexF
TexG
TexH
TexI
TexJ
記録
TexA
TexB
TexC
TexA
TexC
TexD
TexE
TexF
TexG
TexA
TexF
TexG
TexH
TexI
TexJ
記録
実機１
実機2
実機3

毎日作成する必要があったのは
ライトマップをベイクしていた為です。
ライトビルドも自動で毎日走っており、
その度に記録したテクスチャデータが
壊れるので日々作り直す必要がありました。
テレインとキャラが優遇されており
ライトマップとシャドウマップは遅延しやすいです

ただ、それでも記録精度の問題などで遅延してしまう際は、
特定のテクスチャのみ手作業で登録したり
特定テクスチャグループのみ強制的にテクスチャブーストをかけたり、
キャラなどは最低MIPを引き上げたりもしました。
AsyncTextureStreaming.cpp
UpdatePerfectWantedMips_Async()

また、これらの対応に並行して問題となったのが
テクスチャプールオーバーでした。
先読みをかける事でプールが足りなくなることも多く、
その場合はテクスチャグループ単位で
読み込み上限を入れたりしました。

「自動プレイのポストモーテム」でも
触れられたように
テクスチャプールオーバーのチェックも
自動化して頂いており、
プールオーバーしていた場合は
TAがメモリ状況を確認し、
ボトルネックを把握、
予算を超えているセクションに
適宜注意喚起を行いました。
80
MB
80
MB
160
MB
160
MB
320
MB
100
MB
100
MB
100
MB
20
MB
キャラ背景 VFX UI その他
ノーマルベースカラー
トリプルマスク
ライトマップ
シャドウマップ
テクスチャプール(800MB)
大体の予算配分

ロード時間のレギュレーションは
平均15秒最大30秒でした。
（ワーストではなく平均的なHDD読み出し速度で測定）
ロード時間

ファイルオーダーは使用しました。
（プレイデータは自動プレイで作成）
効果は大きく平均で-6秒。
最大だと-17秒のロード時間改善が
ありました。
ロード時間

また、ワールドセッティングに
ワールドコードという設定を追加し
相互に移動が多いだろうマップでは
共通しているアセットをリスト化して
保持するようにしました。
効果は平均で-1秒。
最大だと-13秒のロード時間改善が
ありました。
ロード時間

また、マップジャンプ前にプレイヤーなどの主要なクラスや
スタティック、スケルタルメッシュなど数が多いものを、
GameInstanceなど必ず生きているオブジェクトから参照させ、
マップジャンプ後に外すことで
ロード時間の短縮を行ったりもしました。
ロード時間

アセットレジストリは使用していません。
総アセット数がとても多く（クック後40万アセット超）
メモリを80MBも使用した為です。
ロード時間
BaseEngine.ini

作成アセット数の内訳は大体以下のような感じです。
ロード時間
約4万約8万約12万約11万
キャラ背景 VFX サウンド UI その他
約1万約4万

作成アセット数の内訳は大体以下のような感じです。
ロード時間
約4万約8万約12万約11万
キャラ背景 VFX サウンド UI その他
約1万約4万
メッシュ
20000
テクスチャ
55000
マテリアル
25000
umap
5000
その他
5000
クック後のuasset、uexp、ubulkの数なので
実際の作成数は1/2ほどになるかと思います。
背景アセットの内訳は大体以下のような感じです。

ディスク容量に関しては
ほぼ背景のテクスチャがボトルネックでした。
ディスク容量

各セクションの容量は
制作中の容量から
適宜予想して算出、
配分されていました。
ディスク容量

背景はその中でも
かなり多めに予算をもらって
いたのですが
（ブルーレイディスクの半分以上。）
開発中盤に予算超え。
ディスク容量

データメンテナンス編でも
触れられていましたが、
各マップごとに容量を可視化して
適宜対応していきました。
ディスク容量

容量の大半（７～８割）を占めていたのはテクスチャ。
テクスチャは圧縮効率があまり良くない上に
ライトマップやシャドウマップをベイクしているのも相まって
総量が増え、ボトルネック化していました。
ディスク容量

容量削減対応としては、基本的には
見た目が許せるギリギリまで
「MaximumTextureSize」を
下げて頂きました。
ライトマップ、シャドウマップに関しては
一括でのScalingオプションを拡張して頂き
こちらもベイクエラーのギリギリまで
削減して頂きました。
ディスク容量

また、天球画像には
HDRかつパノラマ展開されたものが
使用されていたので、
映っていない下半分を削ったりしました。
（4k*2k→4k*1kにして
マテリアルでミラーリングしました。）
ディスク容量

また、背景のマスターマテリアルが
BaseColor
TripleMask
Normal
と、3枚のテクスチャを使用する
構成になっていたのも
容量が大きい一因でした。
こちらはテクスチャ使用を抑えた
マテリアルを別途用意して
ニーズに応じて切り替えて
頂きました。
ディスク容量

ノーマルに関しては、BC5で運用していたのも
容量が大きい一因だったので、
DXT5にしたり、RGチャンネルにパッキングしたりもしました。
ただ、こちらはブロックノイズや対応コストの問題などで
局所的な対応で留めています。
ディスク容量

また、これらの対応を含めて
背景のマテリアル数はかなり増えました。
最終的には背景のマスターマテリアルは
約1000種、容量250MBになりました。
ただ、一度にメモリに乗せるのは
50個ほど（約10MB）で
適宜状況に応じて使い分けて運用しました。
全てのマテリアルは背景TAがリスト管理し
お互いに情報共有し合って
統合可能かどうかなどすり合わせました。
ディスク容量

また、メッシュの方の対応として
Adjacency Bufferと
Reversed Index Bufferの
生成をやめました。
アセット数が多かったので
数百MBほどの容量削減になったかと
思います。
ディスク容量

最終的には背景は
当初の容量配分43000MiBを大きく下回り
33000MiBとなり、
想定以上の容量削減を行えました。
ただ、容量対応というよりは
プールオーバー対応などメモリ対応が厳しく
それに合わせていくうちに
容量もどんどん減っていった印象です。
ちなみに他セクションは概ね容量配分通りでした。
ディスク容量

ワークフローに関しては
制作時に役立った、小さな事例を
色々ご紹介させて頂こうかと思います。
ワークフロー

対応プラットフォームが多く、それぞれスケーラビリティも違うので
エディタ上で、各プラットフォームごとの描画状況を
簡単に切り替えて見られるようにして頂きました。
ワークフロー
エディタ拡張

また、背景制作における
細かな拡張メニューを追加して頂いたり、
エディタオンリーの管理タグを
追加して頂いたりしました。
ワークフロー
エディタ拡張

ブループリントも
適宜使用しています。
コンストラクション
スクリプトによる配置や、
ブルーティリティによる
ツールも作成しました。
ワークフロー
ブループリント

レベルブループリントも要所で使用しています。
基本的にはイベントドリブンで
ゲーム進行に応じてライティング環境を変えたり、
マテリアルパラメーターコレクションを変更したりなどしました。
ワークフロー

ただ、一部デバッグや実験目的で
キーバインドや
BeginPlay、Tickが使用されており、
「レベル制作事例」でも紹介されたように
開発終盤に謎のバグを生んでしまいました…。
ワークフロー

その為、PGさんに
レベルBPが仕込まれている
全レベルリストを出して頂き、
全て「手作業」で「目視」で
確認しました。
さらに後に変更が加えられてないか
確実に確認するために
スクショも取って目diffしました…。
ワークフロー
レベル総数2000超
背景に関するレベル1000超
うち何かしらのレベルBPが
あったのは150ほどでした
古くは5年以上前に仕込まれており
担当者が退社しているものも
ありました…

バッチも大量に用意して頂きました。
様々なエディタ起動オプションや、
リネーム、クック、キャッシュ削除、
エラーチェック、圧縮…と
200以上のバッチが作成されました。
ワークフロー
バッチ

コマンドレットも大量に作成して頂きました。
指定フォルダ以下のアセットのリファレンスを一括で出したり、
マテリアルインスタンスの使用パラメーターを調べたり、
マテリアルのノードの設定を一括で変更したり……
使い捨てとも言える色々なものをご対応頂きました。
ワークフロー
コマンドレット

テクスチャに関しては、テクスチャグループやCompressの設定を
間違えたり設定し忘れたりするので
フォルダ単位で判定してある程度自動設定されるようにして頂きました。
ワークフロー
テクスチャ設定自動化

ライトベイクは大量のマップをベイクする必要があったので、
夜のうちに自動ベイク＆サブミットするようにして頂きました。
指定のテキストにパスを書くだけで翌朝にはライトビルドされます。
最大時には毎夜50を超えるマップがライトビルドされていました。
ワークフロー
ライトベイク自動化

1マップあたりのベイク時間は30分以内をレギュレーションとしていました。
（大量のマップを朝までにベイクする必要がある為）
ただ、いくつかのマップはどうしても削れず、最大は2時間弱でした。
ワークフロー

ライトビルド時間の短縮には、
統計とswarmのログを見て対応しました。
大体の場合は、いくつか飛び抜けた
アセットがボトルネックになっているので
それを分割したり、精度を下げたりしました。
ワークフロー

swarmに関してはベイクマップ数が少ない頃は
背景アーティストのみで運用していましたが、
最終的にはチーム全体で協力して頂きました。
（最大時数百台規模で運用していました。）
ただ、他セクションの方からは
中々協力を得にくかった為、
PGさんにエディタ立ち上げの際に自動で
swarmをスタートアップに登録する
バッチを仕込んで頂き
半強制的にご協力頂きました…。
ワークフロー

ただ、日中Swarmが起動していると
作業時に諸々のリソースを奪ってしまい
迷惑がかかります。
その為、普段はCPUを0コアにしておいて
帰宅後PCロックがかかると
フルコア使うように拡張して頂きました。
ワークフロー

また、それでCPUに関しては制限できたのですが
メモリに関しては制限方法がありませんでした。
メモリはワースト時2～30GB奪われることもあり
作業に著しい支障をきたしていました。
ワークフロー

これは例えばフォリッジなどで
大量のインスタンスをばら撒いたりすると
それらがライトベイク時に
コリジョンメッシュとして扱われ、
メモリが爆発してしまう為でした。
（ランタイム時にはカリングなどで
最適化され問題がないのですが、
ライトベイク時には
全てメモリに乗ってきます。）
ワークフロー

そこで、あまりに大量の頂点を扱っている場合は
LOD0にライトベイク用のローメッシュを入れて、
描画時はLOD1から使うようにしました。
ワークフロー

自動ライトビルドが行われた後は、自動ナビビルド、
自動スポーンポイントビルド、を引き続き行い
最終的にクック、パッケージ作成まで自動化されてました。
ワークフロー
ライトナビ
スポーン
ポイント
クックパ
ッ
ケ
ー
ジ
完
成
3時間 30分 10分 6時間

自動化タスクはjenkinsから実行され、
結果がメールとチャットで報告されます。
非常に便利だったのですが、幾つかあった問題点としては、
・自動ビルドは対象マップのチェックインが必須だったが
忘れられてビルド失敗することがあった（ヒューマンエラー）
・swarmで稀にタスク分散されない事があった（原因不明）
・swarmで稀に分散時にタスク終了しないことがあった（原因不明）
ワークフロー

また、自動ライトビルドに関しては、
コマンドレットが当時正常に動作しなかった為
Automationコマンドの方で実装されています。
他に、
ライトマップは連続ベイク時ゴミを残す事があった為
・1回目「Force No Precomputed Lighting」を
オンにしてビルドしてゴミを消す
・2回目通常通りライトビルドする
の2回ビルドを行っていました。
ワークフロー

クックに関しては、40万を超えるアセットをクックしなくてはならない為、
色々な高速化を対応しました。
・ m.2 NVMe SSD の使用
・大量のメモリ（物理メモリ 64GB ＋仮想メモリ 150GB）
・ GC が入らないようにする
・ GC が入らないようにすると Cook 終了時に非常に時間がかかるので、
強制的に終了させるようなオプション追加
・ Cook 終了時に走る VerifyEDL をスキップできるオプションを追加
・ Disk IO の最適化
（ Cook 処理中はなるべく Cook 以外の Disk IO が入らないようにする）
これらで、キャッシュがフルに効いている状態で6時間くらいでした。
ワークフロー

今プロジェクトでは、
背景においてもHoudiniを様々な形で運用しました。
Houdini

破砕
Houdini

ピボットペインター
Houdini

積雪
Houdini

モデル破壊
Houdini
https://2018.cedec.cesa.or.jp/session/detail/s5abdfffa58d45

雲
Houdini

フローマップ
Houdini

ビルボード
Houdini

テレイン
Houdini

HoudiniEngineも使用しており
verはUE4.17.0 Houdini16.5.349
主にインスタンシングなどに使用しました
Houdini

Houdiniは非常に強力なツールで
今プロジェクトにおいては局所的な運用に留まりましたが、
それでも有効だったと考えています。
UE4との相性も良いと思いました。
Houdini

そして、最後になりますが、
宣伝をさせて頂けましたらと思います。
Houdini

プロジェクト終了後、
先程の背景におけるHoudini運用を
さらに拡大した検証を行いました。
Houdini

Houdini

アーティスト主導でHoudiniを運用し、
プロシージャルに「1000の和室」を作成しました。
Houdini

これまではHoudiniは
主にTAが運用していましたが
それをアーティストメインで
背景全体のワークフローに
拡大して検証。
詳細は2019/3/10発売の
CGWORLDに掲載しております。
Houdini

さらに
Houdini

4/20のUnrealFestWestでも
その詳細について登壇させて頂きます。
Houdini
http://unrealengine.jp/unrealfest/

HoudiniとHoudiniEngineの連携、
UnrealPythonによる自動化、
NiagaraとHoudiniの連携、など
プロシージャル背景制作に関して
諸々共有させて頂く予定です。
Houdini

ご都合合えば、
是非是非お越しいただけましたら幸いです。
Houdini

ご清聴ありがとうございました！
UNREALはエピック・ゲームズ・インコーポレーテッドの商標または登録商標です。
ElasticsearchおよびKibanaはElasticdearch BVの商標または登録商標です。
MAYAはオートデスクインコーポレイテッドの商標または登録商標です。
その他掲載されている会社名、商品名は、各社の商標または登録商標です。

UE4における大規模背景制作事例最適化ワークフロー編

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to UE4における大規模背景制作事例最適化ワークフロー編

Similar to UE4における大規模背景制作事例最適化ワークフロー編 (20)

More from エピック・ゲームズ・ジャパン Epic Games Japan

More from エピック・ゲームズ・ジャパン Epic Games Japan (20)