こんにちわ。Pocolです。
SIGGRAPH 2020のPaperが一部公開され始めたみたいです。最近，GI関係が気になっているので，DAIRO SEYBらによる”The design and evolution of the UBERBAKE light baking system”の論文を読んでみようかなと思います。
論文自体はhttps://darioseyb.com/publication/seyb-20-uberbake/にて公開されています。
毎度で申し訳ないのですが，誤字・誤訳をご指摘いただける場合は，正しい翻訳例と共にご指摘いただけると大変ありがたいです。

---

 

Activision社が開発した、特定のプレイヤーのインタラクションに応じて限定的に照明を変化させることをサポートするグローバルイルミネーションシステム「UBERBAKE」の設計と進化について説明します。完全に動的なソリューションに頼るのではなく、従来の静的なライトベイクパイプラインを使用し、最小限のパフォーマンスとメモリオーバーヘッドでランタイムにおいて事前計算された照明を動的に更新できるようにした小規模な機能セットによって従来の静的ライトベイクパイプラインを拡張します。これは、私たちのシステムがハイエンドPCから旧世代のゲーム機まで、ターゲットとなるハードウェアの完全なセットで動作し、ゲームプレイ目的のために照明の変更を使用可能にすることを意味しています。特に、個々の照明の有効化と無効化、ドアの開閉による照明の変化を効率的に事前計算する方法を示します。最後に、プロダクションレベルのセットを用いた本システムの詳細な性能評価を行い、将来的に動的な機能を拡張する方法について説明します。

INTRODUCTION

今日のAAAゲームは、ほんの数年前のオフラインでレンダリングされたムービーのリアルさと複雑さに匹敵するリアルタイムのフレームレート（通常は毎秒30または60フレーム）で画像を生成します。仮想環境をシミュレートし、プレイヤーの入力に反応し、広範囲の複雑な光輸送現象を示す画像を生成するためには、わずか16～30ミリ秒しか残されていません。この最後の目標は、プレイヤーが様々なハードウェアプラットフォームでゲームを楽しむため、モバイルデバイスや前世代のコンソールなど、最新の技術よりも性能の低いものも含め、すべてのハードウェアプラットフォームで同等の品質を達成する必要があるため、特に難しいものとなります。
　グローバルイルミネーション，つまり光源から直接ではなく、シーン内の他のサーフェイスから何度か跳ね返った後に各点に到達する照明のコンポーネントを計算する描画処理の難しさのひとつです。限られた時間予算の中で、ほとんどの最新のゲームエンジンは、何らかの形での事前計算やベイク処理に依存しています。照明の一部はオフラインで計算され、何らかのデータ構造に保存され、実行時に効率的に取得されます。これは、Quake と Quake2 [Abrash 2000] での id Software の作品によって開拓されたもので、後者は、事前に計算され、テクスチャに保存された真の間接照明を特徴とする最初のゲームでした。
ハードウェアアクセラレーションされたレイトレーシング[Parker et al. 2010; Wyman et al. 2018]により最近の開発は、限られた形でのリアルタイムのグローバルイルミネーションに期待を与えていますが、これらの技術は、AAAゲームにおける一般的な照明ソリューションとしては、これまでのところ、あまりにもコストがかかりすぎています。分離したエフェクト（ミラー反射など）を除いて、リアルタイムレイトレーシングは、現在のベイクベースのソリューションに取って代わる可能性は低く、少なくとも次の世代のコンソールでは、普遍的に利用できるようになる可能性はありません（モバイルプラットフォームではもっと長くなる可能性があります）。
しかし、ベイクされたライティングの制限は大きな影響を与えます。ジオメトリを変更するには、コストのかかるオフラインでのアップデートが必要となり、数時間かかることが多く、アーティストのイタレーション時間が大幅に増加します。事前計算は静的なレベルジオメトリを想定して実行されるため、実行時に変更してもライティングには影響がありません。たとえば、プレイヤーが壁を破壊すると、建物の内部に光があふれるはずですが、照明は壁がそのままの状態で事前計算されているため、壁がなくなったときに部屋の中の照明分布がどのように変化するかについての情報はありません。ドアを開けるような単純なインタラクションでも、レベルの照明は一貫性のない状態になる可能性があります。
これらの課題を解決するために開発したダイナミックライティングベイクシステム「UBERBAKE」の設計と進化について説明します。UBERBAKEは複数のリリースを経て開発され、その革新性は主にゲームプレイとレベルデザインの要求によってもたらされました。特に、プレイヤーの行動によって照明がダイナミックに変化するグローバルイルミネーションのシステムを実現したいと考えていました。これにより、照明はドラマチックなビジュアルだけでなく、ゲームプレイの一部としても利用することができ、例えば、プレイヤーの注意を惹きつけたり（例：ランプの点滅で興味のあるポイントを示唆したり）、ゲームのパズルを解くための手段としても利用することができます（例：敵と交戦する前に照明を消すと、敵が正確に狙いを定めにくくなります）。
我々の研究の中心的な洞察は、照明に影響を与えるユーザーインタラクション（照明の有効化/無効化、ドアの開閉）の限られたサブセットを選択することができ、完全にダイナミックなグローバル照明ソリューションの多くの利点を得ることができるということです。これにより、1) 各インタラクションに関連した照明の変更を効率的に事前計算し、2) 以前の完全に静的な実装よりも平均的に遅くなく、最小限の追加メモリを使用し、許可されたインタラクションの数に比例して線形にスケールするランタイムシステムを実装することが可能になりました。

1.1 Design criteria

このシステムの開発中には、難しい制約を満たす必要がありました。そのうちの1つを満たさないシステムは出荷できませんでした。

C.1 ゼロに近いランタイムのオーバーヘッド
最新のゲーミングPCからコンソール、スマートフォンまで、様々なハードで60FPSで動作するゲームを出荷したいと考えています。照明効果はゲームプレイに関係するため、ローエンドのプラットフォームでは無効にすることはできません。我々のシステムがすべてのターゲットプラットフォームで動作するためには、既存の静的なライティングの上にほとんどオーバーヘッドを持たないことが必要です。

C.2 形状に関する追加制約がないこと
多くのグローバル照明アルゴリズムは、最小の壁厚を要求したり、軸を揃えたフィーチャを好むなど、レベルジオメトリに特定の制限を課しています。私たちがシステムを実装したときには、すでにかなりの量のコンテンツが存在していました。コンテンツの多くを作り直すことは不可能であったため、システムはわずかなレベルの変更のみを必要としながらも、うまく機能する必要がありました。

C.3 エンジンやツールコードに大きな変更がないこと
既存のツールに大量のエンジニアリングやアートのリソースを投資しており、大きく変えることはできません。加えて、エンジンの大きな部分を書き換えるリソースがありません。完全なオーバーホールをせずに既存のベイキングパイプラインを拡張しなければならず、実装時間は生産をサポートすることや他の方法でベイキングパイプラインを拡張することに重きを置かなければなりませんでした。

上記の制約条件を満たすことが最優先で、システム設計の選択肢を絞り込みましたが、以下の設計目標に向けて最適化を図りました。

G.1 アーティストのイタレーション時間を最小限にすること
ランタイム性能とは対照的に、ベイクのパフォーマンスには厳しい制約はありません。しかし、長いベイクはアーティストのイタレーション時間を増加させるので，これは避けたいところです。ベイク時間は、シーンの複雑さとシーンごとのインタラクティブ要素の数に応じて調整する必要があります。具体的には、プレビュー品質の結果を高速に反復できるように、10分以下のベイク時間を実現するように努めました。

G.2 コンテンツ作成のオーバーヘッドを最小化すること
以前のシステムでは、照明設定の特定の変更によって影響を受けたすべてのシーン要素（照明、ジオメトリなど）をコンテンツクリエーターが手動でラベル付けしていました。特に、要素を照明の変更前、変更中、変更後のいずれかに分類する必要がありました。このため、ラベル付けのミスによるエラーが発生しやすく、ライティングアーティストの作業負担が大きく、最終的にはシステムが普及していませんでした。

G.3 実装の直交性を最大化すること
ランタイムシステムに大きな変更を加えることなく、インタラクティブな要素を追加し、ベイクするコードを改善できるようにしたいと考えています。これにより、エンジンの変更によるリスクなしに、新しい機能をアーティストに公開することができます。

これらの制約や目標は、学術的な文脈では過度に制限されているように見えるかもしれませんが、私たちの知る限りでは、制作環境では一般的なものであり、そのため、私たちの解決策は広く適用可能です。しかし、他のプロダクション照明システムと同様に、既存の共有技術、アーティストのワークフロー、プロダクションのニーズに特有の制約のために、多くの設計上の決定が必要となります。例えば、私たちが使用しているエンジンはフォワード+レンダラーです[Harada et al.] これにより、ライトマップを使用することは、ディファードエンジンを実装する場合よりも実現可能性の高いソリューションとなります。完全にボリューメトリックなアプローチは、一定の利点（異なるオブジェクトの照明のより良い統一化など）を提供することができますが、高いルックアップコスト（60 Hzのタイトルをターゲットにしているため問題となります）とそれ自体の問題（以前のゲームではライトマップに依存していたため、アーティストは馴染みがありませんでした）の両方を伴います。
このため、既存のソリューションを完全に書き換えるのではなく、既存のソリューションを維持・拡張することになったのですが、この論文で述べたのと同じような推論は、ボリュームメトリックな表現にダイナミズムを追加するためにも適用できます。

ゴールではないこと
最後に明示しておきたいのは、UNITY[Unity Technologies 2020]やUNREAL ENGINE[Epic Games 2020]のような顧客向けゲームエンジンでの利用を目的としたシステム開発ではなく、内部で利用するツールであるということです。つまり、これらの一般的なゲームエンジンの一部の顧客が使用する可能性のあるレガシープラットフォーム用のフォールバックソリューションを提供する必要はなく、当社のゲームが出荷されているハードウェアをサポートするだけでよいのです。すべての機能は、それらを使用している人々と密接に協力して開発されているため、実装の詳細を選択する際にもある程度の自由度を持つことができます。例えば、ユーザーに不必要な負担をかけないことがわかっている場合や、自動で実装することが困難であったり、時間がかかる場合には、手動の手順に頼ることもあります。さらに、我々は、動的グローバル照明の一般的な解決策を開発することを目指したわけではありません。その代わりに、アーティストが各レベルのルック＆フィールに重要な動的効果を決定できるようにしました。

1.2 Existing and Alternative Solutions

リアルタイムアプリケーションのためのグローバルな照明方法については、膨大な研究が存在します。新しいアプローチを開発する前に、私たちは特定の目標と制約条件、すなわち、ランタイム性能と動的ジオメトリのサポートに対して、既存の技術を慎重に検討し、評価しました。

Real-time Light Transport (dynamic lighting and geometry).
リアルタイムの光輸送手法は、ランタイム性能を犠牲にして、最小限の事前計算で動的な照明とジオメトリをサポートします。リアルタイムパストレーシングは、グローバルイルミネーションを計算するための概念的に単純なフレームワークを提供し、それは、ハードウェアで加速されたレイ交差クエリの利用可能性[Parker et al.2010; Wyman et al.2018]と、デノイジング手法の最近の進歩[Koskela et al.2019; Mara et al.2017; Schied et al.2017, 2018]のために、最近人気を博しています。多光源法は、間接照明の問題を、潜在的に多数の関連する仮想光源からの直接照明の観点から投げかけます［Dachsbacher et al.2014; Keller 1997］。残念ながら、現在の世代のコンソールには、専用のレイトレーシングハードウェアが搭載されていません。したがって、制約C.1とC.3が与えられた場合、リアルタイムのパストレースと多光法の文脈での大規模な可視性問題の解決の両方が実行不可能なままです。
　シーンの簡略化された体積表現を使用することは、動的なジオメトリと照明をサポートしながら照明と可視性の計算時間を短縮するために、ジオメトリを照明計算から切り離す一般的な方法です[Crassin et al. 2011; Kaplanyan and Dachsbacker 2010; Line and Karras 2010; Yudintsev 2019]、リアルタイムパストレースと組み合わせることができます[Majercik et al. 2019]。非自明なランタイムコストはさておき、ボリュームメトリックな光輸送法の主な欠点は、照明に使用される簡略化されたシーン表現とシーンジオメトリとの間の不一致に起因しています。リークや補間アーティファクトのない一貫した照明を達成することは依然として課題であり、多くの場合、レベルデザインの変更を必要とし、制約C.2に違反します[Caurant and Lambert 2018; Hooker 2016; Silvennoinen and Timonen 2015]。

Precomputed Lighting (static lighting and geometry)
領域のもう一方の端では、照明とジオメトリの両方を静的であるように制約することは、当然ながらランタイムの制約が最も小さく、ゲーム制作におけるグローバルイルミネーションの最も一般的な形式であると考えられます[Barré-Briseboi 2017; Chen 2008; Guinier 2020; Iwanicki and Sloan 2017; McTaggart 2004; Neubelt and Pettineo 2015; O’Donnel 2018]。すべての制約を満たしているにもかかわらず、これらのテクニックをそのまま使用することはできません。しかし、特にランタイム性能の特性から、これらの技術は基礎となる良い基礎となります。
　ストリーミングメモリコストの増加を犠牲にして、複数のライティングシナリオを事前に計算し、実行時にそれらの間を補間することで、ダイナミックライティングの限定的な形態をサポートすることができます。事前計算されたトランスポート方法の固定メモリオーバーヘッドとは対照的に、ライティングソリューションをブレンドすることによるメモリコストは一時的であり、通常はストリームされたインアウトをすることができます[Blizard 2017;
Caurant and Lambert 2018; Christin 2018; McAuley 2018; Öztürk
and Akyüz 2017; Tokarev 2018]。これらのアプローチは、照明の変更が制限されていて、例えば、時間帯を変更する場合など、プレイヤーが制御できないシナリオではうまく機能します。この場合、ストリーミング負荷は容易に予測でき、最大でも2つの異なる照明セットをメモリに保持しておく必要があります。私たちの全体的な動機は、インタラクティブな要素の大規模なセットに対して、プレイヤー主導の照明変更をサポートすることです。既存の技術を使用すると、メモリ予算がすぐに枯渇してしまいますし、プレイヤーの入力に応じて全く新しい照明のセットでストリーミングを行うことは不可能です。

1.3 Summary and overview

要約すると、既存の手法では、性能制約の下で我々の設計目標を容易に満たすことができるものはありません。そこで、我々は、効率的な局所照明の更新による動的な形状変更をサポートしながら、最大のパフォーマンスを実現するために、ボリュームメトリックとライトマップ表現を混合して使用する事前計算された照明に基づいた独自のシステムを開発しました。以下では、まず（静的な）グローバル照明ソリューション（セクション 2）について説明し、次に、動的な照明効果を処理するために、複数のゲームを開発する中で、どのようにして徐々に拡張していったかについて詳しく説明します。”ダイナミックライトセット(DLS)とは、プレイヤーの行動に応じてライトセットを点灯・消灯させたり(第3節)、グローバルイルミネーションへの寄与を更新したりすることを可能にするものです。最後に，第4節では，ドアの開閉に伴う照明の非線形な変化に対応できるようにDLSを拡張します。

2 OUR BAKED GLOBAL ILLUMINATION SOLUTION

システムの動的な部分に飛び込む前に、静的なグローバルイルミネーションをゲームに組み込むために使用している基本的なプロセスとデータ構造について説明します。その際、動的な要素の導入に備えて、純粋に静的な照明システムに加えた変更点のいくつかを紹介します。これらの変更はすべて、静的照明のパフォーマンス、品質、メモリ使用量を改善することがわかったので，レベルに動的要素が存在しない場合でも使用されます。
　私たちは、ゲーム制作でよく見られる静的な照明システムをベースに構築しており、動的なものにするための変更点を理解するのに十分な動作の高レベルのビューのみを提供しています。私たちが始めた静的なベーキングシステムのより詳細な扱いは、Iwanicki and Sloan [2017]に掲載されています。そこに記載されている技術は、ベイクされたグローバルイルミネーションに対するパフォーマンスの高いアプローチをもたらし、様々なシナリオで実際にうまく機能することが証明されています。ライティングアーティスト、レベルデザイナー、エンジニアは、このタイプのシステムの限界を熟知しており、潜在的な落とし穴を回避する方法を知っています。中央の技術を変更するには、常にすべての関係者の同意が必要なので、これらの考慮事項はプロダクションシステムでは重要です。したがって、以下で概説する決定の多くは、技術的な議論と同様にユーザーの関心事によって動かされています。
　我々の照明ソリューションには4つの部分があります。照明の表現方法（セクション 2.1）と保存方法（セクション 2.2）、グローバル照明の事前計算方法とレベルジオメトリに関する仮定（セクション 2.3）、事前計算されたデータを使用して、静的オブジェクトと移動オブジェクトの両方でシェーディング中にグローバル照明を組み込む方法（セクション 2.4）です。

2.1 Representing lighting

照明データの表現を選択する際には、さまざまなオプションがあります。照明の値をどのように保存するかだけでなく、最初にどの照明を保存するかを決めなければなりません。

パス表記法.
この目的のために、パスとその寄与を正確に表現できるように、いくつかの記法を紹介します。我々は、Heckbert [1990]のパス表記法を拡張し、光源をL、拡散反射をD、レシーバーをRで表す。光路\(\mathcal{L}\)の集合は、各記号が相互作用イベントに対応する正規表現で記述することができます。例えば、LDDRは、光源から始まり、２つの拡散バウンドを介してレシーバーで終わるすべてのパスを表します。表記法を乱用して、パスの集合と、それらのパスから生じる対応する照明の両方を参照するために、\(\mathcal{L}\)を使用します。
　私たちは、一般的な業界の慣行である拡散間接照明、つまりLD+Rの形のパスだけを事前に計算することが主になります。我々は、ベイク中に全半球反射率（拡散アルベド成分の代わりに）を使用して、ランタイムのマテリアルモデルを純粋なLambertianに変換します。これにより、シェーディング結果に寄与するエネルギーの多くを含む一方で、照明方程式の低周波近似が得られます。鏡面照明や直接照明を含めると、満足のいく再構成品質を可能にするために、より高い解像度でデータを保存する必要があります。これらの寄与を計算するための代わりのランタイムメソッドを使用しています。しかし、場合によっては（以下に示すように）、より悪い照明品質とより良いランタイム性能を交換するために、ベイクに直接照明を含めることもあります。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

ここでは、ライトマップ・テクセル(e)の例について計算した異なるタイプのライトパスを示します。プライマリーライト \(\mathrm{L}_{\mathrm{p}}\)は、このシステムで最も一般的な光源である。これらのために間接照明のみをベイクし、直接照明はピクセルごとにランタイムで計算されます。アーティストは、直接照明がベークされた静的なライト \(\mathrm{L}_{\mathrm{S}}\)(b) を配置することもできます。これは、多くのライトがあるエリアで、ランタイムで直接照明、特に影を計算できない場合に行われます。さらに、放射形状からの照明もサポートしていますが、ランタイムで評価するにはコストがかかりすぎるため、直接照明と間接照明の両方をベイクします。なお、ここでいう照明とは点光源やスポット光源のような微小な光源のことで、エミッシブとは三角形に発光体を配置したものを指します。最後に、空からの光 \(\mathrm{L}_\mathrm{Sky}\) (d) を直接または間接的にベイクします。これで、最終的なベイクされた照明が得られます。

\begin{eqnarray}
\mathcal{L}_{\mathrm{B}} = ((\mathrm{L}_{\mathrm{P}}D) | (\mathrm{L}_{\mathrm{S}} | \mathrm{L}_{\mathrm{E}} | \mathrm{L}_{\mathrm{Sky}}))\mathrm{D}^{*}\mathrm{R}. \tag{1}
\end{eqnarray}

2.2 Stroage formats

この照明を、現在のゲームやレベルデザインのニーズに応じて、メモリ消費量、ランタイムアクセス性能に応じて異なる形式で保存しています。異なる保存形式にもかかわらず、照明が一貫していることを保証することは、アーティファクトのない単一のシーンですべての照明を使用できるようにするために重要です（図2参照）。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

直接照明のエンコーディング
単純なスカラー照度を保存すると、外観の忠実性に重要な法線マップをランタイムで使用することができなくなります。そこで、我々は、入射放射照度を球面調和関数などの何らかの基準で保存し、これにより、与えられた表面法線に対する放射照度を評価することができるようにします。

ライトマップ
ライトマップは、レベル内のサーフェスの照明データを保存するための伝統的な方法であり、現在でも広く使用されています。サーフェスの照明を正確に表現でき、実行時に非常に効率的ですが、いくつかの欠点があります。最も重要なことは、細かいフィーチャを持つメッシュでは、実用的ではないほど高いライトマップ解像度が必要になる場合があり、パラメトリゼーションの不連続性が原因で視覚的なアーチファクトが発生することがよくあります。このような困難なメッシュの例としては、ドアハンドルやワイヤーなどがあります。それでも、当社では、レベルデザイナーが独自に開発したレベル編集ツールで作成したジオメトリや、個々の壁セグメントや建物全体などの大規模な構造モデルにライトマップを使用しています。このようなジオメトリは、大部分が大きく平坦なサーフェスで構成されているため、高品質のライトマップUVを簡単に自動生成することができます。照明データをエンコードする際には、AHD（Ambient Highlight Direction）エンコーディングのバリアント（Ambient Highlight Direction）[id Software 1999]を使用しています。この表現は、次のように割り当てられた8バイト/texelを使用します：1つの11_11_10_Floatテクスチャ（4バイト/texel）は、ローカル+Z方向の照度（HDRデータ）を格納し、もう1つのRGBA8テクスチャ（4バイト/texel）は、ローカル+Z方向の照度とアンビエント輝度（値は[0,1]範囲に制限されています）の輝度比とハイライトの方向を格納しています。ライトマップの空間解像度は、所定のメモリバジェット内に収まるようにアーティストが決定します。その上で、特定の領域でより詳細が必要な場合には、各面のライトマップの解像度を相対的にスケーリングしています。我々は代替案を検討しましたが、より高価であり、我々のライターはこの表現を好みました。

ローカルライトグリッド(LLG).
デブリのような小さな小道具や、車や出入り口、キャラクターのような入り組んだものは、ライトマップには向いていません。デブリモデルはレベル内で何度もインスタンス化される可能性があり、より複雑なモデルの場合、ライトマップのUVを自動的に計算するのは失敗やエッジケースが発生しやすくなります。その代わりに、我々は「ローカルライトグリッド」と呼ぶデータ構造を使用しています。これはIwanickiとSloan [2017]によって最初に導入されたもので、ライトマップに代わるボリューメトリックな代替手段を提供します。LLGは、オブジェクトの表面上に照明値を格納しようとする代わりに、オブジェクト中心の照度ボリューム[Greger et al. 1998]のように、モデルの周りのSHイラディアンスプローブにそれらを格納します。Iwanicki and Sloan [2017]が四面体グリッドを使用したのに対し、我々は、より高速なルックアップと照明の完全な分離のために、モデルの周囲のボリュームを表現するために指向性バウンディングボックスを使用して、よりシンプルなユークリッドグリッドを使用することにしました。このようなボリュームメトリックなストレージ手法の主な問題は、結果として得られる照明の再構成が、モデル表面上の可視性の変化によって導入される高周波の詳細情報を損なってしまうことです。LLGは、各モデル頂点に追加の自己可視項を格納し、グリッドプローブから照明データを補間する際にそれを考慮することで、この問題を解決します。可視性から照明を切り離すことの付加的な利点は、モデルがシーンのどこに配置されていても、自己可視性は同じままであるということです。頂点ごとのデータは各インスタンスで同じで、グリッドプローブの値だけがインスタンス間で変化するため、これにより、インスタンスを使用して多くのシーンロケーションでモデルをレンダリングすることができます。この表現では、ドアノブやワイヤーなど、ライトマップを使った非現実的な解像度を必要とするような細かい機能を処理しています。LLGの空間分解能はデフォルトでは1.5メートルごとのサンプルとなっていますが、オブジェクトごとにヒューリスティックな手法を用いてこれを変更しています。一つのグリッドで使用されるプローブの数がある閾値を超えている場合、解像度を下げます。また、接続可能なオブジェクトや照明グラデーションが必要なオブジェクトには、追加のプローブを追加しています。

グローバルライトグリッド(GLG).
これで静的モデルのライティングを2つの表現で表現できるようになりましたが、動いているオブジェクトをシェーディングする方法がありません。このシステムのダイナミックオブジェクトはグローバルイルミネーションに影響を与えませんが、事前に計算されたグローバルイルミネーションを使用して、動いているキャラクター、乗り物、パーティクルエフェクトに影響を与えたいと考えています。これを処理する1つの方法として、空間内の任意のポイントで間接照明をサンプルすることができる体積照明表現を導入することがあります。これにより、移動中のオブジェクトは、そのオブジェクトがたまたま存在するどの位置でも、静的な照明を評価することができるようになります。GLG の解像度はマップ全体で可変で、照明自体の分布と利用可能なゲームプレイ関連の情報に基づいて自動的に決定されます（例えば、プレイアブルエリアにはより高い解像度の GLG が割り当てられます）。最も密度が高いのは1.0メートルごとのプローブです。
　我々は、四面体グリッドを使用してマップ全体に分散された従来の輝度プローブグリッドを使用します[Cupisz 2012; Iwanicki and Sloan 2017]。各プローブ（GLGとLLGの両方）は、3次の球面調和関数(SH)基底で輝度を格納します。その結果、カラーチャンネルごとに9つの係数が得られる。非DCバンドは、DC成分で分割され、それらが[-1，1]の範囲になるように、\(1 / \sqrt{3}\)（線形バンド）または\(1 / \sqrt{5}\)（２次バンド）でスケーリングされます（非負の関数は、SHに投影されたときに、この境界を有します）。任意の点と法線に対して、最も近いプローブを見つけ、そのSH値を補間し、法線の照度を畳み込みで評価することで間接照明を計算します。光漏れを制御するために、我々はまた、四面体面ごとに粗い可視性情報を格納し、補間中にそれを使用して非可視プローブをカリングします[Iwanicki and Sloan 2017]。ボリューム効果はGLGを直接サンプリングし、モデルはGLGをモデルごとにLLGのダイナミックアトラスにリサンプルします。このようにして、照明ルックアップのランタイム実装は、静的オブジェクトと動的オブジェクトの両方で同じにすることができ、唯一の違いはLLGに格納されているデータのソースです。これにより、GLGのルックアップにかかる高額なコストを償却することも可能になりました。LLGと同様に、GLGLは輝度を格納しているので、コサイン畳み込みを実行する前に、頂点ごとの自己視認性を掛け合わせることができます。

2.3 Baking via series expansion

我々の計算はモンテカルロ法によるレイトレーシングを用いていますが、パストレーシング[Immel et al. 1986; Kajiya 1986]のような他の方法とは対照的に、我々はレンダリング方程式の級数展開として構造化し、マップ全体に対して一度に1つのバウンスを計算します。これにより、前のバウンスから計算されたすべての情報を再利用できる、ファイナルギャザリング[Reichert 1992]パスのシーケンスが作成されます。拡散照明では、各バウンスは、最終レンダリングに使用されるのと同じデータ構造（ライトマップとLLG）に格納することができます。このようにすると、サブパスが最大限に再利用されることになります。このステップはCPU上ではオフラインで動作し、出荷されたゲームのランタイムには影響しませんが、ここでの効率が重要でした（G.1）。ベイキングパイプラインでは、単一マシンでのパフォーマンスを重視し、ネットワーク上での分散は行わないことを決定しました。もし分散を試みるとしたら、スタジオの内部ネットワークが限界の要因となります。同様に、パストレーサの代わりに級数展開を使用したのは級数展開を使わないと難しいレベルの低品質なベイク結果を5～10分で出して欲しかったので，意識的な決定でした。また級数展開は、データ構造がバウンドの間に更新されるだけでよく、格納する必要がある一時的なメモリを最小限に抑え、イラディアンスキャッシング[Ward et al.1998]が必要とするような読み書きデータ構造のロックの必要性を排除します。我々は、ファイナルギャザーレイをトレースするためにEmbree [Wald et al.2014]を使用し、SIMDコヒーレンスを最大化するためにレイをアグレッシブに事前ソートします。

2.4 Run-time shading

性能の制約上、ランタイムにできるだけ作業をしないようにしなければなりません。これは、深度マップでの検索を必要とするソリューション[Majerick et al. 2019]やソフトウェア補間[Silvennoinen and Timonen 2015]を高価すぎるとみなします。また、シェーダの組み合わせによる爆発的な爆発を避けるために、レンダリングを単純化したいと考えています。ダイナミックモデルとスタティックモデルの両方にLLGを使用することはその一例で、同一のシェーダが異なるリソースで単純に実行されることになります。私たちは、動的オブジェクト、ボリュームメトリクス、エフェクトのために、疎な位置にあるコンピュートシェーダを使ってGLGを評価するような高価な操作を実行します。これまでに出荷した3つのゲームでは、LGGの評価を頂点シェーダからピクセルシェーダへ、また戻り頂点シェーダへと移行しました。これは、パフォーマンスの制約、ジオメトリ提出パイプラインの効率化、各タイトルで使用されているコンテンツの複雑さに基づいています。

3 INTERACTIVE LIGHTING UPDATE

ここまでのところ、私たちが説明するすべての技術は、能力的にも性能的にも優れていますが、静的なグローバル照明システムを形成しています。ゲームプレイ中に照明を変更する機能はありましたが、これはビルの倒壊などの大規模なスクリプトイベントに限定されていました。これは、各インスタンスのセットアップに何時間ものアーティストとエンジニアリングの努力を必要とするため、使用されることはほとんどありませんでした。このセクションと次のセクションでは、このシステムを拡張して、プレイヤー主導で照明を更新できるようにした方法を詳しく説明します。私たちの目標は、静的ソリューションのパフォーマンスとメモリの特性を維持しながら、最小限の変更セットでこれを行うことでした。また、セクション 4 で説明するように、システムは拡張性があり、複雑な照明の変更にも対応できることを確認しました。

3.1 Dynamic Light Sets

ダイナミックライティングシステムの最初のイタレーションとして、「ダイナミックライトセット」（DLS）を採用しました。これは、グローバルイルミネーションへの寄与を更新しながら、ランタイムにライトのセットを切り替えることができるという単純な問題に対処しました。これを最初のステップとして選択したのは、実装が比較的簡単で、ゲームプレイに大きな影響を与えるからです（例えば、一人称視点のシューティングゲームでライトを撃つことができるなど）。動的ライトセットとは、プライマリライト{\(\mathrm{L}_{\mathrm{P}_i}\)}のセットのことです。パス表記法に従うと、そのベイクされたライティング寄与は \(\mathcal{S} = (\mathrm{L}_{\mathrm{P}_1} | \mathrm{L}_{\mathrm{P}_2} | … )\mathrm{D}^{+} \mathrm{R}\) となります。この寄与は、各 DLS に対して個別のベイクステップで計算する必要があります。我々の実装では、既存の級数展開ベイカーを単純に再利用しています。動的ライトセットのライトは基本ベイクでは無視され、関連するライトだけを有効にして別のパスが実行されます。
　ランタイムでは、各DLSは、関連するブレンドウェイト\(\omega\)を持っています。この重みは、ライトセット内のライトの平均強度として計算されます。例えば、廊下を照らす2つのライトが含まれたダイナミック・ライト・セットを考えてみましょう。そのうちの1つが撃ち落とされた場合（強度を0にした場合）、\(\omega\)は0.5となり、2つのライトの直接的な照明効果が半減します。
　シェーディングに使用される最終的な照明 \(\mathcal{L}\) は、ベース照明 \(\mathcal{L}_{\mathrm{B}}\) と各ダイナミックライトセットの寄与度 \(\mathcal{S}_j\) をそれぞれの重み \(\omega_j\) で乗算したものを線形結合したものです。

\begin{eqnarray}
\mathcal{L} = \mathcal{L}_{\mathrm{B}} + \sum_j \omega_j \cdot \mathcal{S}_j \tag{2}
\end{eqnarray}

ダイナミックライトセットが存在しないレベルでは、これは我々の静的照明システムと同等です。これまでに説明したように、このアプローチは概念的に単純であり、 Öztürkと Akyüz [2017]によって提示された手法と密接に関連している。残念ながら、それは法外に高価なので、以下では、我々のシステムを単一レベルの数百のDLSにスケールするために、パフォーマンスへの影響を制限する方法について説明します。

3.2 Minimal overhead via sparse lighting storage

主なパフォーマンス上の懸念事項は、理論的には、各ダイナミックライトセットは、レベル内のすべてのレシーバに対して照明データを計算して保存しなければならないということです。結局のところ、ライトの寄与はライトまでの距離の二乗に応じて低下しますが、ライトは任意の距離でも何らかのライトを寄与します。つまり、完全に囲まれたライトを除いて、どのライトもレベル内のどのレシーバにも貢献する可能性があるということです。データの完全なセットを保存することは、数個以上の動的なライトセットを持つマップでは法外に高価です。大規模なマップでは、複数のギガバイトのメモリを必要とし、現在のハードウェアでは我々の技術を困難なものにしてしまうでしょう。実際には、図3に示すように、ライトセットは限られた領域にしか大きく寄与しません。この利点を得るために、我々は、動的なライトセットの照明値を格納するために、疎なデータ構造を使用しています。ベースベイクは最初に実行され、すべてのレシーバーのデータを格納します。関連するレシーバーを見つけるために、各ダイナミックライトセットは、我々の級数展開ベーカーを介して直接照明と2つのバウンスを計算します。次に、光源によって直接照らされたテクセルの間接的な平均強度が閾値を計算するために使用されます（実際には、平均値の1%を使用します）。直接ライティングしたか、またはその閾値よりも高い強度を持つレシーバーは、与えられたライトセットの更新レコードに格納されます。これにより、最終的に必要とされるメモリ（図4参照）と事前計算時間の両方が制限され、ファイナルギャザーには、サンプルするレイの数が桁違いに多くなることになります。ベイク時に使用する離散的な照明のデータ構造はシンプルです。アクティブな各レシーバに対して、ベースライトマップ（テクセルの場合）やGLG（GLGプローブの場合）の対応するプローブのレシーバの位置を示すインデックスを格納します。厄介なのは、ランタイム中にコンピュートシェーダの性能を高く保ち、補助データをできるだけ少なくすることです。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

3.3 Fast run-time combination of light sets

ダイナミックライトセット用に導入した離散的なライティングストレージは、ランタイムの複雑さの犠牲と引き換えにメモリ使用量を削減します。ダイナミックライトセットの状態が変化したときに、効率的に照明表現（ライトマップ、LLG、GLGなど）を更新できるようにしたいと考えていますが、そのためには以下のような制約があります。

(1) 我々のソリューションはGPU上で効率的でなければならず、可変長データ構造とダイバージェントコードが問題となります。
(2)ペイロードデータは非常に小さいので(ライトマップのテクセルあたり8バイト)、付随するデータ構造のメモリオーバーヘッドを低く抑える必要があります。1テクセルあたり1つの追加インデックス(4バイト)を格納するだけでも、メモリストレージが 50% 増加します。
(3) よくあるのは、DLSが完全にオフになっているケースで、これらを効率的にスキップできるようにする必要があります。
(4) 同様に、すべての寄与DLSが前のフレームから変更されていないテクセルに対しても、更新をスキップできるようにする必要があります。
(5) できれば最終的なリソースを直接更新したい。多くのPCハードウェアはテクスチャフォーマットのread-modify-writeができません – コンピュートシェーダ上で読み込みのみまた書き込みのみが可能です。可能な場合でも、read-modify-write操作には、避けたいバンド幅のオーバーヘッドがあります。

以下では、なぜこれらの制約が問題の素朴な解を除外したのかを議論し、我々の技術の概要を説明し、このシステムを使用して過去2回のゲームで我々のアプローチを進化させた理由と方法を説明します。

ナイーブなソリューション.
最終的なライトマップを作成するための自然な方法の一つは、テクセルごとにDLSからデータを収集することです。これは、例えばマトリックスパレットのスキニングに似ています。各 texel/LG（アドレスは 4 バイト）は、重なり合う DLS の数（1 バイト）を格納し、重なり合うごとにインデックス（1 バイト）とライティングデータ（8/28 バイト LM/LG）を格納する必要があります。この表現には2つの問題があり、実行できません。テクセルごとに可変長であること、インデックスを作成するためにベースアドレスを格納する必要があること（さらにメモリオーバーヘッドがあり、さらに 4 バイト）、シェーダのダイバージェントがあること（ループ長が可変）、特定のテクセルのすべての DLS が変更されない場合、作業を効率的にスキップすることが難しいことです。
　2つ目のシンプルなアプローチは、各DLSを独立して保存し、最終的なライトマップにデータを散在させることです。これは、ターゲットのtexel/LGアドレスを冗長に格納し、最終的なリソースへのread-modify-writeアクセスを必要としますが、ブレンドインデックスを暗黙のものにし、固定ストライドを持つことになります。追加の利点として、DLSが変更されなかったり、ゼロであったりした場合、作業を簡単にスキップすることができますが、数値精度の問題を引き起こす可能性のあるインクリメンタルブレンドを行った場合に限ります。これは数値精度の問題につながる可能性があります。決定論的なブレンド順序付けが必要な場合は、ゼロではないブレンドを持つすべてのテクセルを更新する必要がありますが、これは DLS ごとに推論することはできません。

我々のアプローチ.
私たちの技法は、上で説明した2つのナイーブな解決策の間にしっかりと位置しており、両方の利点を組み合わせています。この手法では、個々のテクセルや個々の DLS を考慮する代わりに、前処理ステップで影響を受けるライトセットによってテクセルをクラスタリングしています。これにより、それぞれの影響を受けるテキストのセットを持つライト セットの組み合わせのリストが得られます。これにより、組み合わせごとに 1 つの GPU コンピュートディスパッチを生成することができます。これは、上記のすべての制約が満たされます。ディスパッチ内では、ソース情報（ブレンドするライトセット）は一定であるため、各ターゲットテクセルに対して同じです。これにより、可変長のデータ構造を必要とせず、ダイバージェントなコード実行を回避し、テクセルごとに冗長なデータを保存しないことができます。特定のディスパッチに関係するライトセットがオフになっているかどうかを簡単に検出し、それらのライトセットのブレンドをスキップすることができます。さらに、ディスパッチのためのライトセットがどれも変わっていなければ、単純に完全にスキップすることができます。最終的に、任意のread-modify-writeのリソースが必要なくなります。それぞれのテクセルは正確に一つのディスパッチに属しているので、一度だけ書き込まれます。この技術は概念的には健全でパフォーマンスが高いものですが、実際にはさらに考慮すべき点があり、ライティング・アーティストが DLS をより広範囲に使い始めたため、これらは進化しなければなりませんでした。特に、ユニークなライトセットの組み合わせごとに 1 つのディスパスを作成すると、非常に少数のテクセルを含むディスパッチになり、GPU の使用率が低下し、ディスパッチあたりのオーバーヘッドが大きくなります。これは、多くのライトセットの影響を受けるテキステルがある場合に特に当てはまります。

進化.
第1作目の開発時には、DLSの数を1ケタ以内に抑え、重なりが3つ以下になるようにするように指示されていた。バッキングデータをコピーするための専用のシェーダーを作成しました。さらに、オーバーラップが多いテクセルや、ディスパッチが小さすぎる場合に使用するフォールバックシェーダを作成しました。このシェーダは、完全な float_32 スクラッチバッファ（ターゲットハードウェア上で常に read-modify-write 操作ができる）にコピーし、オーバーラップをループさせ、インデックスの数を最小にするようにソートします。フォールバックシェーダは特に高速ではありませんでしたが、頻繁に必要とされるものではありませんでした – 一般的なシナリオは、照明がちらついたり、シャットオフされたりする可能性のある部屋（すべて同じ DLS 内）で、単一の DLS を持ち、同様にちらついたり、消えたりする可能性のあるトンネルに接続されていました。これは、単一のセットを持つ大規模な領域をもたらし、トンネルが部屋にぶつかる場所で2つのDLSはオーバーラップします。
　2作目は1作目と同じようなレベルのものもありましたが、もっと大きな数のオーバーラップに対応しなければならないことはわかっていました。レベルのいくつかはステルスゲームをベースにしていて、個々のライトを撃ち抜いたり、コントロールパネルで消したりしなければならず、プレイヤーは暗視ゴーグルを着用しなければならず、プレイヤー以外のキャラクター（NPC）にはプレイヤーが見えないようにしなければなりませんでした（NPCから見えるかどうかを確認するために、プレイヤーの輝度をサンプリングしていました）。ハードレベルでは、大きな建物の中の光はほぼ全て自分のセットになっていたり、窓を通じて外から入ってくる大きな投光器があって撃ち落とせるようになっていたり、レベルの終盤に火事があってセットが増えたりしています。そのため、効率的に処理する必要があるオーバーラップの数が多くなっていました。最後に、次のセクションで説明するマルチステートジオメトリも、追加のオーバーラップを引き起こすことがわかっていました。
　最初のステップとして、最大 8 つのダイナミックライトセットの影響を受けるテクセルを処理するために、特殊なシェーダの数を増やします。フォールバックシェーダを排除するために、より特殊性の低い2つのシェーダを導入しました：

(1) ディスパッチではすべてのテクセルは同じ数のオーバーラップを持っていますが、DLSは異なる可能性があります。これらを「降格」することはできません。ディスパッチ中にDLSが変更された場合、セット全体が実行されなければなりません。これは、固定サイズ以下の DLS の組み合わせ（最大 128 テクセル）に対して行われ、それらをまとめてパックすることができるようになりました。5個以下のDLSのオーバーラップはすべて、これらのシェーダで処理されました。
(2) 2つの頼みのシェーダは，1つは5-8オーバーラップ用で，もうひとつは9-16のオーバーラップ用です。これらは、1つのテクセルのデータをインターリーブし、「そのクラスタ開始からの相対的な開始アドレス(uint16_t)」を計算するために、16/8テクセルのバッチごとにベースインデックスを格納し(なので1/2ビットに分割割り当て)、ベースからの相対的な「カウント」をテクセルごとに2/3ビット格納します(5, 9なので2/3ビットに収まります)。あとは、ベースとなるインデックスの前にある2/3ビットの数値のプレフィックスサムを計算するだけです。これにより、1 テクセルあたり 3/5 ビットのオーバヘッドを持ち、データとコードのダイバージェンスを最小限に抑えることができます。これらのディスパッチに対するクラスタリングが重複する場合、我々はディスパッチ内の DLS の総数を最小化することを目指しました。

クラス(1)とクラス(2)のディスパッチは、いずれもピクセル総数に占める割合が小さく(図5参照)、付帯データは他のものに比べて非常に小さいです(最大のマップでは約132KB)。これらの最適化の影響を測定すると、最も困難なマップの照明の更新には、古いシェーダを使用して20ミリ秒弱かかっていたのに対し、新しい実装では1.47ミリ秒かかっています。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

4 MULTI-STATE GEOMETRY

前項で説明した動的ライティングシステムは、そのまま出荷されました。その成功に刺激されて、私たちはより複雑な相互作用にまで拡張しようとしました。これまでと同様のゲームデザイン主導の方法論を踏襲し、ドアの開閉という具体的な問題に取り組むことにしました。一人称視点のシューティングゲームのキャンペーンでは、ドアはプレイヤーの進行をコントロールするための手段として機能することがよくあります。プレイヤー以外のキャラクターにドアのロックを解除させることで、ゲームデザイナーはストーリーのペースを設定したり、複雑なレベルをプレイヤーに案内したりすることができます。これは、プレイヤーの注意が開口部のドアに向けられることが多いことを意味します。暗い室内や明るい太陽の光が差し込む外観のレベルでは、ドアを通過する光が重要になるため、ライティング・アーティストにとっては難しい課題となります（図6参照）。これまでのところ、アーティストは、ベイク中にドアを閉じたままにするか（ゲームプレイ中にドアを開けても部屋は暗いまま）、ドアを取り外すか（閉じたドアから光が漏れてしまう）を決めなければなりませんでした。バウンスを「ごまかす」ためにランタイムライトをスクリプトで追加することもできますが、これは時間がかかり、コストもかかります。以下では、ベイク時間のパフォーマンスに過度の影響を与えずにダイナミックドアを可能にするために、ダイナミックライトセットシステムを拡張した方法を説明します。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

4.1 Doors as dynamic light sets

我々の目標の一つ（G.3）は、ランタイムの実装をできるだけシンプルにすることです。ダイナミックライトセットの効率的な実装に投資したので、これを可能な限り再利用するためのドアが欲しかったのです。課題は、ドアを開けたときに起こる照明の変化を、ベースとなる照明の加算成分として表現することでした。ドアの現在の「開き角度」に基づいてランタイムに計算される重み\(\omega_{\mathrm{P}}\)によって線形に制御できる、ドアごとの寄与の1セット、\(\mathcal{S}_{\mathrm{P}}\)に到達したいと考えています。

予備的な前提条件.
これを実現するために、いくつかの単純化された仮定をしています。私たちは、ドアがシーン内を移動するときに起こる複雑な非線形照明の変化を2つの状態に縮小します。「閉じた」状態と「開いた」状態です。「閉じた」状態では、ドアモデルは完全に閉じた位置に置かれ、「開いた」状態ではモデルを完全に無視します。別のオプションとして、「開いた」位置に配置することもできますが、私たちのレベルのドアの多くは、外側と内側の両方に開いていて、「開いた」位置が明確に定義されていません。さらに、閉じた状態でドアに当たる光も無視しています。これを計算するには、ドアが開いたときに光を取り除く必要がありますが、これは我々のダイナミックライトセットシステムとは直接互換性がありません。比較的簡単に実現する方法はありますが、バウンスライトの欠落は大きな影響を与えるものではありませんでした。最後に、複数のドアやダイナミック・ライト・セットがあるレベルでダイナミック・ライティングをベイクする際には、シーン内の他のすべてのインタラクティブ要素の状態を選択しなければなりません。これは、ダイナミックライトセット自体の問題ではありませんでした。ここでは、ライティングは線形に加算され、個々のライトセットの寄与は、他のライトが有効かどうかに影響されません。しかし、ドアの場合、ドアが開いているかどうかは、他のドアだけでなく、ダイナミックライトセットからの光の伝搬にも非線形に影響します。\(n\)個のDLSと\(m\)個のドアに対して正しい結果を得るためには、状態のすべての\((1+n)2^m\)の組み合わせをベークする必要がありますが、これはすぐに解決困難であることが分かります。ドアは比較的離れていることが多いです。そのため、この技術を使って最終的なゲームを出荷する時点では、ダイナミックライトセットとドアベークのそれぞれについて、他のすべてのドアが閉じていることを想定していました。これにより、組み合わせの数が減り、 もちろん、これらすべての単純化は、いくつかの状況ではアーティファクトを招きますが、可能な解決策と一緒にセクション6.2で説明します。

ドアパスの描写.
この問題を推論するために、第2節で紹介したパス表記法を拡張し、閉じた状態のドアを示すために\(\mathrm{P}\)を使用することにします。最初のステップとして、任意の時点でドアと相互作用するすべてのパスを特定します。つまり、次のような形のパスです。

\begin{eqnarray}
\underbrace{ \mathrm{LD}^* }_{\mathrm{emitter \, side}} \overbrace{(\mathrm{PD}^* )^+}^{\mathrm{door \, interactions}} \underbrace{\mathrm{D}^* \mathrm{R}}_{\mathrm{receiver \, side}} . \tag{3}
\end{eqnarray}

ドアが持つかもしれない光の寄与を分離するために、ベースベイクではアルベドを 0 にして、それと相互作用するパスを取り除きます。これにより、通常通りベースベイクを実行し、ドアと相互作用しない照明を効率的に計算することができます。あとは、残りのパスを処理するだけです。

4.2 Efficient sampling techniques

最後のセクションでは、パス空間のどの部分の照明を計算したいかを非常に狭く定義することができました。これを行うためのナイーブなアプローチは、レベル内の各レシーバから始まるパスをトレースし、ドアと相互作用するパスからの寄与のみをカウントするというものです。これにより正しい結果が得られますが、ドアは通常レベルのサイズに比べて小さく、任意のパスが特定のドアに当たる確率は低くなります。ドアと相互作用するパスを効率的に計算するためには、ドアに向かってパスを誘導する必要があります。一般的なパスガイド手法 [Hey and Purgathofer 2002; Jensen 1995; Muller et al. 2017; Vorba et al. 2014] を使用することができ、ベースベイク中に Silvennoinen and Sloan [2019] の技術を使用することもできますが、ドアパスのより制約の多い構造を利用する機会があります。ベイク時間を短縮するために、我々は、全体的な照明への寄与が最も高いと観察されたパスの特定のサブセットへと制限します。これらを図7に示します。はっきりいうと、ドアを直接通る照明とその最初のバウンスを計算します。したがって、我々は、直接ドアに向かってギャザーレイをガイドし、ドアを通って強く照らされている領域に向かってギャザーレイをガイドしたいと考えています。ここで、ドアを直接通過することは、直接照明とは等価ではないことに注意してください。つまり、光源に接続するだけでなく、ドアの反対側のジオメトリからのバウンス照明も考慮に入れたいのです。幸いなことに、ベースベイク時に計算された情報の多くを利用することができます。例えば、ドアを通過した光線が反対側のライトマップされたモデルに当たった場合、格納されている間接照明を単純にサンプリングすることができます。

エリア光源としてのドア.
ドアに近いレシーバーに対して、多くの寄与経路は\(\mathrm{LD}^+ \mathrm{PR}\)の形をしています。図7(a)に示すように、エミッタ側から直接、レシーバー側にバウンスがない状態で到着する。枠に近い床上のレシーバーの場合、ドアは広い立体角を補助しています。これらの場合では、ドアの開口部は（複雑な）エリア光源を形成しています。この寄与を計算するために、我々は、ドアの配向されたバウンディングボックス上の点を描画し、それらに向かってレイをキャストするために層状サンプラーを使用しています。ドアの立体角が広がるほど、積分のこの部分に向かって割り当てるレイの数が多くなります。これは、オフラインレンダリング[Bitterlie et al. 2015]で使用されるポータルサンプリング戦略に似ていますが、ポータルに向かってレイをガイドすることに加えて、これらの方法は、ポータルを通る照明の方向分布も考慮に入れています。残念ながら、我々のシナリオではそれは非常に複雑です。環境マップのサンプリングとは対照的に、レシーバーに到達する照明は、方向だけでなく、ポータルに対する相対的な位置にも依存する。我々は、ライトフィールドインポータンスサンプリング戦略[Lu et al. 2014]を使用して、ドアのバウンディングボックス上のサンプルをより良く寄与させることを試みましたが、分散の差は最小であることがわかりました。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

パスガイディングのためのクラスタ化されたシャドウフォトン
積分のもう一つの大きな部分は、ドアから流れるワンバウンスの間接照明です。すなわち、図7(b)に示すような形態の\(\mathrm{LPDR}\)の経路となります。特に、ドアを開けると部屋の中に太陽光の明るい光路があり、この光路からのバウンス照明がドア照明を支配するというシナリオが多いことに気がつきました。この照明を効果的にサンプリングするために、シャドウ・フォトン[Jensen 1996]にヒントを得た手法を採用しました。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

前処理のステップでは、ドアのバウンディングボックス上の点（紫色のドット）を一様にサンプリングします（紫色のボックス）。各サンプル点に対して、ランダムに選ばれた光源（実線の矢印）に向かってシャドウレイを送ります。シャドウテストが成功した場合、この光がドアを流れる光に寄与し、部屋の中のサーフェイスに当たることがわかります。次に、反対方向（破線）にキャストして、部屋の中の対応するヒットポイントを見つけ、シャドウフォトン（緑、黄、青のドット）を堆積させることができます。これにより、効果的に、ドアに遮られた直接光の「フォトンマップ」が得られます。
　集光ステップでは、フォトンの密度が高い領域に向けてレイを送りたいのですが、さらに、積分のどの部分も見逃さないように、一般的なギャザーレイを送る必要があります。マルチプルインポータンスサンプリング(MIS) [Veach and Guibas 1995]や基本的な積分分割を適用するためには、我々のガイド戦略によって一様なギャザーレイが生成されたかどうかを見分けることができる必要があります。これは、照明された領域をフォトンの点で表現する場合には困難であり、コストがかかります。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

問題を単純化するために、前処理の最後にシャドウフォトンを指向性バウンディングボックス（色のついた領域）にクラスター化しています。これは、部屋に落ちる光の良い近似を得るために何千ものフォトンを送ることができることを意味し、その情報をいくつかの（我々の実装では12個の）強い直射光のある領域をおおむねカバーするバウンディングボックスに減らすことができます。
これで、これらのバウンディングボックスを、レイガイディングの目的のための「エリア光源」として扱うことができるようになりました。つまり、いくつかの多光源法 [Luksch et al. 2013] で行われているように、照明を直接計算するためにそれらを使用するのではなく、むしろ寄与度の高い方向に集まるレイをガイドするためのプロキシとして使用します。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

これにより、バウンディングボックスとの交点を計算することで、ガイドされた方向(赤)と一様半球のサンプリングされた方向(ティール色)を正確に組み合わせることができます。もし一様にサンプリングされた光線がバウンディングボックスの一つ（赤-ティール色の縞模様）と交差した場合、ガイド技術を用いてそれを生成できたことがわかり、対応するMISの重みを計算することができます。ボックスの集合が少ないので、加速構造がなくても高速に計算することができます。もちろん、バウンディングボックスを使うということは、重要度の近似がかなり大雑把であることを意味し、直射光の特徴をいくつか見逃してしまうかもしれません。また、可視性も考慮に入れていませんし、多くのモデルを含む大きな部屋では、重要度とサンプル化された光線の多くが光のパッチに到達しないかもしれません。実際には、特に計算上の影響領域との組み合わせでは、これが大きな問題になることはありません。我々はMISを介したガイド戦略を一様な半球サンプリングと組み合わせているので、これらの問題は我々の推定器に偏りを与えず、失敗例の分散を増加させるだけです。

直接光カリング.
ベイキングプロセスをさらに高速化するために、シャドウフォトンから計算されたバウンディングボックスを別の方法で使用します。ドアを通る直接照明については、理論的にはシーン内のすべての照明を評価する必要があります。それらのほとんどは寄与しないだろうし、一般的なケースでは、それらを選別することは困難な問題です[Dachsbacher et al.]。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

各バウンディングボックス内のシャドウフォトンがどの光から発生したかを追跡して、バウンディングボックスごとにライトのリストを構築します。シェーディングを評価する際には、シェードポイント（黄色の点）があるバウンディングボックスを見つけ、そのボックスに関連するライトのみを使用します。これは、バウンディングボックスがタイトすぎると、いくつかのライトを見逃してしまうことを意味します。これを軽減するために、外接枠を人為的に膨らませます。さらに、バウンスライトを計算している間は、この照明の寄与のみを使用しているので、アーティファクトはそれほど目立ちません。

5 EVALUATION AND RESULT

性能特性を様々な条件で徹底的にドキュメント化し、システムを評価しています。図1と図8は、ゲーム性を向上させるためのダイナミックライトセットの代表的な使用例を示しています。より大きな画像と実際のシステムを示すビデオについては、補足資料を参照してください。我々の意図は、システムが実際にどのように動作するかを示すことであり、したがって、我々が示すすべてのタイミングとメモリの統計は、最近のゲームで出荷されたプロダクションコンテンツから取られています。表1にシステムのパフォーマンスの概要を示します。多くのレベルでは 10 個のダイナミックライトセットが使用されていますが、ドアはあまり使用されていないことに注意してください。これは、アーティストが DLS を探索するために複数の制作サイクルを持っていたのに対し、ドア技術は最後の制作中に遅れて導入され、要求された特定の状況でのみ使用されていたためです。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

※表は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

ベイク時間のパフォーマンス評価
私たちのレベルは、通常、複数の平方マイルの地形の上にあり、建物や小道具で満たされています。この規模の環境では、以前の静的なベイクシステムでも、何時間ものベイク時間がかかることは珍しくありません。これらの時間は、出荷されたゲームで使用されているように、最高品質の設定のためのものです。イテレーションの間、アーティストは、多少のノイズはあるものの、代表的な結果が得られ、それに応じてベイク時間が速くなるように、より低い設定を使用しています。

ランタイムパフォーマンス評価
セクション3で紹介したランタイム最適化は、レベルごとにアーティストが使用できるライトセットの数に大きな影響を与えました。動的なライトベイクシステムを使用した最初のゲームでは、マップごとにライトセット数を一桁に抑えるように指示されていましたが、最後のゲームが出荷される頃には、ランタイムパフォーマンスにほとんど影響を与えずに何百ものDLSをサポートすることができるようになりました。複数のマップでシステムのパフォーマンスオーバーヘッドを測定した結果を表1 に示します。通常のゲームプレイ条件では、ダイナミックライティングは全体的なフレームタイムに影響を与えないことがわかりました。これは，ワークロードが小さく，GPU 上で非同期的に実行され，他のタスクが残した利用率のギャップを埋めていることに起因します．残念ながら、これではオーバーヘッドを正確に測定することもできません。しかし、更新を同期的に実行する特別なデバッグモードがあります。また、すべてのライトセット（通常のモードのように、前のフレームから状態が変化したものだけでなく）を更新します。表 1 の最後の列の数値は、このデバッグモードを使用して測定したものです。すべてのライトセットをフレームごとに更新するように強制した場合（実際には起こらない）、同期実行を強制した場合（GPU の利用が悪い）でも、最大のプロダクションマップでは、動的なライト更新には最大でも 1.47ms かかることがわかります。

6 DISCUSSION, LIMITATIONS, AND FUTURE WORK

私たちが説明したシステムは、導入部で示した基準を満たしており、いくつかのリリースされたゲームだけでなく、今後のAAAゲームでも使用されています。以下では、このシステムの歴史的な観点、現在の制限、それがどのようにユースケースを制限しているか、そして最後に、将来的にこのシステムをどのように進化させていくかについて述べていきます。

6.1 Historical evolution

LLGの前は、ライトマップされていないメッシュの各頂点にディレクショナルライティング情報を格納していました。詳細で細かくテッセレーションされたメッシュでは、これは非常に高い品質を提供しましたが、照明データが各インスタンスで一意であるため、メモリフットプリントとベイクする時間が増えました。また、単一方向の輝度サンプルをメッシュ全体に使用することもできますが、セルフシャドウイング情報が利用できないため、結果としての品質は劣っていました。メモリフットプリントを劇的に削減した LLG は、将来のゲームで動的なライティング要素をサポートするために明示的に行った最初の変更でした。最初に LLG を実装したのは、最初に出荷したゲーム (2014 年) で使用されており頂点単位のライティングのベイクを高速化するためでした。2作目（2016年）では、LLGをランタイムに移行し、3作目（2017年）では、初めて動的更新をサポートしたため、頂点のベイクを一斉に削除しました。アーティストは当初、品質低下の可能性を懸念していましたが、LGGの実装を最適化することで、メモリコストの何分の1かでビジュアル品質を満たすことができるようになりました。

6.2 Limitations

我々のシステムにはいくつかの制限があり、あるものは設計に固有のもので、あるものは我々の特定の実装における選択に起因するものです。設計に起因する制限の多くは、ライトベイキングシステムでは一般的なものであり、動的要素を導入する前にも、これらの制限を念頭に置いておく必要がありました。もちろん、レベルデザイナーが特定のインタラクティブ要素やダイナミックライトに手動でラベルを貼らなければならないという事実が最も大きな制限となっています。インタラクティブ要素を追加したり、インタラクティブ要素を追加したりするには、マップ全体のベイクをやり直す必要があり、これには数時間かかることがあります（表 1 を参照）。実際には、再ベイクは一般的であり、マップへの多くのタイプの変更によって引き起こされるため、これは大きな追加の制限ではありません。本論文では実装特有の制限について触れてきましたが、ここでは最も重要な制限を再要約し、その制限を解除する方法についての考えを提供します。

ドアの状態とドアからのバウンス照明
セクション4で説明したように、ドアが存在し得る状態と、ドアが光を遮断している状態について、いくつかの単純化された仮定を行います。特に、ドアが開いている状態でのドア形状との交点は一切計算しません。このため、図9のような光漏れが発生する可能性があります。これを修正することは難しいことではなく、単に当時は他の作業よりも重要性が低いと判断されていただけです。ドアの状態を選択して「開いている」状態にすることで、選択した状態で開いているドアのベイクにモデルを含めることができます。これにより、オクルージョンが正しく計算されます。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

　解決が困難なアーティファクトは、ドアが閉まっているときにドアの外にあるバウンスライトが欠落していることです。これは、現在のところ、各ドアが照明の寄与を正確に1セット追加しているためです。ドアが閉じているときには、何の照明も追加されていないので、バウンスライトがありません。ドアが開いているときにもバウンスライトは常に存在しているので、ベースベイクにもバウンスライトを単純に含めることはできません。一つの解決策として、ドアに追加の照明を持たせることが考えられます。このとき、ドアに照明を追加することを考えます。そうすれば、バウンス光を一つの寄与としてベイクし、ドアを流れる光を別の寄与としてベイクし、それらの間を補間することができます。正確には二つの状態については、これを単純化して一つの貢献セットに戻すこともできます。\(\mathcal{S}_{\mathrm{C}}\) を閉じたドアから跳ね返ってくる光、\(\mathcal{S}_{\mathrm{O}}\) を開いているときにドアを流れる光、\(\omega_{\mathrm{C}}\), \(\omega_{\mathrm{O}}\) をそれぞれのブレンドの重みと考えてください。2つの状態の間を線形に補間するので、\(\omega_{\mathrm{C}} = 1 – \omega_{\mathrm{O}}\)がわかり、ドアによる全体的な照明の寄与を\(\mathcal{S}_{\mathrm{P}} = (1 – \omega_{\mathrm{C}}) \cdot \mathcal{S}_{\mathrm{C}} + \omega_{\mathrm{O}} \cdot \mathcal{S}_{\mathrm{O}} = \mathcal{S}_{\mathrm{C}} + \omega_{\mathrm{O}} \cdot (\mathcal{S}_{\mathrm{O}} – \mathcal{S}_{\mathrm{C}})\)として表現することができます。\(\mathcal{S}_{\mathrm{C}}\)はドアのランタイム状態から独立しているので、ベース照明に追加することができ、ドアごとに1つの照明寄与のセットに戻ることができます。残念ながら、この最適化はドアごとに2つ以上の状態には一般化できません。

ドアとダイナミックなライトセットの間の相互作用
セクション４で説明したように、我々のシステムでは、各動的要素はそれ自体が独立しており、幾何学的な変化（例えば、ドアが開くことによる）によって必要とされるそれらの間の光の相互作用は考慮されていません。このため、図10に示すような状況では、現在の方法では、2番目の部屋の奥の壁に到達する光を計算することができないため、照明を正しく計算することができません。幸いなことに、前作からすでに実装されている小さな拡張機能があり、この制限を解除することができます。含めたい組み合わせの状態ごとに、ドアが開いていてダイナミックライトセットが有効な組み合わせを指定して、別のベイクパスを実行します。組み合わせに複数の開いたドアが含まれている場合は、そのすべてと相互作用する貢献経路を確認する必要があります。紹介したテクニックをそのまま利用してベーキング性能を向上させることができます。組み合わせの爆発を直接処理しないことに注意してください。その代わりに、アーティストが組み合わせ効果に加えるべき個々のライトセットとドアを選択し、加える要素の影響半径が重なる組み合わせのみを含めることを許可します。

※図は，DARIO SEYB, PETER-PIKE SLOAN, ARI SILVENNONINEN, MICHAL IWANICKI, WOJCIECH JAROSZ, “The design and evolution of the UBERBAKE light baking system”, ACM Trans. Graph., Vol. 39, No. 4, Article 150. July 2020より引用.

6.3 Future work and outlook

本稿では拡散照明のみを取り上げました。非拡散相互作用はリフレクションプローブによって処理され、低グロスなマテリアルは最適化として低周波入射照明に対して直接統合されます。我々は、オフラインで計算する際に照度で割った正規化反射プローブ[Lazarov 2013]を使用し、環境マップをサンプリングした後に乗算して戻します。ベイクされた照明データを更新するだけで、特に照明の変化に対して、もっともらしいスペキュラー結果を生成します。形状変化に対しては、将来的に反射プローブを更新する他の方法を検討すべきです。今後の制作では、既存のシステムを拡張して、より複雑な照明の変化に対応することになるでしょう。前のセクションで説明したように現在の制限をいくつか解除した後、簡単な次のステップは、ダイナミックドアのために使用している技術を他の類似したシナリオに一般化することです。壁や天井が破壊されるようなイベントは簡単で、レベルデザインの多様なニーズに対応する能力に大きな影響を与えます。
最後に、学術界や産業界では、リアルタイムのレイトレーシングに刺激的な進展があり、最高レベルのハードウェアでは、現在でもベイクされた照明に代わる可能性のあるシナリオがあります。より広く採用されるために、リアルタイム レイトレーシング技術が直面しなければならない主な問題は、ここで紹介したランタイム オーバーヘッドの要件が、決して贅沢なものではなく、異常に制限されているわけではないということです。特にAAAゲームは、一般的に非常にパフォーマンスの高い技術を必要とし、オーバーヘッドはマイクロ秒単位で測定されることが多いです。近い将来、リアルタイムのレイトレーシングでこれを実現するために、ここで紹介したアイデアの多くが役に立つと思われます。例えば、フレームと最終解像度から切り離されたデータ構造の更新を行うことで、完全に一般的ではなく（特定のエフェクトに焦点を当てる）、はるかに低いパフォーマンス コストで忠実度を高めることができます。これが、速度、メモリ、事前計算時間、一般的な技術と特殊な技術など、多くの利用可能な軸を横断してパレートフロンティアを探求することに興味を持っている理由です。私たちは、レイトレーシングが勝ついくつかのサブディメンションと、ベイクされた照明を置き換えるのに非常に長い時間がかかるいくつかのコンテキストがあることを期待しています。それは、携帯電話のようなローエンドのプラットフォームでは、複雑なシーンをレイトレーシングするのが困難な状況が続くでしょうし、AAAゲームがターゲット層を拡大しようとしているので、事前計算に依存した手法は、当面の間有用であると見ています。

ACKNOWLEDGMENTS

システムを設計しながら、多くの才能あるライターと一緒に仕事をすることができたのは幸運でした：Luka Romel、Vivian Ding、Dave Blizard、Omar Gatica、Velinda Reys、Krzystof Wojcik、Marko Vukovic。マイケル・スタークとアドリアン・デュブシェがUBERBAKEコードに貢献しました。また、何人かのエンジニアと密接に協力しました。Stephanus Fnu、Danny Chan、Michal Drobot、Peter Pon、Akimitsu Hogge、Michael Vanceです。また、Andy Hendrickson、Dave Stohl、Patrick Kellyの励ましとサポートにも感謝しています。