UE4 Performance and Profiling | Unreal Dev Day Montreal 2017 (日本語訳)

Profiling and Optimizing UE4（日本語版） MONTREAL DEV DAY 2017

目次 • プロファイリングのベストプラクティス • ひと目で分かるプロファイリングの流れ • CPUプロファイリング • Blueprintの最適化 • GPUプロファイリング • 一般的なGPU最適化方法 MONTREAL DEV DAY 2017

プロファイリングの ベストプラクティス When and how to approach the process MONTREAL DEV DAY 2017

いつ / どのようにプロファイリングするべきか • 早く そして 頻繁に！ • 終盤まで待つのではなく、すぐトライしましょう！ • ただし、過度にするのはおすすめしません • プロファイリングして問題があった所にだけ最適化 • 可能な限り早く 対象のハードウェア上でテストしましょう • 全員が基本的なプロファイリング方法を知っているように • アセットのコストを知るアーティストは多くの時間を節約します！ MONTREAL DEV DAY 2017

プロファイリング環境の構築 • プロファイリングの邪魔をするノイズを最小限に • 使用しない機能は全てOFFにしましょう • Framerate Smoothingを切りましょう • Project Settings > General Settings > Framerate group • Testビルドを作りましょう • Developmentビルドでテストすると、 Drawスレッドがノイズで膨れ上がります！ MONTREAL DEV DAY 2017

エディタを使ったプロファイリング • エディタ上では詳細なプロファイリングはしないように • エディタは多くのものにノイズを与えるため、多くの数値の信頼性を下げます • 一般的なパフォーマンステストには良いですが、 100%理想的というわけではありません • エディタでプロファイリングをする場合は • • • • • Standaloneで実行 エディタのリアルタイム更新をOFFに エディタを最小化 Frame Rate Smoothing (Project Settings) をOFFに Vsyncを切る (r.vsync 0) MONTREAL DEV DAY 2017

プロファイリング手順 An at-a-glance look at the approach to profiling MONTREAL DEV DAY 2017

一般的な方法 • ボトルネックを特定しよう • Game Thread • Render Thread • CPU • GPU • 最適化すると、頻繁にボトルネックが変化します • ボトルネック範囲の問題を解決しましょう • Game Thread – C++コード or Blueprint • CPU Render – オブジェクト数, ドローコール, カリング • GPU Render – シェーダ, オーバードロー, ライト MONTREAL DEV DAY 2017

自動化? • 一部のチームはシーンを飛び回るカメラを設定し、 テストのために特定のポイントを使うことを好みます • これは物事の一貫性を保つのに役立ちます。 しかし、ゲームプレイのテストには難しいです • カメラが高密度なエリアを通過することを確認してください。 シンプルなエリアではよくありません • キャラクタやエフェクトをテストすることもお忘れなく シーケンサが便利です！ • Paragonの場合: • テクニカルアーティストはどのエリアに問題があるのかを知っていました • そして、プロファイリング時間の大半をそれらのエリアに充てました MONTREAL DEV DAY 2017

ミリ秒単位で測定しよう • stat fps ではなく stat unit 使おう • 最も大きい値がボトルネックの可能性を示します • フレームごとの処理時間（ms) • • • • Frame: 各フレームの合計処理時間 Game: C++ or BPによるゲームプレイ処理 Draw: CPU render time GPU: GPU render time • stat unitGraph を使うことで 線グラフで測定することができます • 主に繰り返すヒッチに使用されます (心臓の鼓動のように) MONTREAL DEV DAY 2017

スイッチを捨てて、何が壊れているのかを見よう！ • ボトルネックの原因を探すのは面倒です まずは簡単な所からはじめよう！ • ときには最善の最初のステップは、 機能をON/OFFして改善されるか確認することです！ • これは、シーンの一部分の表示 / 非表示をするのと 同じように簡単にできます • また、異なる解像度でレンダリングしたときに 何が起こるのかを見ることも非常に便利です • GPUに負荷をかけすぎているなど MONTREAL DEV DAY 2017

ScreenPercentage • Game Threadとは無関係な問題を 計測する際にとても役に立ちます • stat unit で処理時間を表示 • r.ScreenPercentage 10 を使う • または100よりも小さい数字 • GPUに送られるピクセル数が減ります • もし速くなったら、 GPUがボトルネック • もし速くならなかったら、 CPUがボトルネック MONTREAL DEV DAY 2017

Show Flags • 問題を探す最も簡単な方法の 一つはシーンの一部をOFFに することです • 削減する時間を知ることに 役立ちます • より多くの LODs • より少ないtranslucency （半透明） • 調整されたライティング show <assetType> or showFlag.<assetType> 0-1 • Staticmeshes • Skeletalmeshes • Particles • Lighting • Translucency • Reflectionenvironment • まだまだ沢山あります！ MONTREAL DEV DAY 2017

診断ツール Realtime stats and view modes MONTREAL DEV DAY 2017

Stat コマンド • statコマンドは エンジンの様々な部分における 統計情報をリアルタイムに フィードバックします • 沢山あります • パフォーマンスのために 最も一般的なものをご紹介します • 完全なリストに関しては 公式ドキュメントをご確認ください stat fps stat unit stat scenerendering stat gpu stat engine stat streaming stat emitters stat lighting MONTREAL DEV DAY 2017

Stat SceneRendering • ドローコールのみを見るコマンド • ドローコールは何かを描画するために GPUに送る単一のリクエストです • ローエンドなマシンやモバイルではCPUにて速度が下がる可能性が あります(Metal とVulkanの場合は影響が少ないです) • 他に見たほうが良い箇所： • • • • Shadows Decals Post Processing Lighting MONTREAL DEV DAY 2017

Stat GPU • 4.15で追加されました • GPUからリアルタイムで計測 • ハイライトは見れますが、詳細は見れません • すばやく問題点を見つける際に有用です • 詳細を見る場合はGPUプロファイラを使用してください • 例えば、影を落としている特定のライトを探したい場合など MONTREAL DEV DAY 2017

Optimization View Modes • プロファイリングブレデターになる！ • View Modes は問題の原因を明らかにします • エディタ画面で全てを使えます • プロファイリングツールと併用するべきです MONTREAL DEV DAY 2017

Shader Complexity • シェーダがGPU上でどれほどのコス トになっているのかを表示します • オーバードローの問題を見る良い方法 • • オーバードローとは、ピクセルを何 度も描画することです 最適化のための最も一般的なコンテ ンツの問題の一つです • 下部のグラフはピクセル・頂点シェー ダのパフォーマンスを表しています • 赤や白が多く見える場合は、 アプローチを再考しましょう MONTREAL DEV DAY 2017

Quad Overdraw • 比較的新しいビューポート • 多くのアーティストが見逃す問題を 示します • メッシュをLOD化する必要がある箇所を 示します • • • 緑が多い箇所はシンプルにするべきです 緑以上のものはコストがかかってきます 一般的に半透明の重なりなことが多いで す forward rendererで非常に便利です MONTREAL DEV DAY 2017

Quad Overdraw in-depth • GPUはビューをクアッドに分割します • 2*2のピクセルグループ • これは全てのピクセルで 全ての処理を実行するよりも効率的です • 非常に小さい、又は非常に長い、細いジ オメトリがピクセルを無駄にする • 通常、大きなポリゴンはピクセルクアッドを 最大限に活用し、GPUを最大限に活用します • 正三角形によるモデルと積極的なLOD Image copyright fragmentbuffer.com MONTREAL DEV DAY 2017

Shader Complexity + Quad Overdraw • 2つの強力なビューモードを 一つに結合 • 高価なシェーダとジオメトリ をひと目で把握するのに 便利です • 詳細を計測するためには、 まだ個々の設定が必要です MONTREAL DEV DAY 2017

Light Complexity • シーンのライティングのコストを可視 化 • ライトが重なりあうと、寒色から暖色 に変化します • ライティングのコストは表示しますが 、シャドウのコストは表示しません • 明らかに白は悪いです • ライトの半径を小さくするべきである ことがよく分かります • これを反転することで、特定にライト のコストが「価値がある」かどうかを 素早く確認できます MONTREAL DEV DAY 2017

Lightmap Density • ライトマップのためのテクセル密度を 可視化 • 密度が増すにつれて、寒色から暖色に 変化します • • • 殆どのものは青にできます シャドーマップは非常に高い解像度 にする必要はないことが多いです 可能な限り低く保ちましょう • メモリ消費量がすぐ増大します MONTREAL DEV DAY 2017

Stationary Light Overlap • 特定のオブジェクトには最大4つまで のStationaryライトが影響します • それを超えると、他のライトは全て Movable(完全に動的)になります • このビューモードはそれがどこで起き ているのかを追跡するのに役立ちます • ライトの半径を可能な限り小さく保つ ように注意しましょう • 固定された太陽光を使いますか？ • • それは4つの利用可能なライトの一つ を占めます！ 可能なときは太陽はOFFに しましょう MONTREAL DEV DAY 2017

Primitive Distance Accuracy • テクスチャストリーミングのための可 視化システム • 賢いmip制限を可能にするために、シ ステムで使用する必要があるミップを 確認可能にします • • • • • • Red = 2 以上 mipが少ない Orange = 1 mip 少ない White = ちょうどいい Cyan = 1 mip 多い Green = 2 以上 mipが多い この設定は StreamingDistanceMultiplier プロパティで調整可能です MONTREAL DEV DAY 2017

Mesh UV Densities Accuracy • これはメッシュのUV密度を使用しま す • UV密度がストリーミングデータにど のように影響しているのかを可視化し ます • Primitive Distance Accuracyと同じ • • • • • • Red = 2 以上 mipが少ない Orange = 1 mip 少ない White = ちょうどいい Cyan = 1 mip 多い Green = 2 以上 mipが多い これを修正するためには、各メッシュ のUVを調整する必要があります MONTREAL DEV DAY 2017

プロファイリングツール Built-in CPU and GPU profiling MONTREAL DEV DAY 2017

CPU プロファイリング • 統合ツールを使用して、ゲームプレイを分割し、 各Tickで何が起きているのかを確認する • Blueprintのパフォーマンスをプロファイルする非常 に便利な方法です！ • 時間の1区間を測定する • その区間における各フレームや平均を見ることが できます • 2つの特殊なStatコマンドが必要です • stat startfile & stat stopfile • これらのコマンドの間におけるログファイルを生 成する • プロファイラはログの詳細な分析を可能にする • WorldのTickに潜り、各blueprintの機能を見る • CPU (Game and Draw) と GPU に使用可能! MONTREAL DEV DAY 2017

GPU プロファイリング • GPU機能をプロファイリング3つの方法 • ビューポートでの stat gpu コマンド • セッションフロントエンドで記録されたログ • GPU Profiler • ログか独自のUIにダンプできます • コストを可視化するための良い方法: • • • • Base pass Lighting Shadows Post processing MONTREAL DEV DAY 2017

遅いフレームの追跡 • stat dumpHitches • このコマンドは、指定された時間（ミリ秒単位）以上のヒッチをログにダンプする ために使用されます • 値を設定するには、t.hitchThreshhold 0.XX コマンドを使います(デフォルトは0.075) • memReport –full • 使用されたメモリ量の内訳 • 以下は、毎週Unreal Tournamentのために生成されたチャートです UT UT Hitches Per Minute Hitch Time (% of Gameplay) Time Played Peak Memory 0 0.00% 304.75 sec 1230.80 MB Average Frame Time Average Frame Time Delta % Over 30 FPS % Over 60 FPS 8.33 ms -0.18 ms 100.00% 99.84% MONTREAL DEV DAY 2017

startFPSChart and stopFPSChart • startFPSChart と stopFPSChart を使用して、時間経過に伴う フレームレートの図を作成できます • これらをレベルシーケンスの開始時と終了時に呼び出すことで 指定されたコースに沿ったフレームレートを 自動的に呼び出すことができます MONTREAL DEV DAY 2017

Blueprint 最適化 Or: Keeping the Kids from Eating the Crayons MONTREAL DEV DAY 2017

Blueprint のボトルネックと最適化 • Blueprintはゲームプレイロジックを組み立てることを非常に簡単にします • 誰もがそのような”力”のための準備ができているわけではない！ ☺ • エンジニアの指導を受けることで最高の結果が得られることが多い • 最終的に、全ての人が速くなります • 共通の課題 • Tick機能への依存 • 高価な機能の過剰利用 (多くのオブジェクトを反復) • ハードリファレンスの乱用 MONTREAL DEV DAY 2017

Tick Blueprintへの依存 • Tick はフレームごとに計算することを意味します • Blueprints はTickをほとんど必要としません • Class Defaults の Enable Actor Tick をOFFにしてください • これはTickイベントが機能するように、デフォルトでONになっています • Tickの代替案 • Timers! • Timelines • Tick を必要に応じて手動でON/OFFする • Tickの周期(Tick Frequency)を調整しましょう • 0.0 = 毎フレーム MONTREAL DEV DAY 2017

高価な機能 • 一部の機能は非常に高価です • Get All Actors of Class • Spawn • オブジェクトやプロパティの大きなグループを反復処理するもの • これらを可能な限り使用しないようにしましょう • 参照を取得するためにそれを使用する場合は、参照されるクラスが自身を渡すこと で、照会する必要がないようにすることを検討してください • 配列の代わりにTSetsを使いましょう • それらを使用する必要がある場合、できるだけあまりしないでください • 好ましくは一度だけ、例えばBegin Playのように MONTREAL DEV DAY 2017

Blueprintのハード参照 • Blueprintが互いに参照を生成することは非常に簡単です • Blueprintをロードした時、それが参照する他のすべてのBlueprintをロード する必要があります • そして、それらがさらに参照しているBlueprintも… • そしてさらに…さらに… • これにより、ゲーム内のパフォーマンスが低下することはありませんが、 メモリやロード時間が犠牲になる可能性があります • いくつかのスタジオではエディタの動作が重い • 起動時にゲームの大部分（または全て）をロードしていたことが分かります MONTREAL DEV DAY 2017

Blueprintのハード参照 (つづき) • ハード参照の回避: • 必要かつ問題を起こさない場合以外では、Cast操作は避けてください • 例えば、PickupクラスがPlayerのみとしか対話しない場合は、それはうまくいく かもしれません • しかし、Playerクラスが他のPickupタイプの参照も持つ場合、問題が発生する可 能性があります • 代わりに、Blueprint インターフェイスを使いましょう • 参照を必要としないよう考えるようにしましょう • インターフェイスを介して、より一般的なクラスにメッセージを送信 • それらがインターフェイスを実装する何かにたどり着けば素晴らしい！ • そうでなければ、大きな問題はない MONTREAL DEV DAY 2017

その他のBlueprint 最適化 • いずれのことをあまりしないように（スクリプト言語のように） • 単一のクラスに機能を入れすぎない • 分割しましょう • クラス階層を使用しましょう • しかし、深すぎるクラス階層は避けましょう • • クラス内に大量のコンポーネントを置かないように あまりにも高価な数学処理 • Math Expression ノードを使いましょう – 高速化のために最適化されています • BPのパフォーマンスがこれでも改善しない場合は… GO NATIVE! • Epicでは、Blueprintの多くは汎用的なC++クラスから発生しています • あなたも是非そうするべきです • 全ての重い処理はコードに残して、Blueprintには軽量なものを残しましょう MONTREAL DEV DAY 2017

どのActorがTickしてる？ • 何がTickしていたのか見逃しましたか？ dumpticks を使いましょう • 全てのTick Actor のリストをログにダンプし、Tickが何回呼ばれたのかを 示します • また、シーン内にどれほどの有効 / 無効化された Tick Actorがいるのかも 示します MONTREAL DEV DAY 2017

Draw Thread 最適化 Dealing with too much stuff MONTREAL DEV DAY 2017

CPU Rendering に関する考慮事項 • Draw Threadのボトルネックは、 あまりにも多くのことをすることで発生することが多いです: • 大量のドローコール • オクルージョンクエリ • 大量のパーティクルのシミュレート • 多くのライトの追加 – GPUにより影響する事が多い • Draw Threadを高速化する最も良い方法は、減らすことです • 画面上のものを少なくするための方法を見つけましょう • 一般的に、これはコンテンツを整理するか、 またはUE4内の統合ツールを使用して、オブジェクトの結合を 開始することを意味します MONTREAL DEV DAY 2017

Actor 結合( Merge )ツール • Window > Developer Tools にあります • 選択したメッシュを結合し、新しいアセットに置き換える • Simplygonを介してマテリアルを結合することもできます • Simplygonがなくても標準機能で結合することも可能です • 同じマテリアルを持つメッシュは良い働きをします MONTREAL DEV DAY 2017

Instanced Static Meshes • 与えられたメッシュの複数のインスタンスを生成する仕組み。 同じメッシュオブジェクトの一部として考慮される • 現時点では、コードまたはBlueprintを介してのみ作成することができます 。たいていはConstruction Scriptを介します。 • これを生成するのに役に立つBlueprintを作成するのは非常に簡単です • メッシュがどこに配置されるのかをプレビューするBlueprint • プレビューBPからTransformを収集する 半径ベースのISM BP • Editor Utility class の BPには注意！ – エディタのみです! • Hierarchical Instanced Static Meshes も考慮しましょう • 独自のオクルージョン / Visiblityを扱います MONTREAL DEV DAY 2017

Hierarchical LOD • Hierarchical LODを使用すると、複数のメッシュを結合し、一 つのメッシュとして縮小することができます • テクスチャをアトラスに組み合わせて、全体のマテリアル要求 を減らします • 非常に遠い距離で見る大きなメッシュのグループ、建物や都市 に非常に便利です MONTREAL DEV DAY 2017

GPU 最適化 What to do about all those pixels MONTREAL DEV DAY 2017

GPU Pipeline Overview • Preprocess • 頂点シェーダ • ピクセルシェーダ MONTREAL DEV DAY 2017

頂点シェーダの最適化 • World Position Offsetをどの程度使っているかに注意して下さい • 頂点アニメーションの代替方法よりもしばしば安価です • 頂点カラーは最終的には効果になる可能性がある • Paragonの場合, それを削除して、インスタンスごとに追加しました MONTREAL DEV DAY 2017

ピクセルシェーダの最適化 Pixel Shader Don’ts • 大量の数学処理 • 大量のテクスチャ • 大量のプロシージャル関数 • Noise • 大量のMaterial layers • If への 依存 • 両方共計算する必要がある Pixel Shader Dos • 数学処理の代わりにテクスチャの ルックアップを使用する • グレースケールに圧縮して、一つ にテクスチャにまとめる • レイヤーの使用を最小限に抑える • Switchパラメータを使用して、必 要のないものをOFFに

Material Instruction Count • Material instruction Countには常に注意しましょう • 注意: 表示された数値は、Applyをクリックするまでは正確ではありません • 時には安全のためマテリアルを再コンパイルするのが良いです • Paragonの場合、 Material Instructionのバジェットをマテリアル毎に維持 （しようと）しました • キャラクタ: 350 instructions • これは画面上の3人称サイズによるものです • 環境: 150-200 instructions (255 limit) • 注: これはParagon、プラットフォーム、必要とされたパフォーマンス に非常に特化した値です。あなたの予算とは異なる場合があります MONTREAL DEV DAY 2017

Overdrawの取扱い • Overdraw はGPU負荷の主な原因の一つです • Overdrawのために、ジオメトリ領域を最小化しましょう • Overdrawに頼るよりも、頂点を追加したほうがずっと安価です • 例えば、カイトと少年では、芝生のテクスチャアルファの輪郭にほぼ正確 に一致するように芝生の面をカットしていました • Particle Cutout プロパティを使用する！ • Cascade Required Module以下にあります • テクスチャにそれを与えることで、自動的にスプライトを切り取ります • subUVでも動作します、フレームごとに異なるカットアウトがあります MONTREAL DEV DAY 2017

テクスチャ解像度の管理 • 好きな解像度でテクスチャを作成しても、常にフルの解像度を使用すると • • • • は限りません Texture Streaming viewsを使用して、任意のテクスチャに使用している mip levelを確認してください Texture Statisticsに設定された統計パネル (Window > Statistics)を使用し て、現在のレベルで使用しているmip levelを確認できます そのあと、テクスチャエディタを使ってmip biasを矯正します または、より低い解像度で再インポート☺ MONTREAL DEV DAY 2017

ライティングに関する考慮事項 • 動的なライトは高価です (ディファードでは少し安価です) • 小さく、影を落とさないライトが最も安価です！ • これらを多く持つことができます！ • 動的なライトの数を最小限に • 動的なライトが影響を与える物の数を最小限に • 動的なライトの半径を最小限に – タイトな方が良い • 可能な限り、動的なライトからの影は最小限に • UEにおいて、ライトからの動的な影は最も高価です • Stationary Lightの重なりに注意して下さい • 動的ライトへの後戻りは非常に高価です MONTREAL DEV DAY 2017

ライティングに関する考慮事項 (つづき) • できるだけベイクしましょう！ • • • • • • ベイクには時間がかかりますが…ごめんなさい… 動的ライトを必要とは思わないでください • コンテンツが静的な場合は、おそらく静的ライトを使用できます Mesh Distance Field shadowsを使用しましょう • Fortniteで使いました – 多くの時間を節約しました 密なカスケードシャドウに注意してください シャドウバイアスで多くのアーティファクトはクリーンアップされます 可能な限りライトマップ解像度は低く抑えてください • ビューモードを使用し、可能な限り青にします MONTREAL DEV DAY 2017

ライティングに関する考慮事項 (つづき) • ライトファンクションは本当に必要でない限り避けましょう • IESプロファイルもコストがあることを理解して検討しましょう • 透過ライティング も高価です、注意して下さい • 影を早めに消しましょう(できるだけ近い距離に) • 可能な限り動的ライトは消しましょう • スポットライト は ポイントライトよりも安価です • フェイクシャドウを恐れないで！ • 私達はこれを沢山使ってます、特にVRのために！ MONTREAL DEV DAY 2017

デバイスのための最適化 Making the most of your content MONTREAL DEV DAY 2017

デバイスのための最適化 • Unreal Engine は “一度ビルドすると, どこにでも展開する ” というゲーム 開発アプローチを推進しています • 全てのものが等しく、常にうまくいきます >:D • UE4の多くのコンテンツツールには、Cook時に自動的に縮小する賢いコ ンテンツ製作のためのオプションがあります • これにより、コンテンツの見栄えがよくなったり、様々なサポート しているプラットフォームで正常に動作しますPrevents having to build content multiple times • EpicではFortniteとParagonにこれらのツールを幅広く使用しています • Paragon はPS4で60Hz 1080pで動作する必要があります MONTREAL DEV DAY 2017

デバイスプロファイル • デバイスプロファイル エディタを使用すると、デバイス毎に様 々なコンソール変数(cvars)を制御できます • これにより、コンソールやモバイルのような性能が低いデバイ スでよりシンプルな車道、低品質なMipmap、偏ったメッシュ LODなどを使用することができます • これらのcvarsを設定すると、Cook処理中にアセットの品質が 制御されます • Window > Developer Tools > Device Profiles MONTREAL DEV DAY 2017

デバイス毎のマテリアル最適化 • マテリアル内で QualitySwitch ノードを使用します • これにより、異なるレベルにグラフを分けることができます • 複数の QualitySwitch ノードが使えます。各主要Material input にも (Base Color, Roughness, etc.) • r.MaterialQualityLevel cvar を使用して、プロジェクト全体の品 質を設定できます • Paragonの場合 • PC は High quality • PS4 はMed quality MONTREAL DEV DAY 2017

ネットワーク 最適化 How to properly use the Series of Tubes MONTREAL DEV DAY 2017

Replication 最適化 • ネットワークに関する一般な問題: • 多すぎ • 頻繁すぎ • Replicateは可能な限り小さく、低頻度に！ • net.* コマンドを使用して何が起きているのか確認 • サーバ上で実行する必要があります！ • net.DumpRelevantActors を使って、現在Replicate中の物を確認 • このコマンドは 4.19 で改善されます • net.* コマンドは沢山あります – 全てのリストはドキュメントで MONTREAL DEV DAY 2017

ネットワーク診断機能 • 100人プレイのネットワーキングゲームを制作したおかげで、 Replication問題を追跡するための新しい Toy が手に入ります • stat net • これは、新しく信頼できるデータを表示するために4.19で改善されま した • 最終的にはクライアントから確実に使用できます! MONTREAL DEV DAY 2017

Network Relevancy ビューモード (4.19) • 青= 休止 • オレンジ = 休止してませんが 、チャンネルがない • 緑 = Replicateするチャンネル がある • 赤 = 常に関連する • 白 = 距離で間引かれる (これ らの多くはまだ見える). • 基本的に、オレンジは休止の 候補であり、プロパティの差 分チェックにCPUを使ってい ますが、Replicateはしてませ ん MONTREAL DEV DAY 2017

コンテンツ ストリーミング Control yourself; take only what you need from it MONTREAL DEV DAY 2017

Level Streaming • レベルストリーミングはゲームで使用されているコンテンツを制御する理想 的な方法です • 現在必要なものがストリーミング INし、不要なものはストリーム OUTする • 一度にどれほどストリームするか注意してください！ • プレイヤーを何らかの方法で制限するか、小さなチャンクでストリームす る必要があります • コード、Blueprint、又は Level Streaming Volumeを介して、レベルストリー ミングを制御できます • 注意: コードやBlueprintでコンテンツを過度に参照してしまった場合、いくつ かのメリットが打ち消されます MONTREAL DEV DAY 2017

おまけ: コラボレーションとしてのレベルストリーミング • レベルストリーミングは、レベルデザイナーとアーティストが一緒に働く 主要な方法です • 異なる層が異なるレベルに別れる • 物理的な領域が異なるということではない • Paragonにおける例 (簡略化): • Persistent • • • • • Lighting Base Geometry Collision Foliage Gameplay – これには全てのタワー、Spawner、MOBA要素が含まれる MONTREAL DEV DAY 2017

World Composition • 広いワールド向けの専用ストリーミ ングシステム • 過去のLevel Streaming volumeは機 能しません • しかし、Blueprintによるストリーミ ングは動作します • Pro Tip: Level Streaming Volumeのよう な機能を持つBlueprintを簡単に作れるし 、同じように動作します MONTREAL DEV DAY 2017