Unreal Engine 5 基盤の AA ゲームプロジェクトにおける Nvidia DLSS 統合とプロフェッショナルスタジオのワークフロー

高度なレンダリングアーキテクチャへの導入とスケーリングの必要性

現代のビデオゲーム業界において、AAA タイトルのような予算や数百人規模のチームを持たないものの、高い視覚品質の達成を目指す AA（ダブルA）スタジオは、技術革新の最もアグレッシブなユーザーの位置にあります。Unreal Engine 5（UE5）エンジンのリリースは、仮想ジオメトリシステムの Nanite と完全に動的なグローバルイルミネーション（Global Illumination）ソリューションである Lumen により、フォトリアル性の限界を押し広げました。しかし、これらの画期的な技術は、グラフィックスプロセッシングユニット（GPU）に膨大な計算負荷をもたらします。1 Lumen 技術が秒間 60 フレーム（FPS）の目標を達成するためには、内部解像度をネイティブ画面解像度よりもはるかに低いレベル（例えば 4K 画面での 1080p 内部処理）に引き下げる必要があります。1 この時点でハードウェアの制限を克服し、視覚的な忠実度を維持しながらパフォーマンスを倍増させる業界標準の方法は、AI 駆動型の画像再構築（image reconstruction）アルゴリズムです。この分野の業界リーダーである Nvidia の Deep Learning Super Sampling (DLSS) アーキテクチャは、ピクセルを従来の空間（spatial）的手法で拡大する代わりに、連続するフレームから得られたモーションベクター（motion vectors）と深度バッファ（depth buffers）を使用して、不足しているピクセルをニューラルネットワークを通じて合成する複雑な技術です。3 プロフェッショナルな AA スタジオにとって、プロジェクトへの DLSS の追加は、単なるプラグインの有効化プロセスではありません。レンダリングパイプライン（render pipeline）、ソースコード管理、品質保証（QA）プロセス、およびアーティストのワークフローを最初から最後まで同期させることを要求する、多次元的なエンジニアリングの問題です。このレポートでは、プロフェッショナルな環境において DLSS 3.5、DLSS 4、および Streamline SDK アーキテクチャが Unreal Engine 5 プロジェクトにどのように統合されるかを深く検証します。

Streamline SDK フレームワークとアーキテクチャの基礎

Nvidia は、DLSS 統合を近代化し、ゲーム開発者の肩にかかる統合の負担を軽減するために Streamline SDK を開発しました。Streamline は、ゲームエンジンと DirectX 11、DirectX 12、または Vulkan などのレンダリング API との間で仲介（interposer）レイヤーとして機能する、オープンソースかつハードウェアベンダー（IHV）に依存しないフレームワークです。6

過去において開発者は、Nvidia DLSS、AMD FidelityFX Super Resolution (FSR)、Intel XeSS などの各アップスケーリング（upscaling）技術のために、ゲームエンジンのレンダリングパイプラインに個別に手動の API フック（hooks）を記述する必要がありました。6 Streamline アーキテクチャはこのプロセスを単一の統合ポイントに簡素化します。開発者は、モーションベクター、深度バッファ、およびユーザーインターフェイス（UI）カラーバッファなどのリソースに一度タグ付けし、このデータを Streamline フレームワークに供給します。6 Streamline はこのデータを使用して、サポートされているすべてのアップスケーリングプラグインを適切なグラフィックスパイプラインの段階で実行します。

Streamline 統合の C++ およびエンジンレベルのライフサイクル

Streamline SDK の初期化と管理は、エンジンの最も早いロード段階で行う必要があります。初期化プロセスは、DirectX または Vulkan の API 呼び出しが行われる前に、slInit 関数を介して実行されます。8 この時点でエンジンは、サポートされている機能と要求された機能をロードしますが、まだ初期化（initialize）しません。機能が完全に動作するようになるのは、エンジンがレンダリング API デバイス（device）を作成したときにトリガーされます。9 以下のコード構造は、Streamline ライブラリが C++ を通じてどのように初期化されるかを示しています。

#include <sl.h>
#include <sl_consts.h>
#include <sl_dlss.h>

sl::Preferences pref{}; 
pref.showConsole = false;  
pref.logLevel = sl::eLogLevelDefault; 
pref.applicationId = myId;  
pref.engineType = sl::eEngineTypeUnreal;  

if (SL_FAILED(res, slInit(pref))) { 
    if (res == sl::Result::eErrorDriverOutOfDate) { 
        
    } 
} 

この段階では、セキュリティプロトコルが非常に重要です。プロフェッショナルスタジオは、マルチプレイヤーゲームにおけるチートソフト（DLL hijacking）を防ぐために、sl.interposer.dll ファイルの Nvidia と Streamline の両方のデジタル署名を検証する必要があります。6 製品版（Shipping）段階に移行する前に、開発プロセスで使用されたウォーターマーク付き（watermarked）ライブラリは、必ず製品版に対応した署名済みライブラリに置き換えられます。6

DLSS 技術の進化とモジュール構造

Unreal Engine 5 環境において、DLSS は単一の機能ではなく、テクノロジースイートです。3 スタジオは、プロジェクトの性質に応じて、このスイートのどのモジュールを使用するかを決定します。

1. DLSS Super Resolution (SR): 解像度アップスケールの基本形式です。Tensor コアを使用して、低解像度の入力から高解像度かつ詳細な出力を生成します。3

2. DLSS Frame Generation (FG): DLSS 3 で導入されたこの機能は、AI を使用して 2 つの実際のレンダリングフレームの間に完全に新しいフレームを合成します。従来の CPU のボトルネックを克服し、パフォーマンスを 2 倍にすることができます。6

3. DLSS Multi Frame Generation: RTX 50 シリーズ GPU と DLSS 4 で導入された最新の機能です。処理されたフレームごとに最大 3 つの AI フレームを生成するキャパシティを持っています。10

4. DLSS Ray Reconstruction (RR): レイトレーシング（Ray Tracing）およびパストレーシングを使用するシーンにおいて、手動で調整された従来のノイズ除去装置（denoiser）の代わりとなり、はるかに高い時間的（temporal）安定性を提供する AI モデルです。3

5. Nvidia Reflex: Frame Generation が生み出す時間的処理の遅延（latency）を補正するために、CPU と GPU のキューを同期させる低遅延技術です。Streamline プラグインに直接付属しています。6

プロフェッショナルスタジオのワークフロー：Perforce、ソース管理、およびビルドプロセス

インディー（Indie）開発者は通常、プロジェクトをローカルディスクやクラウドベースの簡単な同期ツールで管理しますが、AA および AAA スタジオの複雑なファイル構造では、業界標準のバージョン管理システムが必須となります。Unreal Engine のプロジェクトは、通常、数十テラバイトの大きさに達する可能性のある、非テキストベースの無数のバイナリファイル（binary assets）で構成されています。

なぜ Git の代わりに Perforce (Helix Core) なのか？

ソフトウェアの世界では Git が事実上の標準であるにもかかわらず、プロフェッショナルなゲームスタジオの圧倒的多数は Perforce（Helix Core）インフラストラクチャを好んでいます。13 Git は本質的に分散型（distributed）システムであり、テキストベースのコード統合（merge）処理においては素晴らしい働きをしますが、巨大なバイナリファイルを処理するように設計されていません。15 Git LFS（Large File Storage）プラグインがパッチとして使用された場合でも、アーティストにとっては抽象的で複雑な体験を提供します。Perforce の最も重要な利点は、その中央集権的な構造と「Exclusive Checkout」（排他チェックアウト）機能です。環境アーティストが巨大な Unreal Engine のマップ（.umap）またはキャラクターアニメーションファイルで作業しているとき、そのファイルを Perforce 経由でロックします。これにより、他のアーティストが同じファイルを同時に変更することを防ぎ、マージ不可能なバイナリファイルの競合をゼロに抑えます。16 また、Perforce はゲームエンジンに組み込まれた統合のおかげで、マテリアルやテクスチャ（texture）の編集をエンジンインターフェイス内（in-engine）から直接バージョン管理することを可能にします。13

カスタムエンジンビルド（Custom Engine Builds）と DLSS の統合

AA スタジオは、Epic Games Launcher を通じて提供される標準の事前コンパイル済み（pre-compiled）エンジンバージョンをめったに使用しません。ゲームの特定のニーズに合わせて C++ レベルでの最適化を行ったり、メモリ管理を変更したり、Streamline のような深いプラグインをフックしたりするために、エンジンをソースコード（source）からビルドします。17 DLSS の統合はまさにこの C++ ソースコードの統合から始まります。Nvidia は GitHub 上に独自の変更された Unreal Engine ブランチをホストしています。19 統合プロセスにおいて、スタジオの「Build Engineer」の役割を持つ開発者は次の手順に従います。

1. Nvidia のリポジトリにある特定のプラグインブランチ（例: dlss3/sl2-5.1-dlss-plugin または関連する UE バージョン用の最新ブランチ）がクローンされます。20

2. Streamline のフック（hooks）が、スタジオのメイン（main）エンジンコードリポジトリとマージ（merge）されます。19

3. エンジンの最新バージョン（例: 5.5.1）が使用されており、公式の DLSS サポートがまだリリースされていない場合、スタジオはコミュニティ発の非公式パッチ（unofficial patches）をコードベースに統合し、これらのコードを安定性テストにかける必要があります。21

継続的インテグレーション（CI/CD）と配信パイプライン

エンジンソースコードとプラグインがマージされた後、アーティストやデザイナーが毎朝数時間にわたってエンジンのビルドを待つことを防ぐために、自動化が導入されます。Jenkins、GitHub Actions、または Epic Games の Horde システムなどの継続的インテグレーション（CI/CD）ツールは、Perforce リポジトリで発生するすべての重要なコード変更時に、クラウドサーバーまたはローカルビルドファーム（build farms）で Unreal Engine を自動的に最初から再ビルドします。22 ビルドが完了すると、生成された巨大なバイナリファイル（Binaries）が Perforce を経由するか、独自の内部ツールを使用してチームに配布されます。22 このプロセスでは、p4ignore または Perforce のファイルタイプルールを非常に慎重に設定する必要があります。Streamline の動的リンクライブラリ（DLL）である sl.interposer.dll、nvngx_dlss.dll などのファイルはバージョン管理に保持される一方、開発者のマシン上で生成される一時的な派生データキャッシュ（Derived Data Cache - DDC）ファイルはリポジトリに送信されるべきではありません。18 これにより、リポジトリの肥大化と不要なネットワークトラフィックが防止されます。

レンダリングパイプラインで遭遇する最適化の問題と解決策

DLSS プラグインをプロジェクトに追加する（Edit -> Plugins メニューから有効にする）プロセスは、プロセスの最も簡単なステップにすぎません。19 本質的なエンジニアリングの労力は、AI モデルが Unreal Engine 5 の複雑なレンダリングパス（render passes）と競合する箇所で費やされます。

Temporal Anti-Aliasing (TAA) と Temporal Super Resolution (TSR) の競合

Unreal Engine 5 は、Epic Games が独自に開発した Temporal Super Resolution (TSR) アルゴリズムをデフォルトのアップスケール（upscaling）ソリューションとして使用します。24 TSR と DLSS の両方が、過去のフレームからのデータ（history frames）を評価して新しいフレームを生成する時間的（temporal）アルゴリズムです。それらが同時に動作すると、グラフィックスプロセッサの帯域幅を消費するだけでなく、ハードウェアリソースを「奪い合う」ことになり、重度のビジュアルアーティファクトを生成します。25 プロフェッショナルなワークフローにおいて DLSS が有効化された場合、TSR は直ちに無効化される必要があります。開発者が Blueprint または C++ を介して品質モードを設定すると、DLSS はエンジンの組み込み画面パーセンテージ（r.screenpercentage）設定を自動的に上書き（override）し、非アクティブ化します。25 これにより、開発者が画面パーセンテージを手動で計算する負担がなくなります。

次の表は、DLSS モードの標準的な画面パーセンテージの対応関係と使用シナリオを詳述しています。

モーションベクターとゴースト問題

AIベースの再構築アルゴリズムにおける最大の弱点は、ゴースト（残像）やスマアリング（引きずり）のアーティファクトです。DLSSは、オブジェクトの動きを追跡するために、レンダーパイプラインからGバッファ内のモーションベクターを要求します。オブジェクトが画面内で移動しているにもかかわらずモーションベクターが生成されない場合、DLSSはそのオブジェクトのピクセルが静止していると仮定します。新しいフレームが描画されると、古いフレームのデータが画面に残り続け、オブジェクトの背後に長い軌跡（尾）を残します。

ワールド位置オフセット（WPO）と植生エラーの修正

Unreal Engine 5においてこの問題が最も頻繁に発生する領域は、風のエフェクトが適用された樹木や草花です。最適化の目的で、エンジンはWPO（World Position Offset）シェーダーノードを使用して頂点（vertices）上でGPUベースの動きを実現する植生に対して、デフォルトではモーションベクターを生成しません。

この慢性的な問題を解決するために、AAスタジオのテクニカルアーティストはエンジン設定ファイル（DefaultEngine.ini）に深く介入します。まず、動的なWPOマテリアルの詳細パネルで「Support Accurate Velocities from Vertex Deformation」設定を有効にする必要があります。次に、レンダーパスを強制するために以下のコンソール変数（CVars）が使用されます。

• r.BasePassForceOutputsVelocity=1: 基本レンダーパス（Base Pass）がどのような状況でも速度（velocity）データを生成することを強制します。この処理によりゴーストは大幅に消滅しますが、GPU帯域幅を増加させるためパフォーマンスのコストがかかります。

• r.NGX.DLSS.DilateMotionVectors=1: モーションベクターをオブジェクトの境界から外側に向かって拡張させます。細かいジオメトリ（葉、ワイヤーなど）を持つシーンで、DLSSがピクセルをより良く捉えることを可能にします。

• r.Shadow.Virtual.NonNanite.IncludeInCoarsePages=0: WPOに起因する動きは、仮想シャドウマップ（Virtual Shadow Maps - VSM）のキャッシュを常に無効化（cache invalidation）し、巨大なパフォーマンス低下を引き起こします。このコマンドは、Naniteではない植生を粗い影のページから除外することでパフォーマンスを取り戻します。

AIモデルの管理：DLSSプリセット

DLSSの強みは、NVIDIAのスーパーコンピュータで継続的にトレーニングされる異なるAIモデルを提供している点にあります。開発者は、nvngx_dlss.dllファイル内に埋め込まれた異なるモデルを、ゲームの特定のビジュアルスタイルに応じて選択できます。これらの設定はJ、K、L、Mプリセットと呼ばれます。

例えば、純粋なラスタライゼーションベース（レイトレーシングなし）のゲームでは、パフォーマンスを向上させながらゴーストを削減するプリセットMが好まれます。プリセットMはRTX 40以降のシリーズでピークパフォーマンスを提供しますが、前世代では安定性の問題を引き起こす可能性があります。一方で、ゲームがインテンシブなレイトレーシング（Ray Tracing）を含んでいる場合やDLSS Ray Reconstructionが有効な場合、プリセットMは映像を過度にノイズの多いものにする可能性があり、そのようなシナリオではプリセットKを使用することで映像の安定性が大幅に向上します。

ユーザーインターフェース（UI）バッファとポストプロセッシングの順序

ゲームの3Dワールドが完璧にレンダリングされていても、画面に重なる2DのHUD要素や、ゲーム世界に配置された（World Space）3Dウィジェットは、DLSS Frame Generationによって破壊される可能性があります。

UIの色とアルファ（TagUIColorAlpha）の仕組み

Frame Generationは、人工フレームを生成する際に画面を全体的なキャンバスとみなします。ゲームの体力バーや弾薬カウンターが画面の片隅にあり、その下でカメラが回転している場合、FGアルゴリズムはUIのピクセルもカメラの動きと一緒に移動させて歪ませ（warp）ます。この状況は、UIの激しいちらつきやぼやけを引き起こします。

この重大な問題を解決するために、NVIDIAはStreamlineプラグインに専用のUIバッファメカニズムを追加しました。ゲームエンジンがUIレイヤーをレンダリングした直後（ただし画面に提示 / presentされる前）、このシステムが稼働します：

1. 分離（Separation）：開発者はr.Streamline.TagUIColorAlpha=1コマンドを有効にして、UIピクセルを分離します。

2. 閾値の設定：r.Streamline.TagUIColorAlphaThresholdを使用して、アルファ値が特定のレベルを超えているピクセルを「これはUI要素であるため、Frame Gen処理に含めない」としてタグ付けします（デフォルト値は0.0です）。

3. 再結合（Recombination）：Frame Generationは3Dワールド上でのみ動作し、人工フレームを生成し、最後のステップで分離されたUIレイヤーが元の鮮明さでこれらのフレームの上に合成（composite）されます。

ここにおける最大の開発者の罠は、UMGウィジェットの代わりに古い方法でUWidgetBlueprintLibrary::DrawTextを使用することです。この関数はアルファチャネルに書き込まないため、StreamlineによってUIとして認識されず、画面の崩壊を引き起こします。同様に、ゲームワールド内の3Dウィジェットにおいて、マテリアルのブレンドモードがMaskedではなくTranslucent（半透明）に変更された場合、TSRおよびDLSSに起因するぼやけを軽減できます。

ポストプロセッシング（後処理）エフェクトの配置

映画制作者の美学を模倣することを目的としたフィルムグレイン（Film Grain）、色収差（Chromatic Aberration）、レンズフレア（Lens Flare）、被写界深度（Depth of Field）などのポストプロセスエフェクトは、AIアップスケーラーの最大の敵です。

DLSSは、クリーンな画像を取得してより高い解像度にスケーリングするようにトレーニングされています。レンダーパイプラインでDLSS処理が実行される前に画像に人工的なフィルムグレインのノイズが追加されると、DLSSのニューラルネットワークはこのグレインを「エラー」または「低解像度アーティファクト」として認識します。アルゴリズムはこれらのグレインを修正（denoise）しようとし、画像が泥のようにぼやけた状態になる原因となります。

プロフェッショナルスタジオは、ポストプロセスマテリアルのレンダー順序を厳密に制御します。光学エフェクト（グレイン、色収差）は、常にDLSS処理が完了し、画像がフルスクリーン解像度に達した後に適用される必要があります。さらに、DLSS自体に内蔵されているシャープネス（Sharpening）パラメータは、低品質のDLSSプロファイルに起因する軽度のぼやけを解消するために、ポストプロセスパイプラインとは独立して使用できます。

品質保証（QA）、プロファイリング、パフォーマンス検証

技術統合が完了した後、ゲームが製品版の品質（Shipping Quality）に達していることを確認するために、アグレッシブなパフォーマンスプロファイリングと品質保証プロセスが開始されます。エンジンのデフォルトツールは、Streamlineアーキテクチャと常に完全に互換性があるとは限りません。

高度なプロファイリングツールとメトリクス読み取り

開発者がFPSカウンターだけを見て最適化を行うのは誤解を招きます。Unreal Engineは、Frame Generationによって完全にAI生成された追加フレームを認識していません。エンジンが1秒間に60フレームを生成していると表示している状況でも、ハードウェアは実際にはモニターに120フレームを提供している可能性があります。

このため、AAスタジオは標準のstat fpsの代わりに、以下の専用ツールとコマンドを使用します：

• stat dlssg: このコンソールコマンドは、生成された人工フレームも考慮に入れて実際の画面フレームレートと、グラフィックカード上のFrame Generationの計算負荷（overhead）をミリ秒（ms）単位で画面に表示します。

• Unreal Trace Insights & GPU Profiler: レンダーパイプライン内のボトルネックをマイクロ秒単位で検査します。どのレンダーパス（Base Pass、VisBuffer、Lighting）にどれくらいの時間がかかっているかを詳細に示します。Nanite VisBufferとHZB（Hierarchical Z-Buffer）の時間がここで最適化されます。

• Nvidia FrameView SDK および ICAT: 遅延時間とハードウェアの電力消費をFrameViewで測定するQAチームは、同時にNvidia ICAT（Image Comparison and Analysis Tool）を使用してA/Bテストを実施します。これらのツールは、ネイティブ解像度とDLSS解像度との間の金網、髪の毛、または遠距離の詳細における微視的な品質の損失を検出するために使用されます。

統合検証チェックリスト（QA Checklist）

ゲームがリリースされる前に技術チームが承認する必要がある厳格なStreamlineチェックリストが存在します。以下の表は、このチェックリストにおける重要な項目と検証すべき条件を要約しています：

これらのテストの大半は、Unreal Editor内で実行できません。Frame Generationは、複数のPIE（Play-In-Editor）ウィンドウや選択されたビューポート上で動作する際に深刻な制限を持っています。健全なプロファイリングと有効なQA結果を得るためには、ゲームを必ず「Standalone Game」モードまたは直接ディストリビューションパッケージ（Shipping Build）にコンパイルした状態で実行することが必須です。

最終評価

Unreal Engine 5ベースのAAプロジェクトにおけるNvidia DLSSの統合は、単純なメニュー設定をはるかに超え、ゲームエンジンの基本アーキテクチャ、ソースコード、およびスタジオのバージョン管理戦略にまで及ぶ包括的なテクノロジーブリッジです。スタジオは、Perforceのような業界標準を使用して大規模なバイナリファイルの危機を乗り越えながら、CI/CDシステムによってカスタムエンジンのビルドを自動化し、Streamline SDKを自社のインフラストラクチャに組み込みます。

モーションベクターの最適化からUIアルファチャネルの分離、ポストプロセス階層の整理からプロファイリングツールのマイクロ秒レベルの微調整に至るプロセスは、テクニカルアーティスト、レンダーエンジニア、QA専門家の完全な同期によってのみ達成可能です。結果として、この規律正しく段階的なエンジニアリングアプローチは、AAスタジオが限られたハードウェア予算であっても、プレイヤーにAAA品質の、滑らかで、視覚的に完璧で、応答性の高い体験を提供することを可能にする最も重要なツールです。

*情報：画像はGoogle Geminiによって生成されました。