UE4におけるエフェクトの基本戦略事例後半

V F X S T U D Y G R O U P©2019 SQUARE ENIX CO., LTD. All Rights Reserved.
株式会社スクウェア・エニックス林武尊
U E 4 におけるエフェクトの基本戦略事例 :後編

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

呼称・略称について
・『Unreal Engine 4』をスライド内では『UE4』と記載しています
・『PlayStation®4』も同様に『PS4』と記載しています
・『エフェクト』の単語は Particle System を表してます

アジェンダ:後編

• 自己紹介
• 前提条件
• 基本戦略
• UE4の拡張
• 特殊表現
アジェンダ:後編
• 環境
• レギュレーション
• 検証したこと
• ディスク容量
• メモリ、処理負荷

レギュレーション

• 基本方針
• ガチガチに固め過ぎない
• シンプルなレギュレーション
• やりたい＆求められるビジュアルの実現を重視

• 基本方針：反省点
• ガチガチに固め過ぎない
⇒ 終盤の最適化に苦労
• シンプルなレギュレーション
⇒ 開発が進むにつれどんどん複雑に‥
• やりたい＆求められるビジュアルの実現を重視
⇒ ワンオフ(専用品)のものばかりになりアセットが大量に

全てが手探りだったので
開発後半までレギュレーションを固められずにいた

なので、特に同じような境遇の方には
一例として参考になればと‥

• 今後は
• レギュレーションを守りやすいように
自動化や制限がうまくできるところは移行していく
（でもディストピアな感じにはしたくない）
• アセットはもっとシンプルに＆もっと汎用性を高めたい
• データサイズや処理負荷の知見を活かしたい

具体的にどんなレギュレーションだったか？

テクスチャ、マテリアル、メッシュに関しては
DeepDiveでの講演資料もご覧ください
『大規模タイトルにおけるエフェクトマテリアル運用』
https://www.slideshare.net/EpicGamesJapan/sqex-ue4dd

ざっくりと言えば‥

• テクスチャ
• テクスチャストリーミングとMipmapの基本仕様を把握する
• テクスチャの解像度は必要最低限
• NoMipmapはなるべく使用しない
• テクスチャアクセスの効率やメモリ使用効率が主な理由
• NeverStreamはできる限り使用しない
• メモリを常に最大限圧迫してしまうので

• テクスチャ
• テクスチャストリーミングとMipmapの基本仕様を把握する
• Epic Games Japan 篠山さんより解説資料を公開予定とのこと

• テクスチャ
• マテリアルがシンプルになるようテクスチャの運用を考える
• Sampler Typeをなるべく絞る
• 基本的にモノクロのテクスチャを「Alpha (BC4)」で運用
• テクスチャのUVを歪ませるのもモノクロテクスチャを流用
• カラーはBC1とBC7を使い分ける
• 非圧縮推奨のテクスチャもBC7にする

• テクスチャ
• 解像度は小さければ小さい方が良い
• 単色は1*1、直線グラデーションは1*256とか
• 基本的に最大1024*1024が目安
• SubUVアニメ用なら最大2048*2048が目安
• クロスフェード切り替えが優秀なのでできるだけ間引く
2048*1024にしたり

• テクスチャ（施策）
• インポート時のデフォルト設定を一部変更
• Config¥DefaultEditorPerProjectUserSettings.ini
• エフェクトアセットの保管フォルダにインポートされた時
• Texture GroupをEffectsにする
• Compression Settingsを変えたりも可能
• 各スタッフのDevelopersフォルダもカバー

• 定期的にプロパティマトリクスでチェック
• レギュレーションが守られているか
• 解像度、圧縮タイプ、NoMipmap、NeverStreamなど
• 定期チェックとリストアップを自動化できると尚良い

• 解像度が大きいテクスチャを発見したら
ゲームを実行しながらMaximumTextureSizeを変えて
許せるレベルまで落とす
• インゲームは特に512や256まで落としても気にならない場合が多い
• 特に汎用的に使われないテクスチャは32とかギリギリまで落とす

• マテリアル
• エフェクトチームの誰でも作成OKなルール
• エフェクトは特殊な表現を求められることが多い
• そのためマテリアルがワンオフ（専用品）になりやすい
• ただし、メモリに常駐させるマスターマテリアルは私が用意する形

• マテリアル
• エフェクトチームの誰でも作成OKなルール
• メリット：
チーム全体でマテリアル作成スキルが身につき底上げになる
• デメリット：
作成して良い数などしっかり制限して管理しないと数が溢れてしまい、
後から最適化するのは非常に大変

• マテリアル
• マテリアル数を減らすためにもBlend Modeは少ない方が良い
• 半透明のBlend ModeはAddは少なめ、Translucency中心
• 不透明はOpaqueとMaskedを使い分けたが
マテリアル数を減らすためにMaskedで統一した方が良かったかも

• マテリアル
• 同様に数を減らすためにShadeing Modelも少ない方が良い
• 汎用マテリアルは基本Unlit、一部でDefault Lit‥の２つのみ
• 人によっては氷でSubsurfaceを使ったりはしている

• マテリアル
• 半透明のライティングは基本無しの方針
• 煙のテクスチャには陰影が描き込まれている
• ただし場所を限定しないものは「エリアカラー」で環境に馴染ませつつ
ライティングしていたものが多い
その際、TranslucencyLightingVolumeは根元からオフになったので
「Surface ForwardShading」でライティング

• マテリアル
• Render After DOF（旧Separate Translucency）は基本無し
• ただしカットシーンでは必要に応じて使用
その分、マテリアルが増えることになるので注意が必要

• マテリアル
• 基本的にEmissive Color値は露出補正による影響を打ち消す
• 仕組みとしてはEyeAdaptationノードで除算するだけ
• 拡張でチェックボックスを追加してもらったのでONにすればOK
• SceneTextureを使ってブラーを表現するものなど
一部でエラーが出たものだけ例外でOFFに

• マテリアル
• 基本的にUsageは主な３項目をONにしておく
• 「Particle Sprites」「Beam Trails」「Mesh Particles」
• 理由は、常に最低限しか設定しない方針だと、後から利用先が増減する
度にマテリアルを更新するのは無理だと思ったから
• しかも汎用マテリアルは私しかサブミットできなくしてもらっているので
• デカール用のマテリアルのUsageは全てOFFにする

• マテリアル
• 原則として触ってはいけないもの
• Apply Fogging（OFFにしたらダメ）
• Disable DepthTest（ONにしたらダメ）
• Render After DOF（インゲームではONにしたらダメ / 前述）‥など
問題のある設定のものが知らずに複製されたりもするので注意が必要

• マテリアル（施策）
• 定期的にプロパティマトリクスでチェック
• プロパティマトリクスでマテリアルを検索可能にする対応があった
• 開発終盤にエフェクトのマテリアルの主要パラメータを
CSVで出力する機能を追加してもらった
• 特定のプロパティの値を一括変更するコマンドレット
• 必要に応じて作ってもらい、実行

• マテリアル
• 屈折について
• 背景オブジェクトでは屈折の使用を避けてもらえた
SceneTextureを使った疑似屈折でカバーしていた
• 半透明描画の後に処理されるため、水面を走った際の波紋が
バトル中のエフェクトを巻き込んだりするが許容
• GPUに余力があるなら屈折を描画するタイミングを
半透明描画前と後の二回に分けるのもあり？（費用対効果次第で）

• スタティックメッシュ
• UVは１つのみ
• コリジョンは不要
• なるべく頂点数を減らす
• 連番メッシュの場合はなるべく少ないパターンにする

• スタティックメッシュ（施策）
• インポート時のデフォルト設定
• Config¥DefaultEditorPerProjectUserSettings.ini
こちらで設定できることに気付いていなかった
• Auto Generate CollisionとGenerate Lightmap UVsをONに
してしまっているスタティックメッシュが後から結構見つかった
⇒ コマンドレットでLighitmapUVとコリジョンを一括削除（後述）

• スタティックメッシュ（施策）
• キャラクターの発光演出、武器出現＆消滅演出などのための
メッシュは万単位の頂点になるのでできるだけ削減
• Houdini Engine for Maya により、Maya上でHoudiniの
高性能なポリゴンリダクション機能「PolyReduce」を
使えるようにしてもらってチーム内で使用

• エフェクト（Particle System）
• エミッター数の目安
• 親子関係を構築できるのでエミッター100超えなど簡単にできてしまう
• ヒットエフェクトで5個
• それ以外でも20個以下
• 画面内に１つのみの大技でも80個以下 ‥のような目安を設定

• GPUパーティクル数の目安
• CPUパーティクルで生成数が100を超えるならGPUに切り替える
• 短いフレーム数で一気に大量に生成しないよう注意喚起
• 約26万個が上限
• 常にメモリ上で確保されるGPUパーティクル計算用のバッファサイズを
デフォルトの 1024*1024 から 512*512 に下げられるように
元々は100万個ほど出せる

• カラーモジュールで与えるEmissiveColorの値の目安
• 実際には輝度というよりもブルームの強さの目安
• リードによる見た目での目安をドキュメント化
描画される面積でブルームの強さが変わるため、見た目での提示

• カラーモジュールで与えるEmissiveColorの値の目安
• InitialColor*ScaleColorで輝度が∞になって色飛びが起こったり‥
ポストプロセスのブラー等の兼ね合いで色飛びが起こったり‥
その都度、描画プログラマに対処してもらった

• ポイントライト
• 「特別感を出す」ために使用場面を限定
• 使用する場合でも基本的に１つのParticleSystemで１個
• 見た目を重視して二乗減衰させないルール
• 二乗減衰だとライトの影響範囲を大きくしたり強度を上げざるを得なくなる
• 強度を上げるとキャラや壁に近い時に強く照らし過ぎる

RGB 100, 50, 10
二乗減衰ON 二乗減衰ON 二乗減衰OFF
RGB 700, 350, 70 RGB 1, 0.5, 0.1
Light Exponent 4
二乗減衰OFF
RGB 0.5, 0.25, 0.05
Light Exponent 3

• 半透明オブジェクトへの影響とキャストシャドウは無し（負荷軽減）
• ライトの影響範囲はできるだけ狭く（負荷軽減）
• リードによる輝度の強さの目安あり（Colorに1以上与えない）
• 露出補正に対するライトの照らし具合のカウンターを入れてもらった
• オブジェクトを照らして返る値に対してのカウンター

• UE4標準のLOD
• 設定の自由度が高い反面、作業がとても煩雑になる
• LODが設定されていることが一目で分からない
• 複製した際にLODが設定されていることに気付かない
• それによりミスが多発する
• バトルエフェクトとカットシーンでは使用を禁止

• UE4標準のLOD
• ただし背景エフェクトでは細やかな設定が必要な際に使用
• LODが設定されていて、最大LOD時にパーティクル発生数が０の場合
「最大LOD時に計算を止める」フラグを入れてくれた
100個以上設置されていた背景エフェクトで1msほど下がるケースがあった
（初期の頃のケース / その後はサブレベルのロード・アンロードで対応したり）

• バウンディングボックスを許容できる最低限に設定
• カリング効率を良くするため
• 固定サイズを設定
• デフォルトでONにしてもらった
• エフェクトのコア要素をカバーすればOK
• 周囲に飛び散る粒子をカバーする必要はなし

• バウンディングボックスを許容できる最低限に設定
• バウンディングボックスの中心がParticleSystemのソートに使用される
• バウンディングボックスが画面外に完全に出ると描画しなくなる
• SecondsBeforeInactiveで画面外に出てから指定秒で計算が止まる
• ０秒で無限 = 計算を止めない
• 10秒にしていた
• 短い秒数の場合、鏡の中に写り込んだエフェクトが止まったりするので注意

• エフェクト（施策）
• エミッター数をCascadeのプレビュー上に表示
• 数が増えるにつれフォントが大きくなっていき色も赤くなっていく
• 注意が必要な設定をしている場合にはWarningメッセージを表示
でも気付かないので保存時にメッセージボックス表示の方が良さそう

• エフェクト（施策）
• 色飛びなど不具合が出た場合に少しでも自力で原因を調べる
• エディタ上で起こる場合
• 実機でも起こるか確認
• RenderDocでどの描画タイミングでおかしくなっているかざっくりチェック
キャプチャデータを描画プログラマに渡して見てもらう
• 実機でのみ起こる場合
• RazorGPUでキャプチャして同様に見てもらう

• エフェクトのアタッチ
• キャラクターにエフェクト専用に独自にアニメーションを
設定可能な骨をルートの子として１つ追加してもらった
• 例えばキャラクターを周回するアニメーションとか
• 大抵はルートからのオフセットや各骨へのアタッチで賄えるが例外用
• 稀に有用な場面があるという感じで、たまに使用した

• 半透明オブジェクトのソート
• 背景では半透明の使用は極力控えてもらえていた
• 川、池、海、ビルの窓ガラスなど一部でのみ使用
• カメラが回り込まないものであれば優先度の設定でカバー可能
• キャラ、背景、エフェクトで優先度設定について取り決められた
• プルダウンで設定可能に拡張

• 半透明オブジェクトのソート
• バトルエリア周囲の半透明壁をエフェクトが突き抜けるような場合は
優先度設定でカバーできないが許容（レアケース）
半透明壁（優先 -100）
エフェクトの弾（優先 0）
壁を突き抜けても
手前に描画される

• アセット全体的なこと
• コンテンツブラウザでアセットを削除する際の「強制削除」
• 問題ないアセットであっても参照エラーが出るので禁止ルールにするか、
行ったら必ず参照元を再保存するルールにした方が良さそう

検証したこと

検証したこと
大量にあるので一部だけ‥

• Particle Cutout
• パーティクルをテクスチャの抜きに合わせてカットする
UE4.11で実装された機能（カット時の頂点情報は事前計算）
検証したこと

• Particle Cutout
• 検証した当時、分割のされ方に不具合があった
またSubUVのクロスフェード時の対応も完全ではなかった
• 事前計算したデータは別アセットになるため、管理するアセット
が増えるデメリットがある
• 以上から検証はしたものの使用は見送った
検証したこと

• 半透明の動的な解像度変更
• PS4®Pro対応時に検証（ノーマル 900p / PS4®Pro 1080p）
• 半透明を専用のバッファに描画してからシーンに合成
• 半透明の描画負荷が高い状態が一定時間続くと
半透明バッファの解像度が下がる
• 最終的に無しになった（半透明バッファ撤廃）
検証したこと

• 半透明の動的な解像度変更（もうちょっと詳しく）
• どのような感じで切り替えていたかというと‥
• Translucencyの描画パスで平均5msを超えると50％になる
• 平均1.5msになったら元に戻す
• 平均の処理時間は30フレーム分の平均で算出
• フルHDと解像度75％はほとんど違いが分からない
（デフォルトで75％ ⇒ 高負荷時は50％が良さそうと思った）
検証したこと

• 半透明の動的な解像度変更（もうちょっと詳しく）
• 問題点
• 動的に解像度が下がると描画負荷の調べにくくなる
ONで調べてOFFで調べて‥
• 大丈夫だと思うとさらに贅沢に作ってしまう可能性も
• 解像度が下がる = 品質が下がる
最初から頼りにせず最適化の手を打って最後に検討すべきという意見も
検証したこと

• デカールとの境界にアーティファクトが出る問題
• 公式ドキュメントでも取り上げられている
• Decal アクタの操作ガイド
http://api.unrealengine.com/JPN/Engine/Actors/DecalActor/
検証したこと

• デカールとの境界にアーティファクトが出る問題
• マテリアルがMaskedのオブジェクトとデカールの境界にアー
ティファクトが出る問題（UE4の問題ではない）
• デカールに使用しているテクスチャをNoMipmapにすれば
回避できるが、NoMipmapは基本無しのルール
• カットシーンで目立つ場合のみNoMipmapを検討してもらった
検証したこと

• テクスチャのプロパティにあるPreserve Border
• Mipmap生成時にフチの色を高解像度ミップに近付ける機能
検証したこと

• Mipmap生成時に処理するのでランタイムのコスト無し
• パーティクルのミップレベルが上がった際に困った見た目になる
場合にはとても有用なのではと思う
• しかしこの機能を知ったのが終盤だったので一部のみで使用
検証したこと

• デカールで使用した場合、深度差のある部分にアーティファクト
が出てしまう問題が出た
検証したこと
Preserve Boarder OFF Preserve Boarder ON

ディスク容量

• 開発途中で全パートのディスク容量の試算が４度あった
• エフェクトの１度目の試算 ‥ 3151 MB (非圧縮)
• エフェクトの２度目の試算 ‥ 2086 MB (非圧縮)
• エフェクトの３度目の試算 ‥ 1484 MB (非圧縮)
• エフェクトの４度目の試算 ‥ 2797 MB (非圧縮)
• こちらに圧縮が入ることを想定した係数を掛けて算出
ディスク容量

• 試算の仕方
• 各カテゴリごとに最終的に制作するデータ総数をリストアップ
• プレイヤー、敵、NPC、レベル、カットシーン、常駐アセット‥など
• 各カテゴリごとに平均のファイルサイズを出す
• それまでの制作物を非圧縮と圧縮それぞれクックして算出
• 制作物が少ない場合は平均的なボリュームのアセットの値を参考にする
• 現在の合計サイズ +（平均サイズ * 未制作データ数）
ディスク容量

ディスク容量
終盤10ヶ月はほぼ毎週、全エフェクトアセットを
非圧縮でクックしてサイズと個数を出して共有した

ディスク容量
終盤10ヶ月はほぼ毎週、全エフェクトアセットを
非圧縮でクックしてサイズと個数を出して共有した
不要なアセットを一斉退避
最適化をがっつり行った時期

• 全エフェクトアセットをクックしての集計は‥
• 参照されていないアセットもあるが全アセットをクックした
• 未実装のエフェクトを先行して作成していたりするため
• 使用しないアセットで圧迫気味になった方が危機感を煽れる
• C#で集計ツールを作って利用した
• 次回は自動で定期チェックして集計するようにしたい
ディスク容量

ディスク容量
最終的には
1691 MB (非圧縮) / 21229 個
※全アセットのクックで調べたもの

ディスク容量
1691 MB (非圧縮) / 21229 個の内訳は‥
• PC
• 武器
• 魔法
• 召喚
• 味方
41 MB
180 MB
49 MB
30 MB
42 MB
• 敵
• レベル
• 常駐
• 汎用
• その他
282 MB
852 MB
71 MB
109 MB
84 MB
574 個
2201 個
412 個
456 個
523 個
3961 個
10632 個
966 個
1058 個
1446 個
※レベルにはカットシーンも含まれる

• ここでの常駐について補足
• メモリに常駐させるアセット
• テクスチャ、マテリアル、マテリアルインスタンス、スタティックメッシュなど
• ただしテクスチャの高解像度ミップマップはストリーミング
• NeverStreamに設定したものは１つだけ
• なので総容量の 71MB 全てが常駐される訳ではない
ディスク容量

ディスク容量
予想と比べると‥

ディスク容量
1691 MB (非圧縮) / 21229 個の内訳は‥
• PC
• 武器
• 魔法
• 召喚
• 味方
41 MB
180 MB
49 MB
30 MB
42 MB
• 敵
• レベル
• 常駐
• 汎用
• その他
282 MB
852 MB
71 MB
109 MB
84 MB
49 MB
244 MB
68 MB
50 MB
59 MB
474 MB
1178 MB
194 MB
151 MB
331 MB
※レベルにはカットシーンも含まれる
予想値予想値

ディスク容量
アセットのタイプごとの個数は‥
• Particle System
• Static Mesh
• Material Instance
• Material
• Material Function
• Texture
• Data Asset
• Blueprint
8688 個
4024 個
5970 個
1233 個
170 個
1587 個
413 個
262 個

未使用アセット撲滅期間

終盤にエフェクトチーム内で実施した
「未使用アセット撲滅期間」について

ギリギリまでデータを制作していたので
制作と平行して実施

「そのアセット、本当に使用されてますか？」

未使用のBlueprintやモーションで
参照されているエフェクトがあった場合‥

製品で使用されるエフェクト内に
非表示のエミッターがあった場合‥

マテリアルで未接続のテクスチャ参照があった場合‥

ディスクやメモリに載るものの
全く使用されないアセットが存在する可能性が（！）

• まず行うこと
• 未使用となったBlueprintの退避依頼
• 未使用となったアニメーションの退避依頼
• 未使用エフェクトの退避
• オートメーションツールで参照数をリストアップ
• 参照数が０のものを対処
• ただし実装予定のものを削除しないよう注意が必要

• 次に行うこと
• 非表示エミッターの削除
• コマンドレットで指定フォルダに対して一括で削除可能
• ただしFIXしているエフェクトに限る必要があるため
進捗に応じて段階的に実施していった
• 結果的に1300個ほどのエミッターを削除できた

• その次に行うこと
• 未使用のテクスチャ・マテリアル・メッシュの退避
• 未使用メッシュを退避したら未使用マテリアルが増えたり‥
未使用マテリアルを退避したら未使用テクスチャが増えたりする
なので参照数を出しては退避を何度も繰り返し行う必要がある

• 他に行ったこと
• 各種コマンドレットの実行
• スタティックメッシュのLightmapUVを一括削除
• スタティックメッシュのコリジョンを一括削除
• エフェクトのIndirectLightingCashを一括でOFFにする（後述）

• マテリアルのマージ作業
• 「見た目が全く変わらない」ことを条件に統合していった
• 「ほとんど同じ構成で統合できる！」というものは一握りだった
一見、構成が同じでも微妙に内容が違って統合が難しいものばかり
• チェックが通ったエフェクトの見た目が変わるリスクもある
実際、やってしまって元に戻すということが何度か発生‥

• マテリアルのマージ作業
• 手順としては、まずエフェクトの全マテリアルの主な情報をCSVで出力
• Exelで「LightingModel」や「BlendMode」ごとにシートを分けて
同種のマテリアル内で１つ１つ開いてマージを検討
• 全く同じ構成だけどRender After DOFがONとOFFのものがあったりと
マテリアルの基本パラメータ違いもあるので作業時に注意を要した

• サイズが目立って多いアセットの調査
• 全エフェクトアセットをクックしてリストアップ
• ２MBを超えるアセット 52個・計308 MB
• これらを１つずつ調査、担当者に最適化してもらった
• ２MBを超えるアセット 30個・計102 MBになった（約200 MBの削減）

• サイズが目立って多かったアセットの例
• インポスター用のテクスチャA 42.7 MB
• インポスター用のテクスチャB 5.3 MB
• 26万頂点のメッシュ 34.8 MB
• 16万頂点のメッシュ 21 MB
• VAT用のテクスチャA 13.8 MB
• VAT用のテクスチャB 13 MB
• HDRのハイトマップ 10.7 MB（BC6H にして 1 MBに）

以上が「未使用アセット撲滅期間」で行ったこと

ちなみに、DeepDiveの資料で詳しく触れているが
テクスチャ、マテリアル、メッシュの命名規則で
先頭に作成者を識別する１文字を与えた
こちらが非常に重宝した
『大規模タイトルにおけるエフェクトマテリアル運用』
https://www.slideshare.net/EpicGamesJapan/sqex-ue4dd

数十～数百のアセット名が並んだリストで
エラーが出ているもの、サイズが大きいものなど
ピックアップした時に担当者が一目で分かるので
アセット名でソートして、担当者に
「確認してください」とすぐ知らせることが可能
今後は担当者情報を自動で埋め込んで
スマートに参照できるような形にしたい

メモリ

メモリ
開発初期の頃のプログラマからの目安はこちら
メインメモリ（VFX）： 50MB
テクスチャプール（VFX）： 100 MB

メモリ
開発後半に最適化チームから予算の提示をもらった
マテリアルの予算 150 MB を超えるレベルが多く
エフェクトのマテリアルが圧迫の原因になっていた

メモリ
その時期、エフェクトのマテリアルが 1500個以上
※マテリアルインスタンスの数を含んでません

メモリ
繰り返しになるがエフェクトチームでは
みんながマテリアルを作成する

UE4におけるエフェクトの基本戦略事例 後半

More Related Content

What's hot

Similar to UE4におけるエフェクトの基本戦略事例 後半

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