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個以上
※マテリアルインスタンスの数を含んでません

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

メモリ
開発中盤に「敵１体につき専用マテリアルは○個」
みたいなルールを決めたが
設定個数が多めだった上にチェックを怠っていた

メモリ
終盤にテクスチャとマテリアルに対して
新規追加を禁止して、申請制に移行
アセット管理する身としては
心理的にかなり楽になった

メモリ
前述の「未使用アセット撲滅期間」を実施
マテリアル統合も平行して進めた結果
1500個超 ⇒ 1200個ほどに削減

メモリ
最終的にエフェクトでメモリに載っていたものは‥
• ParticleSystem
• Material
• MaterialInstance
• StaticMesh
• Texture
• DataAsset
70～120 MB
50～65 MB
12～15 MB
19～26 MB
13～15 MB
1～3 MB
[ TexturePool ]
• Streaming
5～32 MB＿＿
• NonStreaming
10～12 MB＿＿
※5つの色々なロケーションで調査

メモリ
今後は各アセットごとに設けた個数制限を
定期的に自動チェックするようにして
オーバーしていたら担当者に通知するようにしたい

メモリ
ただし他のフォルダから流用する可能性が
あるので、ParticleSystemから参照を辿って
常駐アセットを除外してカウントする必要がある

メモリ
Usageについて

メモリ
Usageの組み合わせによるサイズ：Translucent / Unlit
PS4向けに非圧縮でクックしたファイルサイズ
（UE4.17）
Usage 無し
Particle Sprites ○ ○ ○ ○ ○ ○ ○
Beam Trails ○ ○ ○ ○
Mesh Particles ○ ○ ○ ○ ○
Static Lighting ○ ○ ○ ○
Data Size (KB) 32 124 50 51 32 143 144 124 162 144 162

メモリ
Usageの組み合わせによるサイズ：Translucent / Default Lit
PS4向けに非圧縮でクックしたファイルサイズ
（UE4.17）
Usage 無し
Particle Sprites ○ ○ ○ ○ ○ ○ ○
Beam Trails ○ ○ ○ ○
Mesh Particles ○ ○ ○ ○ ○
Static Lighting ○ ○ ○ ○
Data Size (KB) 110 546 203 208 155 639 644 591 737 689 782

• Usageの組み合わせによるサイズ
• Particle Spritesが最もサイズが大きかった
• ただし拡張した情報が入っているため無改造と差異があると思われる
• デカールマテリアル以外では基本的にParticle SpritesをONにしていた
• しかしParticle Sprites以外でしか使っていない場合は削った方が良い
• UnlitだとStatic LightingをONにしてもサイズは変わらなかった
メモリ

• Usageの組み合わせによるサイズ
• 最低限の組み合わせにしたいが‥
• データ〆のタイミングにならないと判別できない
• 製品データ以外（検証やサンプル）でのみ使用されている可能性もある
• 製品データでの使用先を洗い出して最低限のUsage設定に更新するのを
自動実行できないかプログラマに相談してみたが、今回は断念
• データ〆直前に全マテリアルに対して更新かけるのは怖い
• 検証やサンプルデータでマテリアルが表示されなくなる可能性もある
メモリ

処理負荷

処理負荷
基本的なこと

• 処理負荷は大きく分けてCPUの処理とGPUの処理
• CPU 画面を描画するまでの準備（生成・判定・更新など）
• GPU 画面を描画する処理
処理負荷

• 計測で大事なこと
• PS4やXboxOneの実機上で負荷を見ないと意味が無い
• でもUE4エディタ上でも目安になる情報はある
• シェーダー複雑度
• ドローコール
• Cascade上で独自に表示している予想処理時間とエミッター数
処理負荷

• Gameスレッドの負荷の基本的な要因
• エフェクトの生成
• パーティクルの生成
• GPUパーティクルも生成はCPU負荷
• パーティクルの更新
• 軌跡の分割数が多い・Spawn Per Unitの間隔が短い
• CPUによるコリジョン判定・レイキャスト ‥など
処理負荷

• Drawスレッドの負荷の基本的な要因
• テクスチャ枚数
• モデルの個数
• マテリアルの個数
• エミッターの数
• エフェクトで生成するポイントライトの数 ‥など
処理負荷

• CPU負荷の具体例は‥
• プレイヤーが一度に沢山の弾を放出する時
• プレイヤーが範囲攻撃で敵や背景のコリジョン判定をする時
• 味方キャラや敵キャラが同時に沢山出現して技を出す時
• エミッターを大量に生成する技が出た時
• 風切り表現として分割数が多い軌跡を沢山プレイヤーにアタッチしていた時
• 多数の破片をCPUのコリジョン判定でバウンドさせていた時
• レイキャストを沢山のパーティクルで行っていた時 ‥など
処理負荷

• GPUスレッドの負荷の基本的な要因
• マテリアル自体の重さ（描画の命令数や命令の複雑さ）
• 半透明のライティング・キャストシャドウ生成
• 描画する面積（半透明の場合は重なりも含めての面積）
• GPUパーティクルの更新
• ポストエフェクト ‥など
処理負荷

• GPU負荷の具体例は‥
• 短い間隔で発射できて着弾時に爆発する技を壁際で行った時
• デカールが50～80個のように沢山表示されていた時
• ライティングした煙を沢山重ねて表示していた時
• 不透明度が低くて寿命が長くて大きな煙を沢山重ねていた時
• ミスで沢山のパーティクルにポイントライトを生成していた時
‥など
処理負荷

処理負荷
エフェクトは基本的に半透明を扱うので
開発当初はGPU負荷の方を特に気にしていたが
CPU負荷の方が跳ね上がる場面が多かった印象

処理負荷
汎用マテリアルはできるだけGPU負荷を抑えるよう
シンプルにすることを初期の頃から心掛けたが‥
そのため目的に応じて小分けになった

処理負荷
結果的にはマテリアルの数(容量)の方が問題になった
もう少し汎用マテリアルに機能を充実させて
全体数を抑えられたら良かった

処理負荷
処理負荷のレギュレーション

処理負荷
可変30fps
処理を33msに収める必要がある

処理負荷
キャラ・背景・エフェクトそれぞれの処理負荷の
予算・チェック方法などに関しては
最適化チームからヒアリングがあり提示がもらえた

処理負荷
独自のプロファイラも用意され
細かく内訳を確認することができた

• インゲーム
• エフェクトに関しては探索時とバトル時で分けて考える形
• 探索時
• プレイヤー + NPC + 背景 + 背景エフェクト + UIなど
（背景エフェクトは背景の予算に含まれる形）
• バトル時
• 探索時 + 敵キャラ + プレイヤー・NPC・敵のバトルエフェクト
処理負荷

• インゲーム
• バトル時の予算
• CPU 33msを継続して超えないように‥
FrameやDrawが3～5ms増えている場合は
パーティクルの発生しすぎを疑う
• GPU バトルエフェクトで4ms（プレイヤー＆味方 3ms + 敵 1ms ）
処理負荷

• カットシーン
• シンプルに30fpsを切らないというのが当初からの指標
• 超えたものはQAからバグ報告としてもらう形
処理負荷

• 実機チェックの指針
• 基本的には担当エフェクトがFIXしたら実機チェックする
• 正常に表示されているかチェック
• 処理負荷の計測
• 計測は、基本的にはStat Unitの4つの値を見るだけ
• ただし負荷が目立つものはプロファイラで内訳をみる
• 原因がよく分からないものはプログラマに調査依頼
処理負荷

• 実機チェックの指針
• 処理負荷のスパイク（瞬間的な跳ね上がり）は許容
• コンセプトとして処理負荷よりも見栄えの方が重要視されていたため
• 許容するスパイクは１秒以内と定義
• ただし１秒以内でも画面が引きつる場合はNGとする
処理負荷

処理負荷
普段の実機チェックについて

処理負荷
UE4エディタ上でゲームプレイできるのは便利だが
実機チェックが習慣化しない側面も‥

処理負荷
下流工程なのでギリギリまでデータを制作していた
実機の台数も限られていた

処理負荷
そこで開発後半から、週に一回みんなで集まり
通しプレイする時間を設けた（1時間程度）
次回は続きをプレイしていく形

処理負荷
加えて開発終盤、実機での全エフェクトチェックを
当番制で実施した

処理負荷
曜日でスタッフを割り振った
全エフェクトのチェックリストを作成して
Frame・Game・Draw・GPUの ms の値を計測・記入

処理負荷
バトル時の処理負荷の計測方法について

処理負荷
カメラを自由に操作できるアクションゲームで
エフェクトの平均的な処理負荷を出すのは難しい
状況に応じてかなり上下する

処理負荷
例えば‥敵と味方が沢山登場して同時に技が出て
プレイヤーの大技も出したりすると
CPU負荷が跳ね上がる

処理負荷
カメラに近い敵や壁際で魔法を連発したりすると
半透明が大写しで重なりGPU負荷が跳ね上がる

処理負荷
そこで実機チェック環境を
次のような感じで定めた

• 四方を高い壁で囲んだ狭めのチェック専用レベルを用意
• ロケーションを限定しない技や敵はこのレベルで計測する
処理負荷

• プレイヤーのエフェクトをチェックする場合
• 指定の敵を指定の数配置
• 敵はダメージ０状態、行動は待機状態にする
• 味方は待機状態にする
• カメラは自然なアングルにする
処理負荷

• 各技を行ってFrame・Game・Draw・GPUの値を計測
• 技を開始してから終了の間の平均値やMAX値をチェックして記入
処理負荷

• 計測のために追加してもらった機能 ①
• Frame・Game・Draw・GPUの過去5秒の各情報を5秒更新で表示
処理負荷
前回との差分 5秒間の平均 5秒間のMAX

• 計測のために追加してもらった機能 ②
• 実機に接続しているキーボードのZキーを押すと計測開始、計測終了
• 計測中はデバッグウインドウを非表示にする
• Frame・Game・Draw・GPUの４つの値の各情報と‥
• 平均値、計測前の値と平均値との差分、MAX値
• 表示されたエフェクトの情報をCSVで出力
• エミッター数やパーティクル数など
処理負荷

• 連続で出せる技は、単発時と連発時で計測
• カメラ演出が入る技は、以下のように区切って計測
• 導入演出時
• キャラクターを操作して技を出した時
• フィニッシュ演出時
処理負荷

• 味方のエフェクトをチェックする場合
• 指定の敵を指定の数配置
• 敵はダメージ０状態、行動は待機状態にする
• 味方は最も攻撃頻度が上がる行動モードにする
• プレイヤーは自然な立ち位置、カメラアングルをできるだけ保持
• 計測開始してしばらく放置、平均値やMAX値を計測
処理負荷

• 敵のエフェクトをチェックする場合
• 計測したい敵を平均的に登場する数だけ配置
• プレイヤーと味方をダメージ０状態、待機状態にする
• プレイヤーは自然な立ち位置、カメラアングルをできるだけ保持
• 計測開始してしばらく放置、平均値やMAX値を計測
処理負荷

• 実機チェックについての補足
• 計測する値の変化が激しい場合は何度か計測して大体の値を出す
• 手順のドキュメントを作成、印刷して実機のある場所に置いた
• 自動チェックもプログラマに相談して試してもらっていた
（エフェクト改造のセッションでも軽く紹介あり）
処理負荷

処理負荷
おまけ情報

処理負荷
エフェクトにおける
間接ライティングキャッシュ（ILC）について

• 間接ライティングキャッシュ（ILC）
• ILC自体に関してはEpic Games Japan篠山さんによる
こちらのスライドの解説がとても分かりやすい
『Lightmassの仕組み ~Precomputed Light Volume編~ (Epic Games Japan: 篠山範明)』
https://www.slideshare.net/EpicGamesJapan/lightmass-deep-dive-part2-pub
処理負荷

処理負荷
https://www.slideshare.net/EpicGamesJapan/lightmass-deep-dive-part2-pub

処理負荷
ILC
ILC
ILC

• Particle SystemごとにもILCを持つ
• エフェクトがライティングしないマテリアルのみで構成されてい
たとしてもランタイムでILCの計算が走る
• エフェクト発生時とコンポーネントの移動時
• Draw負荷に影響
• 大量の弾を発射したり大量のヒットエフェクトが出たりする、あるロケーションで
15msほどILCで跳ね上がるケースがあった（その場所のPLVの間隔がかなり詰まっていた）
処理負荷

• ILCの設定は標準ではコンポーネント単位だが、エフェクト単位
でもON/OFFできるよう拡張してくれた
• Unlitマテリアルでのみ構成されているエフェクトはILCをOFFに
するコマンドレットを開発終盤に実行
処理負荷

最後に

最後に
エフェクトは特殊な表現を色々扱うが‥
大半がプログラマの協力なしには実現が難しい
= コストがかかる
でも、実現したい

最後に
わがままでご迷惑もよくかけますが
今後ともよろしくお願いします！
＞プログラマのみなさま

最後に
みなさまからの開発情報のシェアも
もっともっと増えていって欲しいです！

以上になります
少しでも多くの方の助力になれば幸いです！

ご清聴ありがとうございました！
UNREALはエピック・ゲームズ・インコーポレーテッド商標または登録商標です。
PlayStationおよびPS4は株式会社ソニー・インタラクティブエンタテインメントの商標または登録商標です。
その他掲載されている会社名、商品名は、各社の商標または登録商標です。

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)