Advanced Lighting R&D at Ready At Dawn Studios

焼き込み式大域照明（Baked Global Illumination）

• 目標
  • 高品質な静的GI
  • 焼き込まれた環境
  • 焼き込まれたキャラクターライティング
  • ディフューズとスペキュラ

The Order: 1886は屋内と屋外の両方の中くらいの大きさのレベルを持つリニアなゲームである。このゲームはそのライティング的にかなり静的であり、我々のプロジェクトに対して静的に焼き込まれたGIソリューションを使うのに最も理に適っている。

ディフューズライティングだけでなくスペキュラGIも同様にキャプチャするのが重要である。焼き込まれたスペキュラを強く推し進める多くの理由のひとつはキューブマップを用いることで発生する制限である(間違った場所と角度の品質で間違った反射を空間的に取得する)。

沢山の解決法を試した（Tried Many Solutions）

• 焼き込まれたAO
• SG(5, 6, 9, 12)
• SH(4, 9)
• 方向性ディフューズ
• PRT
• 方向性AO
• RGBディフューズ
• 透視投影補正キューブマップ
• H-Basis4/6
• H-Basis AO

我々は開発中に多くのテクニックを試したが、これらの中に我々のニーズにピタリと一致するものはなかった。いくつかのテクニックは小道具用のスペキュラおよびディフューズオクルージョンのためのH-Basis AOのような出荷する製品に残ったままになっている。

しかしながら、最終的には｜球面ガウス《Spherical Gaussians》を用いることになり、これに決定した理由を手短に見ていこうと思う。

球面調和ディフューズ（Spherical Harmonics Diffuse）

• 良い場合: 低い周波数の信号
• 悪い場合: 高い強度、方向性のライティング

注意: 信号をブラーするコストでリンギング《ringing》を減らすために窓関数を適用できる。

HDRライティングは、高い正の係数を打ち消すような非常に大きな負数になる、とあるローブを引き起こす可能性がある。これは品質や圧縮に悪影響である。

球面調和リンギング（Spherical Harmonics Ringing）

リンギングは我々のゲーム中には、ライティングコストを抑えるために直接光を焼き込むときに現れる。これはキャラクターを死んだ/ゾンビのような見た目にしてしまう。リンギングはライティングを、例えば前頭部では行き過ぎに、光の当たらない側では暗すぎにしてしまう。

球面調和スペキュラ（Spherical Harmonics Specular）

• 高周波データには大量の係数が必要
• 評価が高価
  • テクスチャルックアップ
  • SHの回転
  • 評価

我々はBungieが実装した球面調和スペキュラを試した。ルックアップ、SH回転、BRDF評価の組み合わせにより少々高価すぎた。

• SH9は｜艶消し《matte》のように見える。

9つの係数のみではマットなルックになる。係数が16つあれば十分良好だが、そのコストは間違いなく当時では高価すぎていた。

キューブマップスペキュラ（Cubemap Specular）

• 非局所的なサンプリングアーティファクト

• ライティング信号とBRDFにより近く合致する。
• 非局所的
  • AABBの｜透視投影の歪み《perspective warping》を実装した。
  • 未だ完璧ではなく、正方形でない部屋を｜作る《author》のが難しい。
• ｜輝く《glowing》エッジを引き起こす。
  • オクルージョンの欠落

• 局所化とオクルージョンの問題

左のスクリーンショットは我々のゲームではとても一般的な問題である。誤ったスペキュラプロブの捕捉《grabbing》は暗い所やエネルギー不足の所で輝くエッジを引き起こすだろう。

方向性オクルージョンをH-Basisに焼き込み、アーティストに距離を指定させようと試みたが、これは難しく、間違いを起こしがちであった。また、キューブマップが誤った位置にあるために、スペキュラが欲しいときに役に立たなかったり、そもそも得られなかったりもした。アーティストはキューブマップの配置の調整に多くの時間を費やした。

球面ガウス基底（Spherical Gaussian Basis）

ここには3つの主なテクニックの比較がある。球面ガウスでは、ハイライトの幅がパストレースの解に最も近く一致することに注目する。

球面ガウスGI（Spherical Gaussian GI）

キューブマップとSH9（Cubemap and SH9）

これはキューブマップでの焼き込まれたディフューズライティングを示す古いスクリーンショットである。そのエネルギーは平坦に見え、床は得るべきでないところまでエネルギーを得ている。

球面ガウシアン（Spherical Gaussians）

この例では、球面ガウシアンを用いて焼きこまれている。光や影があるべきところにあることに注目する。このシーンは、シャドウとハイライトが混ざっているので、より興味深いものになっているように見える。

スペキュラの焼き込み（Baking Specular）

このシーンでは、球面ガウシアンライティングを無効化した。

• 複数の光源が適切にライトマップにキャプチャされる。
• キューブマップによるエイリアシングがない(追加のおまけ)。

再び有効化するときは、ライト周りのホットスポットに注目する。各光源の周りに多くのキューブマップを配置する必要があるので、この種のライティングをキューブマップでキャプチャするのは非常に困難だろう。

このシーンは非常に暗い --- 多くのスペキュラを付け損なっている。この例では、アーティストはキューブマップを十分に持っていなかった。なので、このエリアにひとつでもキューブマップを置けば、おそらく多少は良くなっただろう。しかし、このレベルではメモリの制約によりそれをしなかった。このレベルはとても大きく、膨大な量のゲームプレイエリアがあったので、すべてのスポットで十分なキューブマップを得ることは実行可能な選択肢ではなかった。

• ｜引き伸ばされた《stretched》ハイライト
  • キューブマップは等方的なPhongハイライトのみを持つ。
  • SGは長く引き伸ばされたハイライトを持つことができる。

有効化すると、このエリアのSGのエネルギーが戻ってきて、金属の梁に引き伸ばされたハイライトを得ることに注目する。キューブマップが円形ハイライトのみをサポートするのに対し、球面ガウシアンは｜細長い《elongated》ハイライトを可能にするBRDFに対する半角パラメータ化を用いる。

この例では、2箇所が確認できる。床と木のパネルで細長いハイライトが確認できる。このエリアでキューブマップのみを用いていた場合にはジオメトリのすべてが明るく輝いていたであろう複雑なジオメトリにも気付く。

基本的な数学的特性（Basic Mathematical Properties）

球面ガウシアン（Spherical Gaussians）

• $A$: 縦幅《amplitude》
• $W$: 横幅《Width》
• $M$: 平均《Mean》

私見では、SGは、直観的なパラメータを持つので、理解しやすい方である。

これらは等方的なので、2Dでグラフ化できる。この可視化では、真ん中で輪切りにして、X軸を平均からの角度で表している。

これは平均からの測地的な距離に基づいて減少《falloff》する関数のような指数関数的ガウシアンである。

• 平均は指す方向を制御する。
• 横幅はフォールオフを制御する。
• 縦幅は高さ又は強度を制御する。

平均は単純な正規化済み方向ベクトルである。望みの方向に回転するのは容易い。

横幅パラメータ、または、たまにフォールオフ、周波数《frequency》、逆幅《inverse width》と呼ばれるそれは、関数がどれだけ素早く平均から減少するかを制御する。

横幅パラメータを変更すると、関数が持つエネルギーの総量を変更する。

縦幅は高さを制御する。これは線形な応答を持つので、より直観的なパラメータのひとつである。例えば、関数に2をかければ、平均方向で高さが2倍になる。

しかし、高さを変更すると、関数の総エネルギー量を変更することにも注意する。故に、振幅と周波数は関数の総エネルギー量に対して結びつけられる。

• SG (演算子) SG = SG (閉じた演算子)
  • 回転は単純な3Dベクトルの回転である。
  • 閉形式の積分
    • 畳み込み、内積
  • 閉形式の積《product》
    • 二重積《double product?》、三重積《triple product》、など

SGの実際の力はどれだけの演算と閉形式の演算をサポートするかによる。ほとんどの演算は別のSGを生成するので、多くの単純なものをつなぎ合わせ、単一のSGを得ることができる。

これはレンダリング方程式のような複雑な数式を取り、解析的に評価できるようにする。

• 複雑な信号を表現するために足し合わせることができる。

SGで可能になるもうひとつの本当に興味深い演算はそれらを足し合わせることである。

左に青い壁、赤い天井、右に緑の壁のある部屋があると想像しよう。上記の図のにあるようなSGで各方向からの放射輝度を表すことができる場合、右の関数を得るために足し合わせることができる。

右の関数のサンプリングを単純化すると、その方向での放射輝度を得るだろう。

• エリアライトを表現できる。

SGはエリアライトを表現できる。

• …それと、様々なBRDF。

SGはBRDFを表現できる。

SGライトマップ（SG Lightmaps）

ライトマップデータ（Light Map Data）

• 5、6、9、12のRGBの 非負 のHDR係数
  • 係数の数は任意
  • SH4/H-Basis4を置き換えるために4を使うことができる。
• 色データのみを含む。
• BC6で圧縮されたライトマップ
• 平均方向と横幅はシェーダにハードコートされた定数である。

ライトマップに格納されるデータはHDRのRGB色のみである。持つローブの数は持つライトマップの数を指示《dictate》する。アーティストがこの概念を理解するのはとても簡単で直観的である。ライトマップはローブ方向での放射輝度を表すので、SHとは異なり各ライトマップでどうなっているかを詳しく｜調べ《inspect》、理解することは非常に容易である。

係数は圧縮や精度の助けになる正の値のみである。

方向と横幅はライトマップには格納されない。

SGの焼き込まれたライティング（SG Baked Lighting）

• 各ライトマップのテクセルに焼き込まれたSGの合計として放射輝度を表現する。

ここにはライトマップの各テクセルでの球面ガウシアンの可視化がある。各半球はSGの数の合計である。見ての通り、図中の球は、右の赤の壁、上部の空、カメラや床の背後の緑の壁から来るの放射輝度を示す。

固定の方向（Fixed Directions）

• 球上で均等に分けた方向の固定のセット
• 5、6、9、12
• 黄金比の螺旋を用いる。

ローブ数に基づいて、黄金比の螺旋のアルゴリズムを用いて方向の一様分布を生成する。

固定の横幅（Fixed Widths）

• 横幅
  • 小さすぎる == 乖離
  • 大きすぎる == 過剰ブラー
  • 丁度いい

横幅は、連続的で、乖離がなく、信号を過剰にブラーするほど広すぎたりしないように、解決する必要がある。

なぜ固定の基底か？（Why Fixed Basis?）

• 可変のスカラの数
  • 27つの色用スカラ (9 * 3)
  • 9つの横幅
  • 18つの方向用スカラ ($\theta$/$\phi$)
  • == 54
• 固定のスカラの数
  • == 27
• 固定の利点
  • 同じデータ量で2倍多い方向
  • より多い最適化の機会
  • 隣接テクセル間の補間問題がない

SGを伴うライティング（Lighting with SGs）

• 基本のアイデア
  • SGの合計として放射輝度を表現する。
  • ひとつのSGとしてBRDFを表現する。

SGの合計として放射輝度を、ひとつのSGとしてBRDFを表現できるならば、ライティングを得るためにSGの解析的な積分演算を用いることができる。これが基本のアイデアである。

SGの焼き込まれたライティング（SG Baked Lighting）

• 実際の実装はもっと複雑である。
  • Fresnel
  • シャドウイング
  • マスキング
  • NDFの歪曲《warping》
    • NDF SGは半角でパラメータ化される。
    • 放射輝度SGはライト方向でパラメータ化される。
    • 効率的なSGの乗算のために同じ空間にある必要がある。

• NDF近似
  • Beckmann = 1つのSG
  • GGX = 3つのSG

BeckmannのNDFの近似は1つのSGだけで極めて正確に行うことができる。GGXのBRDFは良好な｜長いテール《wide tail》を得るために3つのSGを必要とする。

1。しかし、アンビエントライティングでは、GGXローブのテールはパンクチュアルな光源では言うほど目立たない。なので、このスライドのようにひどくはならない。

SGを伴うライティング（Lighting with SGs）

• NDF * 放射輝度 (不可能: 空間が異なる！)
  • NDF = 半角空間
  • 放射輝度 = 正接空間

残念ながら、SGへの入力パラメータが異なる空間にあるため、放射輝度とNDFを解析的に積分できない。ライティング方向で積分する場合、NDFではそのライティング方向を半角方向に変換しなければならない。主なアイデアは、同じ方向を指し、その空間でNDFを最も良く表す他のSGを生成する。

このアイデアではまず、ライト方向の方向を指すようにNDFを回転する。そして、NDFのエネルギーを最も良く表すように横幅を修正する。しかし、SGは対称的に横幅を修正することしかできないが、半角パラメータ化により、他よりもある方向に実際にスケールする。このため、SGをASG(非対称球面ガウシアン)に昇格させる。これは2つの方向で個別に伸縮《stretch》することができるようになる。

ここでは、対称SGの歪みと非対称SGの歪み、対、パストレースの結果の例である。

• ライティング方程式

これはライティング方程式が球上の関数をレンダリングすることのように見えるものである。

歪んだNDFはASGとして表現される。

放射輝度はSGの合計として表現される。

Fresnel、シャドウイング、マスキング関数はグラフィクスで使う典型的な関数である。Fresnel関数とシャドウイング関数はその領域上で非常に滑らかな関数であることに注目する。

マスキング関数は、ビュー方向でパラメータ化される一方、ライティング方向の領域上で積分しているので、積分に関する定数の関数である。

• ライティング方程式

我々が行える最初のことは、マスキング関数が積分に関して定数なので、外に出すことである。

• ライティング方程式

そして、Fresnelとシャドウイングは非常に滑らかなので、外に出すことができる。これは、積分の平均値定理《mean value theorem》のため、かなり強烈な近似である。それが平均値《average value》となるので、良好な代表的な方向を選び取る必要がある。我々はFresnelやシャドウイングを評価するためにライト方向を選択する。

これはかなり強烈な近似であるが、もう少しランタイムコストを支払うことを気にしなければ、さらに高い正確さを得るために2つの区分的線型近似を行うことができる。

3つの項を外に出すと、これらの関数の積を取り、ASGとSGの解析的な積分で乗算することができるようになる。

最終的なアンビエントライティングを評価するために、それぞれのFresnel項やシャドウイング項で乗算されたSGでASGの積分を要約する。そして、右にある最終結果を得るためにマスキング関数で乗算する。

鏡のようなマテリアル（Mirror-Like Materials）

• 基本のアイデア
  • 粗いマテリアル == SG
  • 光沢のあるマテリアル == キューブマップ
  • 中間 ~= lerp(SG, キューブマップ)

実践では

テストシーンではあるところで最大0.2のラフネス

ローブ数に依存する。

アーティストはレベルごとに内外の特定のブレンドポイントを制御する。

球面ガウシアン/キューブマップブレンディングの可視化（Spherical Gaussians / Cube Map Blending Visualization）

このシーンに対するブレンディング重みの特定の選択の可視化

カスタムBRDFの扱い方（Handling Custom BRDFs）

• Beckmann/GGXはSGとしてうまく動作する。
• 布＆髪は表現できるが、より手間がかかる。
  • 参考文献を参照
• 時間がなかった。
  • SGのライトマップデータを点ライトとして扱い、布/髪をN回評価する。

注意: 空間的なエネルギー問題がキューブマップで悪化したので、単に好みでなかったこれらのBRDFを持つキューブマップに対してフォールバックがあった。

ポストモーテムと今後のR&D（Post-Mortem and Future R&D）

振り返り（Looking Back）

• The Order: 1886は2015年2月に出荷した。
• いくつかの技術的選択がうまくいった！
  • マテリアルパイプライン
  • SG焼き込み
• 何か改善できることは？

2月にThe Orderの開発を終了してからは、我々の技術を精査するための時間であったので、強みと弱みを評価できた。いくつかのケースでは、このコースの2013年バージョンで示したマテリアルやシェーディングパイプラインのように、我々の選択が良好なランタイム結果と同様に効率的なアーティスト用オーサリングパイプラインの両方を生成する観点でうまく働いたことは目にも明らかであった。しかし、高品質なアセットを生成するのに必要な時間を少なくできたと思われるような改善の余地があると感じた場所も多くあった。

R&Dの原則（R&D Principles）

• 実際のニーズで駆動する
  • 自分で考えたことが最高ってだけじゃなくて
• 厳しくせず、ゆとりを持とう
• デフォルトで物理ベース
  • もっともらしく、現実世界の値を規定値とする

この仕事を始めたとき、我々の目標は何であるか、そして、技術改善の価値のある候補がどれくらいあるかについて注意深く腰を据えて考えた。Daveと私は物理ベースレンダリング技術にかなり熱心《enthusiastic》で、より厳密に現実世界の振る舞いに基づいたモデルを持つことを目的に純粋に我々の技術を変更することについて夢中になることは容易い。可能性のある変更が単なる｜勢い《enthusiasm》ではなく実際の現実世界のニーズに駆り立てられているかどうかを考慮することが重要であると私は考える。これに関して、ソリューションを提案する前に制作中に遭遇した実際の問題からまず始めることを確認したかった。

似た話に、いかなる可能性のあるソリューションでもアーティストのワークフローの効率か品質のいずれかへの明白な利点となることを確認したかった。これは物理ベース的振る舞いを追従するという名目で単に恣意的にアーティストを制限する新しい技術を避けようとすることを望むことを暗黙的に意味する。

最後に、技術がアーティスト駆動のパラメータを必要とするたび、それらがデフォルトで物理的にもっともらしい結果を常に生成すべきであることを決めた。いくつかのケースでは、生来の制限及び/又は近似に対処するためにアーティストが物理法則を破ることができるようにする必要があるかもしれないが、これは明示的に起こるのみにするべきである。

基本のシーンパイプライン（Basic Scene Pipeline）

これはThe Orderで用いたレンダリングパイプラインの本当に基本的で高レベル視点である。左には、空、太陽、ローカルな照明器具《lighting fixtures》のような光源がある。これらの光源はシーンにライティングを放ち、中図においてマテリアルに反射する。この反射したライティングは入射するピクセルあたりの放射輝度をディスプレイ空間の最終出力に変換する露出/カメラシミュレーションステップを通過する。

これらのステップのうち、マテリアルのみが本当に物理ベースの原則に従っている。残りのこれらのステップはそうではなく、任意の単位と標準を用いていた。｜当然と言えば当然だが《somewhat unsurprisingly》、これらの赤のエリアはThe Orderの製作中で最も多くの問題に遭遇した箇所であった。

ライティングの釣り合い取り（Balancing Lighting）

• 以下では物理原則なし
  • 空
  • 太陽
  • ローカルライト
  • 露出
• どう釣り合いを取るか？

我々の問題の基礎にあるテーマは様々な光源の釣り合いのとり方であった。現実的なシーンを望むなら、様々な光源が組み合わせるときに互いにすべての釣り合いを取ることが重要である。しかし、我々の場合、アーティストが光源を追加するときにこのバランスが正しくなることを保証するフールプルーフな方法をまったく持たなかったことが問題であった。

• 様々なライティング条件で’atriums’を作った。
• ゲーム内露出値を標準化した。
• 光源をビジュアル的に釣り合い取りした。
  • AKA: 良くなるまで調整する。
• 我々のプロダクションセッションを参照

バランシングを扱う方法はライトの強度と様々なエミッシブ効果を特定するためのテスト環境を用いることだった。これらの環境のすべては、time of dayと同様に様々な気象条件を反映した太陽と空の要素を組み合わせた、同じアトリウムジオメトリを用いた。アーティストはこれらのアトリウムで標準化された露出値を選択した。これは一般的にニたインゲーム条件での基本の露出値として使われた。光源をバランシングするため、それらは単純にシーンに追加され、それらの強度はシーンの残りとビジュアル的に一貫性のあるようになるまで調整された。この処理は幾分かエラーになりやすく、同様に時間がかかった。

• 良好な最終結果だが、それほど効率的ではない。
• 調整と問題の追跡に大幅な時間を要した。
• もっと簡単にできる？
  • そう思う:)

プロジェクトの後に得た考慮すべき意見《takeaway》は、我々の処理で説得力のあるビジュアルを作ることが間違いなく可能で、確実に取り得る限りで効率的であった。我々のパイプラインに更なる物理ベース原則を適用することは合理化《streamlined》されたワークフローになるのに役立つ可能性があると｜強く思っている《firmly believe》。

The Orderでの空（Skies in The Order）

• 最初の試み: e-On SoftwareのVue
  • 完全にプロシージャルなスカイドーム
  • VFX界隈《industry》で使われる
• アーティストが使うのに苦労した。
  • ｜険しい《steep》学習曲線
  • 遅いレンダリング
  • 一般的にスペシャリストによって使われる
• 将来的に再検討する必要がある。

プロジェクトの初期では、HDRスカイドームをオーサリングするツールとしてE-On SoftwareのVueを評価した。これはとても強力な完全にプロシージャルなソリューションであるが、かなり厳しい学習曲線を持っている。このツールを用いるVFXスタジオでは、これらのシミュレーションで開示されるすべてのパラメータに精通する専属のVueアーティストがいるのが普通である。我々にはそのようなエキスパートはいないので、アーティストたちはよりローテクなソリューションを追求することに決めた。

• 出荷ソリューション: 購入したHDR空画像
  • 追加のディテールをPhotoshopで加えた。
• 任意の強度！
  • 画像間で非常に矛盾している
  • HDRIで問題を引き起こす
• 手でビジュアル的なバランスを取らなければならなかった。
  • 終わりのない調整

最終的なゲームで用いた空のほとんどは様々なサードパーティのライブラリから購入したHDR画像に基づいていた。我々の遠景《vista》アーティストは、杖化のディテールで画像をカスタマイズするのにPhotoshopやMariのような馴染み深いツールで扱うことができたので、それらが仕事をより楽にすることを発見した。このアプローチでの主な問題はHDR画像が強度の観点で｜混沌として《all over the place》いたことであった。これらはピクセル値に対していずれの特定の物理単位も利用しておらず、我々のゲームで用いられる任意の単位に合うまで、全体の強度を手動で調整しなければならなかった。

｜プロシージャル空モデル《Procedual Sky Models》

• CIEの空モデル[ISO 20042004. Spatial distribution of daylight — CIE standard general sky. https://www.iso.org/standard/38608.html.]
  • 相対的な輝度分布のみ得る:(
• [Preetham et al. 1999Preetham, A. J., Shirley, P. and Smits, B. 1999. A practical analytic model for daylight. Proceedings of the 26th annual conference on computer graphics and interactive techniques 91–100. 10.1145/311535.311545. https://papers.cumincad.org/data/works/att/74bb.content.pdf.]
  • 解析的輝度＋色度《chromaticity》
  • ｜直接的な日光の放射輝度《direct solar radiance》を含む
• [Hosek and Wilkie 2012Hosek, L. and Wilkie, A. 2012. An analytic model for full spectral sky-dome radiance. ACM Trans. Graph. 31, 4. 10.1145/2185520.2185591. https://cgg.mff.cuni.cz/projects/SkylightModelling/HosekWilkie_SkylightModel_SIGGRAPH2012_Preprint.pdf.]
  • 改良した解析的モデル
  • スペクトルパストレース《spectral path-traced》データに基づく

我々のR&Dの一部として、様々なプロシージャル空モデルを調査し始めてきている。グラフィクスリサーチで人気のモデルもいくつかある。

CIEの一般的な空は建築モデル用に主として設計され、絶対輝度値を与えない。さらに、色度を一切持たない。これでは、少なからず物理的に正確な強度は持ちたいと考えているので、我々の目的に相当に合わなくなる。

Preethamのモデルは現時点でかなり古いが、多く使われてきている。空の任意の点に対する輝度と色度の計算の解析方法《an analytical means》を提供し、少量のパラメータセットのみを持つ。

Hosek-Wilkieのモデルはかなり新しく、Preethamのモデルで現れるいくつかの欠点を改善するのを目的とする。Preethamのように、似たような少量のパラメータセットで完全なRGBデータを提供する。

Hosek-Wilkieの空モデル（Hosek-Wilkie Sky Model）

• プロトタイピングや検証に良い
  • (サンプルコードを)統合しやすい
  • 物理的に正確な強度
  • 単純なパラメータ
• オーサリングで役立つ？
  • プロシージャル雲
  • 上にディテールを描き込める？
  • 更なる調査が必要

我々は未だにR&Dの初めの段階にいるが、今の所、Hosek-Wilkieモデルは少なくともプロトタイピングや検証では役立つことが証明されている。著者はCコードとしてサンプル実装を提供しており、我々の｜たたき台《testbed》アプリケーションに統合するのは我々にとってかなり自明であった。一度統合すれば、適切なライティング強度を持つバランスされたレンダリングを得ることが即座にできた。実際のゲームシナリオで用いることにもいくつかの成功を収めている。これはゲームシーンにインポートされるEXR画像を生成することで行われる。しかし、出荷する製品に使われる最終的な空をオーサリングする方法として役立つか否かは依然として不明である。これを知るために、clouds mountain rangesのように、空に更なる詳細を追加する方法を調査することに時間をかける必要がある。

The Orderでの太陽光（Sunlight in The Order）

• ランタイムのディレクショナルライト
• 任意の色と強度
  • 空と同じ: バランスが釣り合うように見えるまで調整する
• カスケーディングバランス問題
  • 空は間違っているか？
  • 太陽は間違っているか？
  • 両方間違っている！？

The Orderで太陽の証明をモデル化するために、厳選《hand-picked》した強度値を持つランタイムのディレクショナルライトを活用した。空のように、この光源は任意の単位を用い、太陽光が空と釣り合い取れているように見えることをビジュアル的に検証するのはアーティスト次第だった。製作中に持ち上がった問題をデバッグしようとするときに処理する追加の不明点があるという問題が生じた。例えば、太陽からの特定のスペキュラハイライトが明るすぎるように見えたならば、どの要素が問題を起こしていたのかを知らなかった。太陽が明るすぎたのだろうか？または、恐らく空が暗すぎただけか。または、恐らくマテリアルが間違ったか。ライティング単位に対するリファレンスの現実世界の基準がない場合に、我々はしばしばこれらの種類の問題に悩まされていた。

“二重太陽”問題（“Double sun” problem）

この画像は、IBLスペキュラローブとしてキャプチャしたキューブマップを用いている場合に出くわす可能性がある太陽光によるその他の一般的な問題を示す。空の画像が｜太陽ディスク《solar disc》を持ち、キューブマッププロブにそれをキャプチャする場合、太陽ディスクがランタイムの反射に現れるのが確認できるだろう。しばしば結果のハイライトは正しくない強度により暗すぎてしまったり、スペキュラプロブの貧弱な空間的局所性により影の中に現れてしまったりするだろう。完全なプロシージャルモデルでは、これを扱うことは自明である。スペキュラプロブをキャプチャするときに太陽ディスクを単に省く。しかし、それが空の画像中にあるなら、取り除く方法を見つけなければならない。The Orderでは、しばしば太陽の上を塗りつぶしてみたり、遮蔽ジオメトリでブロックしたりした。

プロシージャル太陽（Procedual Sun）

• Preethamの太陽を現在試している
• オーサリングで素晴らしい
  • 高度から色＋強度を計算する
  • 物理的に正確な既定値と比較して色/サイズ/強度を調整する

これらの問題のいくつかを解決するのを助けるため、シーンの照明にプロシージャル太陽光モデルを用いる実験も始めた。現時点では、我々は太陽の放射輝度を計算するPreethamモデルを用いていたが、Hosek-Wilkieモデルも周辺減光《limbal darkening》のシミュレーションを含む太陽の放射輝度関数を提供する。オーサリングツールとして用いる場合に素晴らしい成功を収めた。必要なことのすべては太陽の現在の高度であり、太陽ディスクの適切な色と高度を計算できる。いくつかの単純な計算で、太陽の大きさを仮定して結果の放射照度を計算することもできる。これは近似したディレクショナルライトの強度を決定するのに使うことができる。

太陽高度: 85° --- f/16（Sun Elevation: 85° - f/16）

この画像のセットは、プロシージャルな太陽と空モデルを用いて、カスタムパストレーサーでレンダリングした。これらは印象的なものではなく、適切な強度とバランスを取ったライティングをレンダリングすることがどれだけ簡単かを示す。太陽の強度における関連する落ち込みを一致するために太陽が落ちるたびに絞りサイズがどれだけ変化するかを確認できる。

太陽高度: 65° --- f/16（Sun Elevation: 65° - f/16）

太陽高度: 45° --- f/16（Sun Elevation: 45° - f/16）

太陽高度: 25° --- f/16（Sun Elevation: 25° - f/16）

太陽高度: 5° --- f/11（Sun Elevation: 5° - f/11）

太陽高度: 0.5° --- f/8（Sun Elevation: 0.5° - f/8）

The Orderでのローカルライト（Local Lights in The Order）

• 実行時でのポイントおよびスポットライト
  • 焼き込みのみのスフィア、ディスク、クアッドエリアライト
• 物理的な単位または強度なし
• 照明器具のデータベースを作る
  • Maya内にライト＋器具メッシュを素早く配置する

The Orderは、単純な実行時ポイント及びスポットライトとして主にモデル化された、いろいろなローカル光源を特徴とする。太陽と空のように、これらは物理的単位を用いず、代わりに任意の強度値を用いた。

我々がすぐ気付いたあることとは、ゲーム中ですべての単一の光源のパラメータを個々に選択することができるようにするつもりはないということであった。これに対処するため、Mayaを用いてシーンにすぐに設置させられる照明器具のデータベースを作成した。これらの器具は、ライトとその周りの器具のジオメトリ表現と実行時光源の両方を含んでいた。

ローカルライトの釣り合い取り（Balancing Local Lights）

• アーティストはアトリウムで強度を特定した
  • “正しく”見えるまで調整した
• バランシング問題へのまた別のレイヤー
  • 検証不可能
  • 屋内/屋外の遷移における問題

物理的単位を用いなかったので、ライティングアーティストは太陽と空を組み合わせたとき、結果のライティングが釣り合って見えることを手動で検証する必要があった。これを行うため、エミッシブ要素とライト寄与の両方をビジュアル的に調査するためのテストアトリウムを再び用いた。基本的に、アーティストは特定の照明条件にライトを配置して、光源が期待通りにうまく動作することを確かめるだけだった。

ここでの主な問題は、一旦ローカルライトが混ざり合うと何事も検証することが基本的に不可能であることであった。バランシング問題とはまた別の話である。これはアンバランスなライティングに対するまた別の可能性のあるソースを追加した。2つのライティング条件の間のエリアの遷移でいくつかの問題もあったが、露出が新しいライティング条件に適切な値に変化したとき、そのバランスは不正確に見えるだろう。

ローカルライト: 将来（Local Lights: The Future）

• 現実世界の単位と強度の範囲
  • デフォルトで太陽と空が一致する
  • リファレンス比較がより簡単になる
• 大量の選択肢[Lagarde and de Rousiers 2014Lagarde, S. and de Rousiers, C. 2014. Moving Frostbite to Physically based rendering. Physically Based Shading in Theory and Practice course. ACM SIGGRAPH. https://seblagarde.wordpress.com/2015/07/14/siggraph-2014-moving-frostbite-to-physically-based-rendering/.]
  • 輝度($cd/m^2$)
  • 光束($lm$)
  • EV100

今後では、光源に物理的な単位を用いることが大きな助けになる可能性があるだろうと考えている。様々な照明器具の実際の値を調べるのは簡単であるので、これらは結果の照度がアーティストの期待するモノであることを確かめるのにインゲームで用いられる可能性があるだろう。現実世界のリファレンスシーンに我々のエンジンを合わせるのに極めて役に立つ可能性があるだろう。

Sebastian Lagardeは去年¹物理的単位の使用に対するいくつかの選択肢を提示しており、我々は依然として我々にとって最良に働くものを決定するためのR&Dを行っている。

露出: The Order（Exposure: The Order）

• トーンマッピング前に単一のスカラが適用される
  • アーティストはlog2空間で指定する
• 単純な幾何平均の自動露出
  • 適応に対する指数関数的なフィードバック
• 大量の手動の介在《intervetion》
  • 最大/最小露出のクランプ
  • 基準値《key value》の調整
  • 領域ごとに指定する

露出は、反射したピクセルごとのライティングの値を取り、ディスプレイ空間へのトーンマッピングで適した範囲にスケールする責任があるので、全体の問題のもうひとつの要素である。The Orderでは、我々の露出はトーンマッピングステージの前に各ピクセルに正しく直接適用された単純なスカラ値である。その結果、現実のカメラパラメータや露出標準への特定のマッピングは存在しなかった。現実世界のカメラで用いられるパラメータの反応をほんの少しでも一致させるために、アーティストがlog2空間で指定できるようにはしていた。

自動露出では、シーン全体の輝度の幾何平均を計算して、その平均輝度を特定のミドルグレーの値にマップするスケール値を選び取る、かなり一般的なアプローチを取った。他の多くのスタジオが見出していた通り、このテクニックは多くの問題を持つ可能性がある。スクリーンの平等《equal》な平均輝度の計算に基づくので、シーンの特定の要素にうまく露出しない露出を選んでしまう可能性がしばしばある。結局の所、許容できる結果を得るために大量に手を加えなければならなかった。これは領域的ボリュームに適用された最大および最小クランプ値の形を成した。これは明らかに自動的だと思われるシステムに我々が望んでいるようなワークフローではない。

自動露出(デフォルト)（Auto exposure (default)）

一般的に自動露出がどのように失敗するかの例を示すため、ここにBlackwall Yardsのレベルから取ったインゲームのキャプチャがある。このスクリーンショットでは、自動露出がデフォルト設定で有効化されている。窓を通して見える｜見通し《vista》が｜消し飛ばされ《is blown out》、すべてのディテールを洗い落としているので、結果の露出はまったく働いていない。これはシステムがレンガにある暗いエリアを補おうとしているために起こる。これは屋内ライティングとより暗いアルベドの両方によりさらに暗くなる。

手動露出(アーティスト指定)（Manual exposure (artist-specified)）

ここに同じスクリーンショットがあるが、自動露出システムを用いる代わりにアーティスト指定の露出値を用いている。結果は、見通しエリアに重要なディテールや輪郭がすべて見えるので、前のスクリーンショットよりさらに釣り合いが取れている。

露出: 将来（Exposure: The Future）

• 物理ベースの露出モデル
  • [Lagarde and de Rousiers 2014Lagarde, S. and de Rousiers, C. 2014. Moving Frostbite to Physically based rendering. Physically Based Shading in Theory and Practice course. ACM SIGGRAPH. https://seblagarde.wordpress.com/2015/07/14/siggraph-2014-moving-frostbite-to-physically-based-rendering/.; Hennessy 2014Hennessy, P. 2014. Implementing a Physically Based Camera: Manual Exposure. Placeholder Art. https://placeholderart.wordpress.com/2014/11/21/implementing-a-physically-based-camera-manual-exposure/.]
  • 現実世界のパラメータ
  • 写真撮影のガイドライン
• より良い計測
  • 重み付けスキームで実験する
  • 視点依存の制約
• 更なるR&D!

今後のプロジェクトでは、より一貫性のある物理ベース露出モデルの採用を計画している。絞りやEVのような実際のカメラパラメータで露出を操る実験を行ってきており、その結果は見込みがある。現実のパラメータを用いると露出を物理ベースのライティング強度とより一貫性のあるものにし、露出の選択に写真撮影の一般的な慣習を用いることができるようになる。

自動露出に対して、計測と重み付けのスキームの代替テクニックを現時点では探している。ゲームへ本質的《inherently》に使える情報をさらに利用することでより良い仕事を行うことができると固く信じている。たとえば、我々のゲームでは、一般にカメラの前にプレイヤーキャラクターがずっといるので、そのモデルが常にうまく露出されるようにするために、プレイヤーのピクセルをより高く重み付けできるはずである。最終的な反射率を用いるのではなく表面の入射する放射照度に基づいて露出を計算するアプローチを取る最近のゲームも存在している。これを行うことはアルベドやスペキュラが結果に作用しないことを意味する。これはまさしく多くのケースでしてほしいことである。

被写界深度: The Order（Depth of Field: The Order）

• Scatter as gather
• 内部的に: フォーカス面
  • 焦点エリアに渡り明示的に制御する
  • 不自然なDOFを作りやすい
• カメラパラメータとしてアーティストに開示される
  • 絞り、フォーカス距離、など
  • ゲーム側でのフォーカス面への変換

これは私が議論してきた他のトピックと幾分無関係であるが、物理ベースパラメータに移行した所のもうひとつの例であるので、議題にあげる。エンジンレベルでは、我々の被写界深度は4つのフォーカス面により操られていた。基本的には、深度値が最終的にその平面に関連するようになった所に基づいたあるCoCサイズにブレンドするためにピクセル深度を用いるだろう。これらのパラメータが直接使われた場合、どのエリアに焦点が合うかに関するアーティストの直接制御を基本的に与えた。これは現実世界のカメラの振る舞いに基礎を持たなくても良かった。結果として、まったく不自然な被写界深度効果を本当に作りやすく、現実的に見える設定を選ぶ方がむしろ難しかった。プロジェクトにおける様々な地点で、私はアーティストやデザイナーに現実のカメラパラメータを用いるアイデアを持ち込んだので、既定値で現実的な結果を得ることができた。しかし、その時点で、絶対制御を得るほうがより望ましいと感じていた。

制作が進むに連れて、ゲームプレイのカメラシステムのいくつかはアーティストに対してわずかのカメラパラメータを採用し、フォーカス面へのアドホックな変換を行った。これらのカメラパラメータは最終的にとてもうまくいったので、制御不足についての初期の懸念が誤りだと証明《disprove》した。

被写界深度: 将来（Depth of Field: The Future）

• 物理的なカメラパラメータを用いるようにエンジンを切り替える
  • アーティストに親しみのあるパラメータ
  • デフォルトで現実的な結果
  • [Sousa 2013Sousa, T. 2013. Graphics Gems from CryENGINE 3. Advances in Real-Time Rendering in Games course. ACM SIGGRAPH. https://advances.realtimerendering.com/s2013/index.html.]を参照
• デフォルトで露出と組み合わせる？
• 選択的な分離の許可
  • 露出/CoCオフセット
  • 完全に分離したパラメータを許可する？
• ground truthと検証する！
  • 単純な薄レンズ近似
  • TODO: より複合的なレンズシステム

我々の過去の実験に基づけば、現実のパラメータがパイプライン全体を通して用いられるべきなのは明らかである。幾分明らかでないことは、現実のカメラの振る舞いを模倣するために、被写界深度パラメータを露出と分離すべきかどうかということである。今の所、極端なケースにおけるいずれかのシステムの振る舞いをバイアスするための選択的な制御を伴うがそれらを分離する方向に気持ちが傾いている。しかし、それが良い決定かどうかを知るならば、現実世界での経験をたくさん要するだろう。

私が言及するであろうもうひとつのことはground truthのパストレーサーに対する被写界深度の近似を検証し始めていることである。これを行うことはバグやground truthと異なって見えるリアルタイム近似を引き起こすその他の問題を｜見分ける《spot》のに役立つ。私がまだこれに対して行う必要があることは、｜デジタル一眼レフ《DLSR》[^DLSR]カメラに見られるものような、より複合的なレンズシステムで改良したground truthシミュレーションである。これを行うことはリアルタイムバージョンに情報を提供するのに役立つかもしれないので、より高品質な結果を得られる。