Unreal Engine 5 イテレーション改善のための新機能とバックエンド技術紹介【CEDEC 2023】

Unreal Engine5 イテレーション改善のための新機能とバックエンド技術紹介 Epic Games Japan 鍬農 健二郎

注意 ● 扱うバージョンは、 UE5.3 (2023年8月) 時点でのもの ● 開発中の機能を含むため、今後変更される可能性があります ● 計測値は開発中のものであり、今後改善される可能性があります

検証環境 本セッションでは殆どのテストを以下の環境で実施 CPU AMD Ryzen Threadripper PRO 3995WQ 64-Cores 2.70Hz RAM 256 GB Memory 4TB SSD OS Windows 10 Enterprise 64-bit

サマリー 本セッションの内容を活用することで以下のことが達成できる ● クックやパッケージングのイテレーションを早くできる ● 実機で早く確認できて、レンダリングの調整に時間をさける ● バックエンドの機能への理解が深まる ● プロジェクトに最適なソリューションを自身で検討できる

なぜイテレーションを 改善する必要があるのか？

昨今のゲーム開発は... プロジェクトの大規模化 リモートワークが促進 クラウド化の促進 アセットの数が増える マップのサイズが大きくなる 同期やロード時間の増大 ストレージの確保 会社に行くのが難しい どこからでも同じように仕事できる ビルド、ストレージ、仮想化環境の活用 Unreal Engine で言えば World Partition, LWC, Nanite, Lumenなど 高精細で高品質なコンテンツを実現 ⇒ 開発環境は充実してきたが、さらに良いコンテンツが求められる

UE5移行後にも頂いたフィードバック パッケージングに時間がか かるため、実機での検証に 時間がかかる そもそも元からプロジェク トの同期に時間がかかる パッケージングがとても長 いが原因がわからない クック処理の時間が長い が、どうすれば短縮できる かわからない エディタでのロードが長 い、バックグラウンドでア セットロードできない １つのファイルを変更した だけでも実機で確認するま でに時間がかかる PIEで実行する際に長い待ち 時間があり、ゲームをすぐ に開始できない ファイル数が増えたことで 実機確認までのファイル転 送に時間がかかる 全プラットフォームを複数 のビルド構成でビルドする のが大変 DDCや中間ファイルなど、 扱うファイルも増加して ディスク容量が足りない DDCを持っていないと シェーダーコンパイルが長 くかかる プロジェクトのリソースを含 む、ディスクスペースを逼迫 している エディタが起動するまでが遅 くマップを開くのも遅い OFPAで扱うファイル数が膨 大になったことでプロジェ クトの同期が遅い プロジェクトのビルドに長 い時間がかかる、コンパイ ルもリンクも長い

より良いコンテンツ制作のため、 待ち時間を減らして開発に時間を割けるよう さらなるイテレーションの改善が必要

目次 ● 概要 ● イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times ● Tips

イテレーション改善

現在開発中のイテレーション改善の機能 Sync ● Target Iteration Virtual Asset Editor ● ● ● ODSC DDC 圧縮 Editor Domain ● ● ● ● Load times ● Cook ● Zen Cooker ODSC : On Demand Shader Compilation DDC : Derived Data Cache Zen Store Zen Server Zen Storage Zen Dashboard Zen Loader

Zen？

Zen 禅 /Zen/zen/[noun] : fundamentals; essentials; harmony; 完全に再設計されたアーキテクチャにより、アセットのクック、 保存、ロードを高速かつ効率的に行うことができる エレガントで調和の取れた流れが、待ち時間や中断を最小限に抑 えて仕事をするスペースを提供し、落ち着いた時間を過ごすこと ができる（ようなイメージ）

現在開発中のイテレーション改善の機能 Sync ● Target Iteration Virtual Asset Editor ● ● ● ODSC DDC 圧縮 Editor Domain ● ● ● ● ● Zen Cooker Store Server Storage Dashboard Load times ● Cook Zen Zen Zen Zen Zen Loader

イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times

“Sync” の改善 ソースコントロールからローカルPCの プロジェクトの同期を早くすることで 素早くEditorでの確認が開始できる

なぜ “Sync”を改善？ ソースコントロールから大量のファイルや 大きなサイズのファイルを同期することで Editorで操作できるまでに時間がかかっている

Virtual Assets 【機能】 アセットを2つのデータに分割することによって、プロジェクトのディスク容量 を抑えて同期の効率を上げることができる UE5.3 から Production Ready として追加 【効果】 プロジェクトのサイズが大きくなるほど、メンバー間でデータを高速かつ効率的 に同期できるようになる 【利用方法】 公式ドキュメント参照 https://docs.unrealengine.com/5.2/ja/overview-of-virtual-assets-in-unreal-engine/

• https://docs.unrealengine.com/5.2/ja/overview-of-virtual-assets-in-unreal-engine/

https://docs.unrealengine.com/5.2/ja/overvie w-of-virtual-assets-in-unreal-engine/ https://www.docswell.com/s/EpicGamesJapa n/53P8EK-UE5_1_World%20Buliding_Core#p 42 Virtual Assetに関して公式ドキュメントやUE5.1アップデートをご参考ください

• https://www.docswell.com/s/EpicGamesJapan/53P8EK-UE5_1_World Buliding_Core#p42
• https://docs.unrealengine.com/5.2/ja/overview-of-virtual-assets-in-unreal-engine/

Virtual Assets ● 同期回数が減る事で同期のプロセスが早くなる ● Texture や Mesh を多用するプロジェクトで効果を発揮 ● Ancient Game においては、最初の同期で x50 のディスク容量削減

Virtual Assets のイメージ テクスチャ アセット VA テクスチャ アセット Structured Data Editorに公開されたPropertyなどの情報 アセットとして必要な構成要素 (必須部分) (.uasset) .uasset Bulk Data (.upayload) Pixel単位の描画情報等表示のための情報 テクスチャとして必要な構成要素 (追加データ) アセットを用途によって分離して管理することで 更新に必要なデータも小さくなる

Virtual Assets の運用フローイメージ Bulk Data Perforce Perforce DDC download Structured Data Perforce DDC check out pull Structured Data Structured Data Perforce DDC check in Structured Data Bulk Data Sync PIE Edit Submit

Virtual Assets の注意点 ● ネットワーク接続が必須、高速なネットワーク環境で効果を発揮 ● Source Control に Perforce の利用が必要 ● 新規プロジェクトはそのまま利用、開発中のプロジェクトへの適用は注意 ● ● ロールバックの方法、仮想化の解除方法など、元の運用に戻すことは可能 プロジェクトによって効果が変わる ● ● ● 「巨大なアセットのみを仮想化するだけ」でも恩恵を受けられる 大きなサイズのアセットを扱わない場合は恩恵を受けにくい 小規模、少人数、単独開発では特に恩恵を受けにくい

イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times

“Editor” の改善 エディタでオペレーションする際の 読み込みや処理を短縮して 素早く繰り返し確認できるようにする

なぜ “Editor”を改善？ 起動時やPIE実行時に アセットに対して必要以上にアクセスしたり 更新すること処理を行うことによって 操作できるまでに時間がかかっている

ODSC : On Demand Shader Compilation 【機能】 現在のビューの表示に必要なものだけを対象としてシェーダコンパイルすること によってマップやエディタの展開を早くする UE5.1 以降ではデフォルトで有効 【対象】 頻繁にプロジェクトを同期して大量のシェーダーコンパイルをする人 キャッシュされたシェーダー用のリモートDDCにアクセスできない人 マテリアルやシェーダーを作成するアーティストや描画エンジニア 【利用方法】 コンソール変数で以下の定義を追加 (デフォルト:1) r.ShaderCompiler.JobCacheDDC=1

OSDC の効果 エディタ起動時間は マップロード時間は x1.1～2.2 の改善 x1.8～3.9 の改善

モバイルプレビューの高速化 https://www.docswell.com/s/EpicGamesJapan/KM1VGG-UE5_GTMF23_IntroFeatures#p76

• https://www.docswell.com/s/EpicGamesJapan/KM1VGG-UE5_GTMF23_IntroFeatures#p76

ODSC の課題 ● コンパイルの必要があるシェーダーの数が大幅に減り、エディタの起動、 マップのロード、PIE にかかる時間が大幅に短縮 ● まだユースケースによってはさまざまなボトルネックがある ● 既知の問題 ● ● ● ● グローバルシェーダーとデフォルトマテリアルのコンパイル (必須シェーダー) ODSCの恩恵を受けることができないケース ODSCが原因でのヒッチ シェーダーのバリエーションが多い

DDC : Derived Data Cache 圧縮 【機能】 DDC と テクスチャアセット(.png) の保存に Oodle Data (Kraken圧縮) が適用 UE5.0 以降ではデフォルトで有効 【効果】 Local DDC および Shared DDC に保存されたファイルサイズ、および テクスチャ のファイルサイズが圧縮されて大幅に小さくなる 例：ShooterGame に適用すると Windows 用 Cookのキャッシュが 1.21 GB→380 MB (69%減) Oodle Data：ファイルを圧縮することによってデータサイズを小さくすることができる機能

DDC についてのおさらい ● 機能 テクスチャやメッシュの派生データ(実データ等)をキャッシュする機能 データ量が大きいため、予めキャッシュしておくことでアクセスを高速化 ● キャッシュ作成 各アセットのロード時にキャッシュをチェックして無ければ生成 あればキャッシュを利用してデータを展開 ● 保存場所 LocalDDC (早い) → SharedDDC (遅い)

Virtual Assets のイメージ テクスチャ アセット VA テクスチャ アセット Structured Data Editorに公開されたPropertyなどの情報 アセットとして必要な構成要素 (必須部分) (.uasset) .uasset Bulk Data (.upayload) Pixel単位の描画情報等表示のための情報 テクスチャとして必要な構成要素 (追加データ) アセットを用途によって分離して管理することで 更新に必要なデータも小さくなる

DDC に保存されるデータ Static Mesh 最適化された頂点バッファとインデックスバッファ UV, LODリソース, Naniteリソース など Skeletal Mesh LODリソース Texture 圧縮ツールの出力 (DXTバイナリ) Material コンパイル済みシェーダーマップ シェーダーバイトコード Audio ストリーミングオーディオリソース

Editor Domain 【機能】 Editorで扱うアセット(パッケージ)のキャッシュを作成する 【効果】 キャッシュデータを利用してパッケージをロードすることで、保存されているプ ロパティのUObjectの読み込みを高速化する 【利用方法】 Editor.iniで以下の設定を有効する (デフォルト:false) [EditorDomain] EditorDomainEnabled=true SaveUnversioned=true Domain：領域、領土

Editor Domain とその他 Domain の関係 Source Domain Editor Domain Editor Domain Package Workspace Domain Editor Source Data Import UAsset DDC Target Domain Zen Storage Cook Target Domain Package Source Control

Editor Domain の効果比較 Editor起動時間については マップロード時間については x1.2 程度の改善 x1.1 程度の改善

イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times

“Cook” の改善 Cook = アセットのコンバート処理 アセットのコンバート処理を短縮して 素早くアセットを確認できるようにする

なぜ “Cook”を改善？ シングルプロセスでの処理や アセットアクセスの重複などにより 非効率なクック処理を実行しているため

Cook についてのおさらい コンテンツのクック処理 https://docs.unrealengine.com/5.2/ja/cooking-content-in-unreal-engine/ Unreal Engine は、テクスチャ データ用 .png またはオーディオ用 .wav など内部で使用す る特定のフォーマットでコンテンツアセットを格納します。 ただしこのコンテンツは、プラットフォームでは独自のフォーマットを使用しており、ア セットを格納するためにアンリアルが使用するフォーマットに非対応の場合、あるいはメモ リやパフォーマンス効率がもっと良いフォーマットが存在する場合のいずれかの理由で、 様々なプラットフォームに合わせて異なるフォーマットに変換する必要があります。 内部フォーマットからプラットフォーム独自のフォーマットへのコンテンツ変 換プロセスを クック と呼びます。

• https://docs.unrealengine.com/5.2/ja/cooking-content-in-unreal-engine/

パッケージングのフローにおけるクックの位置づけ Build Cook アセットのロード LoadPackage Stage Package アセットの保存 Serialize クックの主な処理はこの２つ Deploy

クックによるアセットのコンバート .uasset .uasset Asset ファイル パッケージのヘッダー情報 パッケージをロードした際に一番最 初にロード .uexp Export ファイル パッケージのアーカイブ情報 パッケージのインポート・エクス ポート情報を展開する際にロード .ubulk Bulk ファイル アセットの実データが格納 プラットフォーム固有の情報やマッ プの情報などが必要な際にロード

今までの Cooking の課題 UE5 以前の Cooker のアーキテクチャでは ● キャッシュが効かない ● 分散できない ● 重複を排除できない 基本的なクックプロセスは ● シーケンシャルなクッキング処理 ● クックの非同期処理は殆どのケースで遅延が許容されず同期前提が多い ● Iterative Cooking は信頼性が低い

Zen Cooker 【機能】 既存のクック処理に対して改善された新しいクッキングシステム 例として以下のような機能を備えている ● ● ● Multiprocess Cooking Hibrid Iterative Iterative++ 【利用方法】 各機能の詳細にて

Multiprocess Cooking 【機能】 複数のプロセスでクックを行う事によってクック処理を短縮できる UE5.3 からベータ版として追加 【利用方法】 Editor.ini で以下の設定を追加 [CookSettings] CookProcessCount=4 もしくはクック時の引数に以下の指定を追加 -CookProcessCount=4

プロセス数の違いのイメージ シングルプロセスクック 料理：アセット 鍋 ：クッカー ガス：メモリ マルチプロセスクック

16プロセスによる CitySample のクック ● 16 のエディタ起動によるプロ セスでクックを実行 ● プロセス毎に全力でクックを するのでメモリは必要

マルチプロセスクックのアーキテクチャ UnrealEditor-Cmd Cook Director (FCookDirector) Create , Tick, Assign WorkerSV0 (FCookWorkerServer) WorkerCL0 WorkerSV1 WorkerSV2 LoadPackage InQueue WorkerSV2 Launch, Snd,Rcv LoadPackage ForCooking LoadPackage (FCookWorkerClient) Load Serialize UnrealEditor-Cmd WorkerCL1 UnrealEditor-Cmd UnrealEditor-Cmd WorkerCL2 WorkerCL3 Cooking

マルチプロセスクックの効果 (CitySample) ● ● プロセス数が多いと処理も早くなる傾向 (必ずしもそうではない) プロセス数が多いとメモリを消費

Hybrid Iterative 【機能】 特定のアセットタイプをデフォルトで反復的にクックできるようにする 【利用方法】 Editor.ini で以下の設定を追加 (デフォルト:false) [CookSettings] HybridIterativeEnabled=true Editor.ini で反復クックの対象とするクラスを指定 (以下は設定例) [TargetDomain] +IterativeClassAllowList=/Script/Engine.Texture2D +IterativeClassAllowList=/Script/Engine.StaticMesh +IterativeScriptPackageAllowList=/Script/Engine

Iterative++ 【機能】 既存の反復クックをより正確に反復検出を行うクッキング機能 【効果】 クックの実行結果をキャッシュして同一コンテンツのクックが要求された場合は クック処理をスキップすることで、クック処理を早く完了できる 【利用方法】 以下の引数を追加してクックを実行 -iterative -iterativerequireexe -ini:Editor:[CookSettings]:IterativeUseClassFilters=true

Iterative++ の比較 815秒 かかっていた処理が 58秒(x14.0) に短縮

イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times

“Target Iteration” とは？ Target=実機･デバイス, Iteration=反復 コンソール機やモバイル端末など 実機で素早く確認できるようにする

なぜ “Target Iteration”を改善？ 実機で確認するまでに アセットをクックしたり転送する必要があり 時間がかかっていたため

旧来の Target Iteration の構成 Target Target Target Device Cooked Assets Target Device Cooked Assets CookOnTheFly Server Editor Work Station Cook On The Fly Editor Work Station Cook By The Book

Target Iteration 改善のために ● Zen Store キャッシュを保存する機能 ● Zen Storage キャッシュの保存場所 Zen Store が有効な場合ここに保存される ● Zen Server キャッシュを管理するアプリケーション Zen Storage への書き込みや読み出しをサポート

新しい Target Iteration の構成 Target Target Device Cook時にアセット をZen Storageに キャッシュする Zen Server Cooked Assets Cache Storage (Zen Storage) Editor Work Station COTF/CBTB

Zen Store 【機能】 クック済みアセットをローカルのルーズファイルではなく、ローカルのストレージ (Zen Storage)に格納する機能 【利用方法】 Engine.ini に以下を設定を追加 (BaseEngine.iniでデフォルト定義済み) [Zen.AutoLaunch] DataPath=%APPSETTINGSDIR%Zen/Data LocalDataCachePathEnvOverride=UE-LocalDataCachePath LocalDataCachePathEditorOverrideSetting=LocalDerivedDataCache ExtraArgs=--http asio --gc-cache-duration-seconds 2937600 --gc-interval-seconds 21600 [/Script/UnrealEd.ProjectPackagingSettings] bUseZenStore=true ルーズファイル：1ファイルに纏めていないファイル、Cook済みアセットのことをここでは指す

Zen Store のドキュメント https://docs.unrealengine.com/5.2/ja/zen-store-in-unreal-engine/

• https://docs.unrealengine.com/5.2/ja/zen-store-in-unreal-engine/

Launch 時に Zen Store が動くアーキテクチャ Zen Store 有効 .uassetや.umap Network PackageStore 実データ以外のパッケージ HTTP PackageStore FileSystem PackageStore FS Zen Storage HTTP AsyncPackageLoader Network PackageStore Zen Store 無効 I/O Dispatcher .ubulk file TextureやMeshの実データ FileSystem PackageStore FS

Zen Store 無効 Zen Store 有効 Cooked アセットは保存されない Cooked アセット /Saved/Cooked 以下に作成される Zen Storageに保存される

Zen Server 【機能】 Editorから起動される内製のアプリケーション Editorの外で複数のデータを管理できる ローカルでDDCの管理に利用 【利用方法】 Engine.ini で以下の設定を追加 (デフォルト:true) [Zen] AutoLaunch=true デフォルト有効なので、Zen Storeの設定が有効なときには自動で起動する Zen Storeを利用するかは bUseZenStore の設定による

Zen Server のコード https://github.com/EpicGames/zen

• https://github.com/EpicGames/zen

Zen Server 適用前 Source Assets workspace UE5 HD ● ● Device App Copy Source Assets Cooked Assets 複数のSource AsstsとCooked Asstsのコピー Cooked Assetsのコピーに伴うロス Copy HD Cooked Assets

Zen Server 適用後 Source Assets UE5 Device workspace Access Source Assets Cooked Assets App Access Zen Server HD HD ● ● ● Source Assets Zen Storage におけるデータ管理 Target Device のスペース削減 Cooked Assts のコピーが削減 Cooked Assets Cooked Assets

Zen Store を利用した比較 (コンソール機) Editor起動時間については マップロード時間については x1.8 程度の改善 x3.1 程度の改善

Zen Dashboard /Engine/Binaries/Win64 以下に配置 Zen Serverの稼働状況を示す機能

イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times

“Load Times” の改善 Load Times = ロード時間 アセットの読み込み時間を短縮して 素早くアセットを確認したい

なぜ “Load Times”を改善？ ロードするアセットの増加や アセットの非効率なロードによって ロード待ちに常に悩まされている

Zen Loader 【機能】 File I/Oが効率的で少ないブロッキングの新しいアセット非同期ロードシステム 【効果】 Editorを起動して操作できるようになるまでの時間が短くなる アセットのロードがより効率的でマップのロードが早く完了する 【利用方法】 Engine.iniに以下の設定を追加 [/Script/Engine.EditorStreamingSettings] s.ZenLoaderEnabled=True s.AsyncLoadingThreadEnabled=True

Zen Loader のドキュメント https://docs.unrealengine.com/5.2/ja/zen-loader-in-unreal-engine/

• https://docs.unrealengine.com/5.2/ja/zen-loader-in-unreal-engine/

IO Store については https://www.docswell.com/s/EpicGamesJapan/56G9EK-UE4_IOStore_UE425

• https://www.docswell.com/s/EpicGamesJapan/56G9EK-UE4_IOStore_UE425

Async Loader のロードマップ UE4.25 UE4.26 Experimental Beta Editor build Not IoStore package AsyncLoader IoStore package AsyncLoader2 New loader

Async Loader AsyncLoader AsyncLoader2 EditorPackage Loader エディタで動作 IOStore によるパッケージを使用しない エディタでも動作 IOStore によるパッケージを使用する Editor では AsyncLoader で動作 Cook Package では AsyncLoader2 で動作 ※1 ※1:”-UseIoStore” を付与して起動時に有効

Zen Loader 無効時 の1ファイルのロード処理 (WireframeMaterial=30.6ms) 非同期処理ではなく 全てGame Threadでロード

Zen Loader 有効時 の1ファイルのロード処理 (WireframeMaterial=12.2ms：約x2.5早い) DDCアクセスは非同期で処理

Zen Loader による効果の検証 x1.1 程度の改善 x1.8 程度の改善 x3.1 程度の改善

目次 ● 概要 ● イテレーション改善 ● ● ● ● ● Sync Editor Cook Target Iteration Load Times ● Tips

Tips ● ● ● ● ● Cooking Insights Cook の効率を上げるために ロードアセットのトラッキング Cook Class Skip Only Editor Only

Cooking Insights [UE4] Unreal InsightsによるCookプロファイル (Cook Trace) https://qiita.com/EGJ-Ken_Kuwano/items/359e82a4780cfdca2844 Cook の処理を調べることによって、 ● ● ● アセット毎のクック処理に掛かった時間や処理を確認できる ボトルネックを調べて改善することができる 不必要にクックされたデータがないか調べることができる

• https://qiita.com/EGJ-Ken_Kuwano/items/359e82a4780cfdca2844

Cookの処理時間が長い ロードだけで1.5sec

Cook の効率を上げるために 大量のコンテンツを扱うプロジェクトにおけるCook時間を改善する推奨事項 ● ● ● ● ● Shared DDC を有効化してキャッシュを共有する シェーダーコンパイル用のXGEを無効化する クッカーのメモリに十分なスペースがある ストレージに SSD を使用 メモリに余裕がある場合は 複数プラットフォームを同時にクックするほうが早い

ロードアセットのトラッキング ロードされたパッケージ単位でのコールスタックを出力する機能 “TrackAsyncLoadRequests.Enable 1”でトレースした後に “TrackAsyncLoadRequests.Dump” で出力

Cooking Class 【機能】 クラスを指定してクックすることを可能にし、対象クラスのみに対してクックを 実行できるようになる 【効果】 クラスを限定してクックすることでクック処理の時間を短縮 【利用方法】 Cook時に以下のようなクラスを指定して引数を渡す 例：-cookincludeclass=StaticMesh 例：-cookincludeclass=/Script/Engine.StaticMesh 例：-cookincludeclass=/Script/Engine.StaticMesh+AnimSequence

SkipOnlyEditorOnly 【機能】 EditorOnlyDataで参照されるパッケージをクックから除外する開発中の機能 【効果】 ● EditorOnlyデータをクックに含めない事によって、パッケージなど本当に必 要なデータだけがクックされることになって不必要なクックを減らす ● クックにかかる時間、パッケージ作成の時間を短縮できる 【利用方法】 Engine.ini に以下の設定を追加 [Core.System] CanSkipEditorReferencedPackagesWhenCooking=True

まとめ ● エディタのイテレーション、クック、パッケージングを早く完了できるよう になり、他の作業に時間をさけるようになる ● 実機で早く確認できるようになり、見た目の調整が早くできるようになる ● バックエンドの機能への理解が深まる ● プロジェクトに最適なソリューションを自身で検討できるようになる