RE ENGINEのパストレーシング実装は制作工程をどう変えたか。DCC照合から品質確認まで

RE ENGINEのパストレーシング実装で重要なのは、直接光や間接光の描画品質だけではない。参照用パストレーサーをDCCツールの結果と照合し、ゲーム向け実装へ縮小したうえで、アセット規約、照明、品質確認まで同じ基準へ接続したことだ。日本の技術アーティストや内製エンジン担当が持ち帰るべき結論は、パストレーシングを最終工程の高画質オプションとして足すのではなく、制作物を測る基準器と検証経路を先に設計することである。

2026年7月16日公開のNVIDIA Technical BlogのQ&Aでは、RE ENGINEチームがPRAGMATAとResident Evil Requiemへの導入過程を説明している。回答は当事者チームの発言だが、掲載元と記事著者はNVIDIA側で、回答者個人の氏名は示されていない。本稿ではこのQ&Aを実装事例として読み、NVIDIA製品の一般的な性能評価とは分けて扱う。

参照パストレーサーを先に作った理由

RE ENGINEチームは約2年をかけ、まず参照用パストレーサーを開発し、一般的なDCCパストレーサーに対して細かな照明挙動とバウンス結果を照合した。その後、リアルタイム環境で動くゲーム向け版へ規模を落とし、DLSS Ray Reconstructionによるデノイズを前提に最適化したと説明している。参照版と製品版を分けたことで、「速いが正しいか判断できない実装」ではなく、品質差を戻って確認できる構造を持てたと読める。

ここでDCC出力を絶対的な正解とみなすのは早い。Q&Aは比較したDCC製品名、バージョン、カラーマネジメント、許容誤差を公開していない。実際の内製導入では、共通のテストシーン、光源単位、BSDFパラメーター、色変換、比較対象の版を固定して初めて基準になる。これは公開情報から導く実務上の提案であり、CAPCOMが公開した手順そのものではない。

ゲーム向け版でも既製機能をそのまま採用したわけではない。発光体のノイズにはNext Event Estimation用のサンプリング構造を用意し、IBLが支配的な屋内では公開論文を基にReSTIR GIを自社実装したという。AlphaTestをレイのヒットごとにテクスチャ参照すると高コストになるため、スクリーンスペース深度とヒット位置を比べるScreenSpaceAlphaTestも作っている。参照実装はゴールではなく、差分を説明しながら近似を選ぶための物差しである。

レンダラー変更前後で工程の重心がどう移るか

公開Q&Aから確認できる変更と、内製チームが品質ゲートへ落とす際の論点を対応させると次のようになる。

Resident Evil RequiemとPRAGMATAで同じ規約にはならない

Resident Evil Requiemでは、現実世界の再現を重視するため、高精度な照明によってシーンの一貫性と空間の説得力が上がる一方、アセット品質や実装上の問題も見つけやすくなったという。そのため、照明だけでなくアセット制作、実装ルール、品質確認まで見直した。Graceのストランドヘアではリアルタイムの光透過が、毛量感と材質感に寄与したと説明されている。

PRAGMATAのハードサーフェス中心のSF環境では、高品質な反射に対して面の精度、法線、材質設定が最終画へより直接的に影響する。その結果、反射を前提にしたアセット制作と品質確認の重要度が上がった。Dianaの長いストランドヘアでは、光透過だけでなく毛髪数、ジョイント数、物理制御の最適化も課題になり、Resident Evil Requiem側で蓄積した知見とチーム間協力が使われた。

つまり、共通レンダラーを入れても制作基準を一枚に統一するわけではない。フォトリアルな接地感を測るシーンと、鏡面反射で法線誤差を見つけるシーンでは、合否条件が異なる。技術アーティストが両タイトルへのゲーム内統合を主導したという事実は、レンダリング機能の導入責任をエンジニアだけに閉じず、タイトル固有のアセット条件へ翻訳する役割が必要だったことを示す。

DCC照合が品質確認を上流へ移す

従来のシャドウマップは解像度の制約があり、手作業で影を調整できるカットシーンとゲームプレイの間で品質差が出る場合があった。Q&Aによれば、両作のパストレーシングでは従来は間接光だけに使っていたレイを直接光にも使い、パストレーシング利用時のゲームプレイとカットシーンの差を縮めた。これはライターの調整をなくす話ではない。局所的な補正を重ねる前に、アセット、材質、光源、レンダラーのどこが参照結果から外れたかを切り分ける仕事へ重心が移る。

CAPCOMのオンライン統合報告書2025は、RE ENGINEがライトプローブ、レイトレーシング、パストレーシングをハードウェア条件に応じて使い分ける構成を示している。Q&Aでも両タイトルは既存レイトレーシングとプローブGIを引き続き支える必要があったとされる。したがって品質確認は最高設定だけで完了せず、同じアセットが各経路で許容範囲に収まるかを見る必要がある。

内製エンジンへ入れる前の判断チェックリスト

1. 参照シーンを先に固定する。屋内外、動的光源、鏡面、粗面、肌、髪、AlphaTestを含む小さなシーン群を作り、DCC版と参照版の比較条件を版管理する。
2. 参照版と製品版を分ける。製品版で近似やデノイズを変えたとき、どの差を速度のために受け入れたか追跡できるようにする。
3. アセット契約を更新する。法線、粗さ、発光、透過、単位、色空間をチェック項目にし、反射下で初めて見える不整合をDCC出力前に検出する。
4. 例外表現に所有者を置く。ぼかしを使う透明ランプシェード、カットアウト、ストランドヘアのような横断課題は、タイトル側とエンジン側で再現シーンと担当を共有する。
5. 描画経路の組み合わせを削らない。パストレーシング、従来レイトレーシング、プローブGIごとに、ゲームプレイ、カットシーン、主要アセットの確認欄を持つ。
6. デノイザー評価の範囲を固定する。入力サンプル、解像度、動き、履歴リセット、対象GPUを記録し、ベンダー名ではなく同一条件の画質とフレーム時間で判断する。
7. 技術アーティストを統合初期から入れる。実装後の目視確認ではなく、基準シーン、アセット規約、バグ分類、タイトル間共有の設計を共同で持つ。