Moving Frostbite to Physically based rendering

2.1. モデルと仮説の検証（Validating models and hypothesis）

ビデオゲーム業界は長年に渡りフォトリアルな画像を得ようと試みを重ねてきたが、フォトリアリズム《photorealism》 では画像を生成する方法やデータについて言及せずに感覚で(｜定性的に《qualitatively》)判断していた。現実世界の振る舞いや特性をシミュレートしようとする 物理ベースレンダリング ではそれと異なり、数値で(｜定量的に《quantitatively》)判断する。そのため、きちんとしたモデルや正しい仮説を選び出すためにはground-truthとなる良いリファレンスが必要になる。妥当性の判断や正しい選択をする最善の方法は現実世界と比較観察を行うことである。現実世界を観察することで、図1に見られるようなハイライト形状、濡れた表面の振る舞い、ライト強度の違いによる差異といった様々なビジュアル要素を迅速に把握することができる。現実世界をマテリアルのリファレンスとする場合には、異なるライティングの振る舞いをキャプチャするために複数の縮尺で撮影することが重要になる。

しかし、現実のデータを正確に測定しようにも複雑すぎるか時間がかかりすぎることがよくある。MERLなどのデータベースを利用すれば、モデルの性能評価を迅速に行うことができる。本アプローチでは、ライトの強度やフォールオフ、空の明るさ、カメラのエフェクトなどの実データの測定及び評価を試みたが、これらの工程は時間がかかる上、必ずしも簡単にセットアップできるわけではない。

2.2. インエンジン近似の評価（Validating in-engine approximations）

MitsubaのようなモダンなPBRパストレーサーは最新のレンダリング技術を実装しており、近似の妥当性を評価する代替手段として十分なほどに現実感のある画像を生成することができる。Frostbiteでは近似の妥当性を迅速に評価できるようにMitsuba用の簡単なエクスポータを作った。このエクスポータはジオメトリ情報、(テクスチャを含まない)定数のマテリアル情報、すべてのライト強度を出力でき、マテリアルモデル、ライトインテグレーション、ライト強度を簡単に確認できる。さらにこのエクスポータはグローバルイルミネーション、アンビエントオクルージョン、反射といったより複雑な現象の正確性を検証することを可能にする。図2はエクスポート後に自動的に起動するウィジェットを示す。このウィジェットでは完全に制御された露出の下で境目をスワイプしてピクセル値を比較することが可能になっている。もうひとつ重要なこととして、出力する強度を広い値範囲で保持するためにレンダラは線形なHDRフォーマットであるOpenEXRに最終画像を出力する。

2.3. インエンジンリファレンスモードの評価（Validating in-engine reference mode）

前節で説明したエクスポータは便利だが、シーンをレンダリングするのに毎度数秒から数分かかってしまう。そこでイテレーションを早めるため、GPUでの(IBLとエリアライトの)ブルートフォースサンプリングによるライティングインテグレーションを行うゲーム内リファレンスモードを追加した(図3)。このレンダリング時間は決して短いわけではないが、そのイテレーション間隔はエクスポータを使うよりも格段に短くなる。

注: 正しいリファレンスを使うことが重要である。これは明らかなように思えるが、リファレンスが良くない場合、近似もまた良くならない。髪シェーディングモデルを近似するときはリファレンスとして現実世界に一番近いものを使おう。式を近似するときは誤差を計算できるように、Fresnelの式に対するOren-NayarやSchlickの近似式のような、すでにある近似式ではなくオリジナルの式を必ず使おう。唯一完全に信用できるリファレンスは現実世界のみである。

デカールはマテリアル特性を層にしたり、リッチな外観や変化を作れるようにするための動的システムとして理解できる。この文脈の中で、デカールがPBRにおいて”正しい”ことはますます重要になる。ここでの”正しい”とは、デカールのマテリアルパラメータとライティング前の表面を何度重なり合わせても適切に組み合わせることができる能力のことを指す。Frostbiteではこれを目的としてデカールをレンダリングするために主にディファードシェーディングを用いる³が、ハードウェアやパフォーマンスに制約がある中でこれを正しく行うのはほぼ不可能である。我々は様々な物理ベースマテリアルを考慮しつつ正しくデカールをブレンドする良い解答を導き出せないでいるが、完全性のために主要な落とし穴とFrostbiteでの選択をリスト化しておく。

• 正確性: ブレンド処理の正確性は重要である。すなわち、ブレンド処理後の属性の復元《recovery》が正しくなければならない。例えば、$normal * 0.5 + 0.5$のような標準的なエンコーディングを施したNormalやxy要素のみのNormalにおいて、正しく復元することができるのは置き換え(すなわち、線形補間)のみである。ディテールを付加する[Barré-Brisebois and Hill 2012Barré-Brisebois, C. and Hill, S. 2012. Blending in Detail. Self Shadow. https://blog.selfshadow.com/publications/blending-in-detail/.]ような処理では誤った結果を生み出すだろう。プログラマブルブレンディングが活きる場面だが、対応するプラットホームがほとんどない。我々はこの場合では、いくつかの属性で圧縮することを回避し、単純で線形に補間するアルファブレンディングに頼ることを選択をした。
• 相互作用: 正しくブレンドするため、デカールと対象の表面は同じマテリアルモデル(同じパラメータリスト)を使うべきである。プロダクションとパフォーマンスの両方の観点から見ると、MaterialIdごとに分けて作ったデカールをそれぞれ個別のパスで描画する必要があるため、これは管理しきれない。我々はデカールパラメータをゲームが選んだマテリアルの中で共通するパラメータ一式に制限することを選択した。これは基本的にNormal、BaseColor、Smoothnessとなる。MetalMaskやReflectance(または、f0 color)といった他のパラメータはDisney(または、二色)のベースマテリアルを選択した場合にのみ検討する⁴。しかし、これでは十分ではない。デフォルト以外のMaterialIdに影響を与えるデカールはアーティファクトを発生させる。MaterialDataとMaterialIdはブレンド可能なデータではなく、置き換えのみ可能である。選択肢のひとつはアルファチャンネルに個別のブレンド因数を用いて中立的な値に強制することである。もうひとつの選択肢はMaterialIDが0以外のマテリアルに影響を与えるデカールを禁止することである。
• 間接ライティング: デカールが与える影響はライティングを評価する前に処理する必要がある。しかしFrostbiteでは、間接ディフューズをGバッファ生成パスの間に評価するため、ディフューズアルベド以外のマテリアル特性にこれ以上の変更を加えることを妨げてしまう⁵。解決法のひとつは例えばレベルを網羅するプロブボリュームテクスチャ[Valient 2014Valient, M. 2014. Taking Killzone Shadow Fall Image Quality into the Next Generation. Game Developers Conference. https://www.guerrilla-games.com/media/News/Files/GDC2014_Valient_Killzone_Graphics.pdf.]を用いて、すべての間接ディフューズライティングをディファードパスで評価することである。もうひとつの解決法はUnrealEngine4が提案しているようなGバッファ生成前にバッファにデカール属性を格納するデカール用プリパスを使うことである。これはデカールを貼り付けるオブジェクトを2回レンダリングする必要がある。Frostbiteでは、このような解決法により暗黙的に生まれるオーバーヘッドを危惧しアーティファクトを許容することを選択した。
• 発光: FrostbiteのGバッファストレージは制限されているため、節4.8に示すように、エミッシブ情報はパフォーマンス上の理由により時折ラジオシティバッファに組み込まれる。ラジオシティバッファはのちにアルベドを組み合わせる。この場合、アルベドを変更するデカールは発光色を変更する。Frostbiteでは、発光とデカールを扱うことによるアーティファクトを許容した。
• ハイライト形状の保存とスペキュラエイリアシング: いずれかの法線パラメータを変更することはピクセルが占める領域の下にあるNDFを変化させることを暗に示している。これは(ToskvigやLEANマッピングのようなテクニックにより扱われる)形状の保存を偏らせることを意味する。このことは、節5.3に示すように、デカール適用前に処理されていた。解決法はデカール適用後のポストプロセスとして法線フィルタリングパス⁶を行うことである[@Schulz2014MovingNextGeneration]。
• フォワードレンダリングされた表面: ディファードデカールは透明オブジェクトやフォワードレンダリングされたオブジェクトとの互換性を持たない。この場合の基本的な解決法は表面のライティングを含むライティング結果をブレンドするフォワードデカールを頼ることである。フォワードレンダリングされたオブジェクトにおけるデカールのパラメータブレンディグをサポートすることは可能であるだろうが、アート側に大きな制約が必要になる(ブレンドモードの制限、テクスチャ配列でのテクスチャサイズの制限、など)。この問題はライティングの適用において類似点が存在する。ライティングですでに見つかっている解決策を適用すると、タイルベースのデカールに発展するかもしれない。

ライティングパイプラインはすでに界隈で議論されている基盤技術に敬意を払って、ハイダイナミックレンジをサポートし、線形空間で処理し、(MIPMAP、ブレンド、フィルタリング、などにおいて)入出力をガンマ的に正しく行うべきである。Frostbiteではあらゆるゲームエンジンと同じようにハードウェアがサポートするsRGB変換機能に頼ることを選択した。

信憑性の高いシーンはライティングの一貫性と正確性に基づいている。すなわち、すべてのオブジェクトは周囲の環境からライティングを受け取り、正しい強度の光を反射し、シャドウを持つべきである。ゲームエンジンはそれぞれが関連を持たない様々なライティングツールを提供する。アーティファクトがひとつのライティングツールの操作によって、正しい結果を得るために他のライティング要素を再調整したり、信頼性や空間参照を破壊したりしないというのは困難が伴う。Frostbiteでは、すべてが標準で正しい状態にあり、アーティファクトにより好きなように調整することができる、とするメインのガイドライン用意した。これにより正しい結果を得るよりも正しい結果を逸脱することのほうがアーティストにとって難しくなるはずである。ただし、エンジンの制限の回避やアーティスト的な理由のためアーティストによる制御を忘れてはならない。

Frostbiteは、パンクチュアルライト、エリアライト、エミッシブ表面、IBLといった、いくつかのライトタイプをサポートする。“IBL”という言葉には、(空表現に用いる)遠方のライトプロブ、局所化したライトプロブ、スクリーンスペースリフレクション(SSR)が含まれる。一貫性はすべてのライティング要素が結合し、マテリアル特性と正しく相互作用するとき達成される。以下に例を示す。

• 一貫性のあるマテリアルライティング: すべてのBSDFはすべてのライトタイプと正しく相互作用すべきである。これは直接光と同じく間接光も含まれる。
• 一貫性のある間接ディフューズライティング: すべてのライトタイプはラジオシティシステムを考慮しなければならない。太陽や空のライティングは非常に重要な部分であるが、他のライトタイプについてもすべて同様に含まれるべきである。
• 一貫性のある間接スペキュラライティング: SSR、ローカルライトプロブ、遠方のライトプロブはともに正しく組み合わされなければならない。
• 一貫性のあるライト単位: すべてのライトは現実的な比率を達成するため同じ単位で表現されるべきである。例えば、HDRキャプチャしたライトプロブを扱うときは注意しないとすぐに解析的ライトとの比率がおかしくなる。
• 一貫性のあるデカール: デカールは間接光を含むすべてのライトタイプの影響を正しく受けるようにすべきである。

次節ではFrostbiteがサポートするすべてのライトライプとエンジンでライティングの一貫性を保つ方法を説明する。我々はすべてのケースを解決していないため、その落とし穴についても詳しく述べる。デカール由来の問題については節3.3を参照。

アーティストの利便性のため、Frostbiteでは、パンクチュアルライトとエリアライトで同じインターフェースと設定を共有している。これらの設定の一部を図15に示す。我々はライトの強度から色相を分けることを選択する。我々は 強度《intensity》 という言葉をライトが放射するエネルギー量を指すときに使うが、これは厳密な定義ではない。白の色相を差別化するため、人工的な光源は色温度(白熱灯やハロゲンランプ)か相関色温度《correlated color temperature》(CCT) (ほぼその他)のいずれかを持ってラベル付けされる。色温度は比較可能な色相の光を放出する理想的な黒体放射の温度であり、CCTはそのライトの色に人間の色知覚で最も近いとする色温度を指す。色温度とCCTは通常ケルビン(K)で測定される。この文書では簡単化のために、色温度という言葉にはCCTも含む場合がある。front-facingパラメータのこともcolor temperatureと呼ぶ。表4は様々なライトタイプの対応する温度と知覚する色を示す。

スペクトルレンダラ(色の表現にRGBではなくスペクトル値を用いるレンダラ)であれば黒体で定義される放射スペクトルを直に用いることができるだろう⁷。Frostbiteでは、色温度からは色相のみを参照し⁸、ライト強度は独立的にアーティストに制御させることとした。色温度から色相を参照することは比較的複雑な処理であり、 @Charity2001WhatColorBlackbody が解説している。アーティストはRGBでも指定できる。

: 色温度と知覚する色。2700°Kから3000°Kを暖色、3500°Kから4100°Kを中間色《neutral colors》、5000°K以上を寒色と呼ぶ。

“ライト強度”は各ライトタイプごとに示される。色温度と強度の両方を用いることで、アーティストはリファレンス値をメーカーのウェブサイトから拾ってきて、Frostbiteに直接突っ込むことができるようになる(図16参照)。ライト設定には通常の減衰範囲が含まれ、ライトの物理サイズ上で制御する。ライトの物理サイズ(例えば、球の半径、ディスクの半径、チューブの長さ、など)はアーティストにそのライトがエリアライトなのかパンクチュアルライトなのかを定義できるようにする。図17はFrostbiteでサポートするライトを示す。点とスポットはパンクチュアルライトのみで、その他はエリアライトと見なされる。パンクチュアルライトとエリアライトを分けているのはパフォーマンス的な理由であり、Frostbiteはライトタイプ間の円滑な移行をサポートする。

一貫性のあるライティングを得るには、ライト強度の比率を尊重する、すなわち、共通の単位システムを持つ必要がある。ライト強度は図18に示されるように広範囲に及ぶ可能性があり、｜丁重に扱う《conserve》ことが重要である。知覚されるシーンのリッチさはライティングの正しいバランスに起因する。図19は屋内と屋外のライティングをミックスしたものを示す。パイプラインの最後で行う露出処理は広範囲の強度を正規化されたピクセル値に変換する(節5.1参照)。

通常はライティングアーティストが太陽のようなリファレンスを任意に定義することによってライト比率をセットアップする。このリファレンスはある強度(通常は5から10の小さな値)を放出するために設定され、他のすべての光源の値はこれをベースに行われる。しかし、大抵の場合でこれらの設定は現在のシーンの状態(地下、屋内、屋外、など)によりバイアスされるため、他のシーンではそのライトリグは使えなくなってしまう。正しいライティング比率を導入するため、Frostbiteではライトに物理単位を採用した。これは以下のことを可能にする。

• さまざまなライトタイプを一貫性を持って取り扱う。
• いくつかの場面でライトリグを再利用する。
• 物理ベースマテリアルからよりよい応答を得る。ハイコントラストなライティングはマテリアルのリッチさを明らかにするのに役立つ。
• 物理ベースカメラを使うことで、写真家の知識を活用する。節5.1を参照。

ライト単位はライトの測定に関連しており、以下の2つに分けられる。

• 放射測定《Radiometric》: “純粋な”物理量を取扱い、光放射測定《optical radiation measurements》やスペクトルレンダリングの文脈で使われる⁹。
• 測光《Photometric》: 可視スペクトル内の｜放射の減少《radiation falling》のみを考慮する。

放射測定と測光により導かれる量は非常に近い関係にある。測光は本質的に人間の目の感度により重み付けされた放射測定である。これら2つの形式は界隈では広く網羅されてきた。最も一般的に使われる放射測定と測光の量は表5にリスト化されている。放射測定量にはエネルギーの添字$e$を用い、測光量にはビジュアルの添字$v$を用いる。

: 放射測定量と測光量

人間の目の感度はCIEの測光曲線$V(\lambda)$により表される。これは目が特定の光の波長をどれだけ効率的に拾うかを表した釣鐘型の曲線に従う(図20参照)。人間の目の感度は緑として現れる555nmをピークとする。この波長で、感度の関数での値は1単位になり、100%の効率を意味している。測光量は以下の可視光(380nmから780nm)上の積分により放射測定量と関連している。

定数$K_m$は ｜明所視における放射の最大スペクトル発光効率《maximum spectral luminous efficacy of radiation for photoscopic vision》 と呼ばれ、その値は光度測定におけるSI単位であるカンデラの定義に基づいている。その定義は「1カンデラは、与えられた方向で、周波数540THz(波長にすると555nm)の単色放射を放ち、この方向での放射強度が$\frac{1}{683} [\frac{W}{sr}]$となる、その光度である」であり、$K_m = 683$であることを意味する。電球の強度を扱うとき、通常は放射量で説明されるため、上の定義は簡単なフレーズに言い換えることができる。つまり「緑色の555nmの光の1ワットは683ルーメンになる」である。測光曲線からはライトの発光効率を推測することもできる。これは「光源から生み出された光がどれだけ見えているか」と解釈できる。発光効率を計算する式は以下のようになる。

ここで、$\eta$は$[\frac{lm}{W}]$(ルーメン毎ワット)を単位とする。この式は緑(555nm)のライトが683 lm/Wの効率を有することを意味している。これは100%の発光効率と等価である。発光効率はライトタイプごとに異なる可能性がある。つまり、2つの同じワット数を持つライトでも知覚される強度は異なる可能性がある。表6はいくつかの異なるライトの発光効率を示す。

: いくつかのライトの発光効率(%)。

ゲームのような、非スペクトルレンダリングの文脈では、いくつかの簡略化を用いて放射測定単位と測光単位の変換を容易にすることができる。放射量とライトの発光効率の関係から、ワットからルーメンへ変換することが可能になる。

この情報が利用できないときは、ライトは$\eta = 683$で100%の効率になると仮定するのが一般的である。この式は他の量についてしばしば拡張される。

スペクトルレンダラでは、ライトは放射測定単位で表される必要がある。｜スペクトル加重放射輝度《spectral weighted radiance》を用いるような｜後続の《successive》処理は放射測定の領域でのみ正しくなる。このスペクトル放射輝度をピクセル値に変換する後のステージは測光的な重み付け処理(自動露出やトーンマッピング)をしばしば必要とする。

放射測定か測光か(Radiometry or Photometry?) ほとんどのゲームエンジンのような非スペクトルレンダリングでは、発光効率の情報は放射測定単位と測光単位を行き来するために必要とされる。2つの値(ライト強度と発光効率)を提供することはアーティストに対して複雑さを増加させるため、$\eta = 683$とする仮定を用いることが好ましい。このような近似により、各量は線形に変換できるようになるため量の表現に関わらず処理が同一のものになる。しかし、現実世界で観察されるものと視覚的に一致させるためにエンジンでは現実世界のライト強度を使うことが望まれる。100%の発光効率を仮定すると、この世界は過度に明るいライティングを生み出すため、放射測定のリファレンス値を使うことを妨げる。幸いなことに、市販のライトは測光量でその特徴を提供している。また、節4.9.1で述べたように、HDRIはしばしば測光単位(輝度)で提供される。

Frostbiteでは、すべてのライトで測光単位を使っている。これは、レンダリングパイプラインがレンダターゲットに輝度値を格納していることを示している。ライティングの強度は相対的な方法(様々なライトタイプの比率)と絶対的な方法(真のライト単位)で表現することもできる。Frostbiteではメーカーのウェブサイトが提供している値やリファレンス値と一致させることができるため、絶対的な方法で扱ったほうが簡単であることを発見した。

備考: あるデバイスでは放射する光を測定することができる。例えば、入射光量計《incident light meter》(図21)では、表面に届く実際の輝度を測定することができる。輝度は露出計《spot meter》や輝度計《luminance meter》でも測定できる。これは本質的に入射光を一方向に制限する不透明なシールドを持つ入射光量計である。我々は光度を直接的に測定することはできないので、光源からの距離を把握した状態で輝度を計測し、逆二乗の法則$luminousIntensity = luminous \cdot distance^2$から等価な光度を計算する必要がある。

｜EV値《Exposure Value》: EV値はライト強度を説明するために写真の知識とともにアーティストによりしばしば使われる。もともと、EV値は求められる画のためのカメラの設定(絞りの組み合わせ、シャッタースピード、感度)の集まりである。露出計の助けにより、写真家はカメラフィルムを最大限に使用するように適応したカメラ設定を自動的に決定することができる。詳細は節5.1を参照。こんにちのEV値は写真家による｜主な使い方から外れて《abused from their primary usage》、ライトの単位と化している。これは ｜F値《f-stop》 と呼ばれ、底を2とした対数スケールで説明される。このスケールはほぼ知覚的に線形である。EV値はライトの単位として設計されていた訳ではないので、その定義は機器ごとのキャリブレーション定数$K$に依存している。

ここで、$L_{avg}$はシーンの平均輝度を、$S$は｜ISOの算術表記《ISO arithmetic》を、$K$は反射光計のキャリブレーション定数を表す。ISO2720:1974では$K$が10.6から13.4の範囲を推奨する。一般用途としての$K$には2つの値がある。すなわち、12.5(キャノン、ニコン、セコニック)と14(ミノルタ、ケンコ、ペンタックス)である。レンダラでは$K = 12.5$がもっとも一般的に採用されているように見える¹⁰。表7はEV値と輝度の対応関係を示す。エリアライトやエミッシブライトとしてlog2のライト単位を用いることは高い値を取り扱う上で好ましいことである。アーティストがEV値を単位とすることに慣れているので、我々はオプションの単位として$K = 12.5$によるEV値を採用することに決めた。したがって、EV値から輝度への変換は以下のようになる。

表8はFrostbiteがサポートすさまざまなライトタイプで使われるライト単位を示す。ライトタイプの各ライト単位が持つそれぞれのアドバンテージは次節で説明する。

: $\text{EV}_{100}$(ISO100のときのEV値)と$K = 12.5$のときの対応する輝度($\frac{cd}{m^2}$)

: Frostbiteのさまざまなライトタイプに関連するライト単位。

Frostbiteはポイントライトとスポットライトの2つのパンクチュアルライトのみをサポートする。パンクチュアルライトを物理的に正しくするためには、いわゆる”逆二乗則《inverse square law》”に従わなければならない(図22参照)。逆二乗則はポイントライトでのみ有効で、以下には適用しない。

1. 狭い分布を持つフラッドライトやサーチライト。ライトビームは｜平行性が強い《highly collimated》ため。
2. エリアライトやフレネルレンズのような特定のライト。

光量: 逆二乗則を式にすると以下のようになる。

ここで、$I$は光度を、$E$は照度を表す。この式は距離単位がライティング計算を通して均質である(単位が統一されている)ことを必要とする。この値は距離が0に近づくと無限大に近づくが、ライトは常に大きさを持つため現実世界では起こらない。しかし、リアルタイムグラフィクスでは、数値計算の問題を回避するために小さな補正値を加えることが一般的である。パンクチュアルライトは最小の大きさを持つと考え、オブジェクトを絶対にその中に｜入り込ま《penetrate》せないようにすることは｜経験から言えば良い方法《good rule of thumb》である。Frostbiteでは、1単位を1mとしてパンクチュアルライトは1cmの大きさを持つと定義する(表記を簡単にするため、この文書で再掲するときは”max”を省略する)。

Frostbiteでは、アーティストは測光プロファイルにより光量か光度のいずれかを単位としてパンクチュアルのライト強度を制御することができる(節4.5参照)。光量は常にライティング計算において光度に変換される。光量はライトの立体角上で積分することで光度から計算できる。

• ポイントライト:

• スポットライト(開口角《opening angle》$0 < \theta_{\text{outer}} < \pi$を持つ):

式16はコーンの正確な立体角である。この式の帰結として、コーンの角度が小さくなるとライティングがそこに集束するためにより明るく見えるということを示している(図23参照)。このような関連性《coupling》があることで、アーティストがスポットライトを操作するのが難しくなったり、最適化を行うさいに問題が生じたりする。我々は集束光の関連性を取り除き、反射鏡《spot reflector》が光を吸収するかのように振る舞うシンプルなマスキングとすることを選択した。これらの検討と合わせてディスク型のエリアライトへの移行をスムーズに行うため、Frostbiteではスポットライトの光量を以下のように定義した。

パンクチュアルライトにおける光量から光度への変換は表9にまとめられている。万全を期すために、錐台ライトの変換も付け加えている。錐台ライトと線ライトはFrostbiteではエリアライトとして扱われており、数式を使わない。これらはごくまれに使われる程度であり、ポイントライトやスポットライトの効率的なライティングパスを共有することができない。

ライト計算: これらの光源のライティング計算は以下により求められる。

• ポイントライト:

: パンクチュアルライトと錐台ライトにおける光量(lm)から光度(cd)への変換。$\theta_{\text{outer}}$、$\theta_a$、$\theta_b$はそれぞれの開口角を表す。

ライト方向に向いている表面の法線を考えると、その照度は逆二乗則に従って以下のようになる。

• スポットライト:

ライト方向に向いている表面の法線を考えると、その照度は逆二乗則(とFrostbiteの慣例)に従って以下のようになる。

測定: 両者の関係を評価するため、入射光計による一連の測定を行った。そのセットアップは図24で説明されている。光量単位の扱いと電球を表すことができるという点光源についての仮定を評価した結果は表10に示す。ルーメンが2倍になると照度も2倍になることに注目して欲しい。Nearestは得られた中で一番高い値を取り出してきたものであり、電球の大きさに依存する。スポットライトの測定は、セットアップがより複雑になり、我々の定義に合わないため、行わなかった。Frostbiteでのポイントライトはすべての強度キャリブレーションのためのリファレンスライトである。これらは現実世界の測定と合致しており、故に信用に値する。

: 入射光計による現実世界での電球の測定とインゲーム値の比較。

減衰《Attenuation》: 逆二乗則が抱える問題のひとつは絶対にゼロに到達しないことである。パフォーマンス的な理由から、レンダラはライトカリングのアルゴリズムをサポートするために有限のライト範囲を実装しなければならない。ある限界点で、照度は滑らかにゼロに達するべきである。これを解決するアプローチのひとつはほとんどの関数に影響を与えないような方法[Karis 2013Karis, B. 2013. Real Shading in Unreal Engine 4. Physically Based Shading in Theory and Practice course. ACM SIGGRAPH. https://blog.selfshadow.com/publications/s2013-shading-course/.]でフォールオフに窓関数を用いることである。これのために、我々は距離基準《distance criteria》に基づくゼロへの基本的な線形補間を用いる。

そして、関数を変化しないようにするため、距離基準を微調整すると以下のようになる。

このシンプルなアプローチはうまくいくが、不自然に見える強めのカットオフを生じる。次のアプローチはしきい値により関数をバイアスして0から1の初期範囲にリマップする[@Madams2011ImprovedLightAttenuation]。

結果は良いが、このアプローチは0地点における勾配が0ではないことでビジュアルに不連続性が生まれてしまうために苦労する。より良いアプローチは窓関数を用いて$lightRadius$地点における勾配が0になるよう保証することである。図25を参照のこと。

$n$は遷移の滑らかさを調整することができる。我々はFrostbiteにおいて Karis [2013Karis, B. 2013. Real Shading in Unreal Engine 4. Physically Based Shading in Theory and Practice course. ACM SIGGRAPH. https://blog.selfshadow.com/publications/s2013-shading-course/.] によって示されたものと同じような$n = 4$とした場合のWindow1を採用した。このスムージング関数はすべてのパンクチュアルライトとエリアライトで採用されている。しかし、lerpの基準《criteria》は放射状である($\frac{x^2}{d^2}$)ので、チューブや矩形ライトのような球でない形ではうまくいかない。我々はパフォーマンス的な理由によりこのトレードオフを許容する。アーティストは正確さが必要とされる場面ではライト半径を拡大することができる。

リスト4はこの節で述べた様々な主題の結果のコードを示す。

float smoothDistanceAtt(float squaredDistance, float invSqrAttRadius) {
    float factor = squaredDistance * invSqrAttRadius;
    float smoothFactor = saturate(1.0f - factor * factor);
    return smoothFactor * smoothFactor;
}

float getDistanceAtt(float3 unnormalizedLightVector, float invSqrAttRadius) {
    float sqrDist = dot(unnormalizedLightVector, unnormalizedLightVector);
    float attenuation = 1.0 / max(sqrtDist, 0.01 * 0.01);
    attenuation *= smoothDistanceAtt(sqrDist, invSqrAttRadius);
    return attenuation;
}

float getAngleAtt(float3 normalizedLightVector, float3 lightDir, float lightAngleScale, float lightAngleOffset) {
    // CPUで以下を計算しておく。
    // float lightAngleScale = 1.0f / max(0.001f, (cosInner - cosOuter));
    // float lightAngleOffset = -cosOuter * angleScale;

    float cd = dot(lightDir, normalizedLightVector);
    float attenuation = saturate(cd * lightAngleScale + lightAngleOffset);

    // 遷移を滑らかにする。
    attenuation *= attenuation;

    return attenuation;
}

// パンクチュアルライトを処理する。
float3 unnormalizedLightVector = lightPos - worldPos;
float3 L = normalize《unnormalizedLightVector》;
float att = 1;
att *= getDistanceAtt(unnormalizedLightVector, lightInvSqrAttRadius);
att *= getAngleAtt(L, lightForward, lightAngleScale, lightAngleOffset);

// lightColorは出射する輝度×ユーザのライト色である。
// つまり、ポイントライトと光量単位だと: lightColor = color * phi / (4 * PI)
float3 luminance o  BSDF(...) * saturate(dot(N, L)) * lightColor * att;

: 減衰。

測光ライトはそれらの強度分布を説明するために測光プロファイルを使う。これらの分布は測光ファイルに格納されており、ファイルフォーマットとしてIESとEULUMDAT2つが一般的に存在する。これらはシンプルなASCIIファイルである。

• IES: IESはIlluminating Engineering Societyの頭文字で、ウェブ上で測光データを配信するために作られた。北米では最も人気があり、ヨーロッパでも広く使われている。
• EULUMDAT: EULUMDATはヨーロッパの標準規格であり、ヨーロッパではデファクトスタンダードとなっているが、一般に認められた標準化団体が存在しない。

多くの照明メーカーは自身のウェブサイトで自由に利用可能な測光ファイルを提供している。例えば、Lithonia LightingはIESとEULUMDATのファイルの広大なライブラリを持っている。

両フォーマットは様々な角度に対する光度を格納する。これらは研究機関でライトセンサを使って測定され、光源の周りを球状に広がり、球の中心を指し示す。このキャプチャ手法により、すべてのランプは点光源として考えられる(図26を参照)。物理的に正確な結果を得るため、IES/EULUMDATファイルは小さな球の上に適用されるにとどめるべきである。IES/EULUMDATファイルを小さい球でないジオメトリに適用すると、手法やフォーマット定義に固有の不正確さが生じる可能性がある。ライト分布を説明するために使われる球面座標系は”｜フォトメトリック・ウェブ《the photometric web》”と言われる。これらは3つの異なるタイプのフォトメトリック・ウェブがあり、タイプA、B、Cと呼ばれる。

• タイプA: 車のヘッドライトや信号灯用。
• タイプB: 調整可能な屋外エリアやスポーツの照明器具用。
• タイプC: 建築や道の明かり用。

実践では、タイプAとBはまれに用いられ、タイプCはコンピュータグラフィクスで最も一般的に用いられる。

IES フォーマットはその構造が理解しにくい形でカンデラとして光度値を格納する。これはこのフォーマットがサポートする絶対的光度と相対的強度の両方に適用される。絶対的光度はLED器具で必要になり、相対的光度はコンピュータグラフィクスや昔ながらのライト(蛍光灯、白熱灯、ハロゲン、など)において最も一般的なケースである。このフォーマットにはIES-LM-63-86からIES-LM-63-2002までの5つの異なる仕様がある。すべてのフォーマットをサポートするIESパーサを書くことは簡単な仕事ではなく、コンピュータグラフィクスで使われるいくつかのファイルは不完全でありフォーマットに反しているように見える。その仕様は自由にアクセスできるわけではなく、いくつか不明な範囲が存在する。具体的には、水平な回転の方向をに伴う測光タイプAとBに関するIESNAの文献にいくつかの混乱がある。IESに関するこんにちの最良の資料はHelios32というウェブサイト[@Ashdown1999Helios32Resources]と彼の関連する文書であるように思われる。IESパーサを書くための良い資料はHelios32を管理している @Ashdown1998ParsingIESNALM63 によって書かれている。IESファイルを可視化するために、最も人気のあるビュアーはIESviewerである[@Legotin2001IESviewer]。一方でEULUMDATフォーマットはライトによって放出される総キロルーメンあたりのカンデラにより光度値を格納するという良く構造化されたフォーマットである。

この特質は重要であり、いくつかの明確化を行うのに必要である。IESファイルは相対的光度と絶対的光度の両方に対してカンデラ値を格納する。絶対的光度と相対的光度の両方に対してEULUMDATファイルからカンデラ値を取り出すには、以下の変換を施す必要がある。

EULUMDATフォーマットはより複雑な器具《fixture》や色温度のような追加情報を格納することができる。EULUMDATフォーマットをメンテナンスする団体がおらず、その仕様は1990年からほとんど変わらないままである。公式なファイルフォーマットの出版物がなく、唯一の仕様のひとつはHelios32のウェブサイト[@Ashdown1999Helios32Resources]より取得可能である。ビジュアライザや文書を含む良いツールセットがEulumdat Toolsのウェブサイト[@FOLDSystems2003EulumdatTools]にて取得可能である。

Frostbiteでは、開発にかけられる時間が少なかったため、その欠点に関わらずIESフォーマットのみをサポートすることにした。コンピュータグラフィクスで普及していると思われるのも理由のひとつである。IESファイルから生成した測光プロファイルは直接ポイントライトやスポットライトに適用することができる。IESプロファイルはライト強度を記述するのに使うこともでき、乗数《multiplier》で調整することができる。これは光度でライトを制御する唯一の方法である。もうひとつの選択肢はIESプロファイルをプロファイルの最大光度で正規化されたマスクとして使うことである。光度のポイントライトの数式で両方のケースを扱うため、我々は最大光度でプロファイルを正規化し、以下の式でポイントライトの評価を行う。

$I$はプロファイルの最大光度かマスク用のユーザ定義ライト強度のいずれかを表す。$\text{getIESProfileAttenuation}$関数は正規化されたプロファイル値を返す。スポットライトでは、角度による減衰がこの式の外にかけられる。よりタイトな形はより進んだ最適化を可能にし、単純なプロファイルのために便利である(図27参照)。

新しいライトプロファイルを作るとき、球面測光関数は球面パラメータ化$(\theta, \cos(\phi))$により2Dテクスチャを埋めるため再構築されサンプルされる¹¹。我々はマスク的な使い方とそうでない使い方の両方を扱うために最大光度の逆数によりスケールされた正規化済みの値を格納する。シェーダでは、2Dテクスチャが評価され、減衰として適用される(リスト5)。

float getIESProfileAttenuation(float3 L, ShadowLightInfo light) {
    // ライト空間へのサンプル方向
    float3 iesSampleDirection = mul(light.worldToLight, -L);

    // デカルト座標から球面座標へ
    // テクスチャはcos(phi)にエンコードされ、[-1, 1]から[0, 1]へスケールされる。
    float phiCoord = (iesSampleDirection.z * 0.5f) + 0.5f;
    float theta = atan2(iesSampleDirection.y, iesSampleDirection.x);
    float thetaCoord = theta * FB_INV_TWO_PI;
    float3 texCoord = float3(thetaCoord, phiCoord, light.lightIndex);
    float iesProfileScale = iesTexture.SampleLevel(sampler, texCoord, 0).r;

    return iesProfileScale;
}

att *= getAngleAtt(L, lightForward, lightAngleScale, lightAngleOffset);
att *= getIESProfileAttenuation(L, light);
// lightColorは選択に依存する。
// マスクでない: lightColor = color * MaxCandelas
// マスク(光量によるポイントライト用): lightColor = color * phi / (4 * PI);
float3 luminance = BSDF(...) * saturate(dot(N, L)) * lightColor * att;

: IESプロファイルのサンプル。

なぜIESプロファイルを使うのか？ IESプロファイルはゲームよりも建築の設計でより役に立つ。しかし、マスクとしてライトプロファイルを使えるようになると、面白い使い方が生まれてくる。例えば、IESプロファイルはあるツールでアーティストが作成することができ、複雑なシャドウをシミュレートするのに使うことができる(図28)。これはcookieテクスチャ¹²に似ているが、異なるパラメータ化によるものである。

太陽は、特に屋外環境では重要な光源であり、非常に高い値(表11参照)を持つ一方で、非常に小さな立体角をカバーする。この構成では法線の向きと変化に過敏に反応する。マテリアルのディフューズ部分のためのパンクチュアルライトとしてこのような光源を検討することは許容されるべき近似であるが、スペキュラ部分にこれをすると鏡のような表面で問題を引き起こす。Frostbiteでは、この問題を部分的に｜緩和する《alleviate》ために、太陽を常に外側の半球に垂直なディスク型エリアライトとして扱う。

アーティストは太陽の方向に垂直な表面に対して太陽の照度(ルクス)を指定する。これは(表11のような)光計を用いなければならない現実世界とは反対に直接的に値を確認できるために便利である。その計算は以下のように単純化される。

ここで、$E_{\perp}$はアーティストにより与えられる照度値である。リスト6は太陽を評価するための関数を示す。ディフューズ部分は太陽がパンクチュアルであるかのように照らされ、スペキュラ部分は太陽の形を計算に入れている。

: 光計で測定された太陽と空の照度値(ルクス)の例。$\perp$なしは水平方向での測定を、$\perp$ありは太陽方向での測定を表す。測定場所はストックホルムで、6月に行った。

float3 D = sunDirection;
float r = sin(sunAngularRadius);  // ディスク半径
float d = cos(sunAngularRadius);  // ディスクまでの距離

// ディスクへの最も近い点(半径が小さいため、良い近似となる)
float DdotR = dot(D, R);
float3 S = R - DdotR * D;
float3 L = DdotR < d ? normalize(d * D + normalize(S) * r) : R;

// ディフューズとスペキュラの評価。
float illuminance = sunIlluminanceInLux * saturate(dot(N, D));

// D: ディフューズ方向
// S: スペキュラ法苦
luminance = BSDF(V, D, L, data) * illuminance;

: ディスク型エリアライトとしての太陽の評価。

備考: 現時点では正しいエネルギー保存因数を見つけられていないため、このディスク型エリアライトはエネルギー保存則を満たしていない。空からのライティングは遠方のライトプロブとして扱う(節4.9参照)。

エリアライトは光源が物理的な形状を持つ現実世界のライティングと一致させるために物理ベースレンダリングにおいて重要である。この形状はアーティストが表面のマテリアル特性、特にラフネスを簡単に把握することができるようにする。以前にパンクチュアルライトを使っていた頃は、アーティストは無限小のスペキュラハイライトを表面のラフネスを調整することで隠す傾向があり、故にライティングとマテリアルが結合していた。パンクチュアルな発生源は光源の良い近似となり得るが、文脈(距離、関与媒質、など)に依存する。後に見ることになるだろうが、エリアライトはIBLと概念的に近いため相互作用を容易に行うことができる。より重要なことは、エリアライトはさらに柔らかいライティングを生み出し、スペキュラエイリアシングを低減する。

Frostbiteでは、球、ディスク、チューブ、矩形といった様々なエリアライト形状をサポートする。エリアライトによって照らされているある点の出射する輝度は以下で与えられる。

関数$V$は陰影が付けられる点からエリアライトが到達可能であれば$1$、そうでなければ$0$となる。関数$V$はエリアライトの形状とそのシャドウの両方を勘定に入れることができる。この節ではエリアシャドウを考慮しない。これは節4.10.4で述べる。故に、$V$はライト形状の可視性のみ表現し、$\Omega_{\text{light}}$はエリアライトに対する立体角を表す。この立体角上の積分は面積上の積分として書き直すことができる[@Pharr2010PhysicallyBasedRendering] (図30を参照)。

この式は常に解析解を持つわけではないが、Monte Carloと重点サンプリングにより数値積分できる。我々は節2で述べたようにすべてのエリアライトを重点サンプリングするインエンジンリファレンスを実装した。このコードは付録Aで提供される。当然だが、この種の計算はプロダクション用としては高価すぎるので、我々はこれらの近似を開発した。インエンジンリファレンスモードは近似の正確性を確かめるための貴重なツールとなった。

ディフューズライティングとスペキュラライティングの積分はエリアライトのタイプについて別々に記述される。

備考: この文書で表されるエリアライトは執筆時点ではプロダクションで使われていない。これらはシネマティクスのような30FPSのゲームを対象とすることを目標としており、非最適化バージョンを提供するのみとなっている。

float3 Lunormalized = lightPos - worldPos;
float3 L = normalize(Lunormalized);
float sqrDist = dot(Lunormalized, Lunormalized);

#if WITHOUT_CORRECT_HORIZON  // 地平線より上での解析解

// "正面の球へのパッチ"の式(Quilezのバージョン)
float sqrLightRadius = light.radius * light.radius;
// オブジェクトをライトに入り込ませない(max)
// "FB_PI *"はフォームファクタの式に含まれる(1/FB_PI)を打ち消す
float illuminance = FB_PI * (sqrLightRadius / (max(sqrLightRadius, sqrDist))) * saturate(dot(worldNormal, L));

#else  // 地平線ありの解析解

// "傾いた球へのパッチ"の式
float Beta = acos(dot(worldNormal, L));
float H = sqrt(sqrDist);
float h = H / radius;
float x = sqrt(h * h - 1);
float y = -x * (1 / tan(Beta));

float illuminance = 0;
if (h * cos(Beta) > 1) {
    illuminance = cos(Beta) / (h * h);
} else {
    illuminance = (1 / (FB_PI * h * h)) * (cos(Beta) * acos(y) - x * sin(Beta) * sqrt(1 - y * y)) + (1 / FB_PI) * atan(sin(Beta) + sqrt(1 - y * y) / x);
}

illuminance *= FB_PI;

#endif

float cot(float x) { return cos(x) / sin(x); }
float acot(float x) { return atan(1 / x); }

#if WITHOUT_CORRECT_HORIZON  // 水平線より上の解析解

// フォームファクタの式は打ち消される必要がある(1 / FB_PI)を持つ。
// そのためilluminanceは"FB_PI *"を持つ。
float illuminance = FB_PI * saturate(dot(planeNormal, -L)) * saturate(dot(worldNormal, L)) / (sqrDist / (radius * radius) + 1);

#else  // 水平線ありの解析解

// ほぼ厳密解
float h = length(lightPos - worldPos);
float r = lightRadius;
float theta = acos(dot(worldNormal, L));
float H = h / r;
float H2 = H * H;
float X = pow((1 - H2 * cot(theta) * cot(theta)), 0.5);

float illuminance = 0;
if (theta < acot(1 / H)) {
    illuminance = (1 / (1 + H2)) * cos(theta);
} else {
    illuminance = -H * X * sin(theta) / (FB_PI * (1 + H2)) + (1 / FB_PI) * atan(X * sin(theta) / H) + cos(theta) * (FB_PI - acos(H * cot(theta))) / (FB_PI * (1 + H2));
}

// saturate(dot(planeNormal, -L))をかけたほうがground truthと良く一致する。式の第一の部分と良くマッチするが、第2の部分とは不一致が起こる。まだ改良途中だが、十分良好な結果を示している。
illuminance *= FB_PI * saturate(dot(planeNormal, -L));
#endif

// CPUで
float3 virtualPoint = lightPos + lightForward * (discRadius / tan(halfOuterAngle));

// GPUで
// ライトの位置を外側の角度に基づいた量だけライトの反対方向にシフトした仮想的な位置で減衰する
illuminance *= getAngleAtt(normalize(virtualPos - worldPos), lightForward, lightAngleScale, lightAngleOffset);

// right diskは常に照らす表面の方を向く円盤である。
// 球とright diskの立体角は2 * PI * (1 - cos(なす角))である。
// なす角sigmaは、球だとarcsin(r / d)であり、right diskだとatan(r / d)である。
// sinSigmaSqr = sin(なす角)^2は、球だと(r^2 / d^2)であり、円盤だと(r^2 / (r^2 + d^2))である。
// cosThetaはクランプされていない。
float illuminanceSphereOrDisk(float cosTheta, float sinSigmaSqr) {
    float sinTheta = sqrt(1.0f - cosTheta * cosTheta);

    float illuminance = 0.0f;
    // メモ: 以下のテストはオリジナルの式と等価である。
    // 曲線には以下の3つのフェーズが存在する。
    //     cosTheta > sqrt(sinSigmaSqr)のとき、
    //     cosTheta > -sqrt(sinSigmaSqr)のとき、
    //     0のとき。
    // 上２つはcosTheta * cosTheta > sinSigmaSqrとすることで１つにでき、
    // 代わりにsaturate(cosTheta)を用いる。
    if (cosTheta * cosTheta > sinSigmaSqr) {
        illuminance = FB_PI * sinSigmaSqr * saturate(cosTheta);
    } else {
        float x = sqrt(1.0f / sinSigmaSqr - 1.0f);  // 円盤ではx = d / rに単純化する
        float y = -x * (cosTheta / sinTheta);
        float sinThetaSqrtY = sinTheta * sqrt(1.0f - y * y);
        illuminance = (cosTheta * acos《y》 - x * sinThetaSqrtY) * sinSigmaSqr + atan(sinThetaSqrtY / x);
    }
    return max(illuminance, 0.0f);
}

// 球の評価
float cosTheta = clamp(dot(worldNormal, L), -0.999, 0.999);  // エッジケースを避けるためにクランプする
// オブジェクトが表面を貫通するのを防ぐ必要がある
// なので、0で割るのを避けなければならず、0.9999fとする
float sqrLightRadius = lightRadius * lightRadius;
float sinSigmaSqr = min(sqrLightRadius / sqrDist, 0.9999f);
float illuminance = illuminanceSphereOrDisk(cosTheta, sinSigmaSqr);

// 円盤の評価
float cosTheta = dot(worldNormal, L);
float sqrLightRadius = lightRadius * lightRadius;
// ライトを表面に貫通させない
float sinSigmaSqr = sqrLightRadius / (sqrLightRadius + max(sqrLightRadius, sqrDist));
// ground truthとのさらなる一致のために、saturate(dot(planeNormal, -L))をかける
float illuminance = illuminanceSphereOrDisk(cosTheta, sinSigmaSqr) * saturate(dot(planeNormal, -L));

float rightPyramidSolidAngle(float dist, float halfWidth, float halfHeight) {
    float a = halfWidth;
    float b = halfHeight;
    float h = dist;

    return 4 * asin(a * b / sqrt((a * a + h * h) * (b * b + h * h)));
}

float rectangleSolidAngle(float3 worldPos, float3 p0, float3 p1, float3 p2, floatp3) {
    float3 v0 = p0 - worldPos;
    float3 v1 = p1 - worldPos;
    float3 v2 = p2 - worldPos;
    float3 v3 = p3 - worldPos;

    float3 n0 = normalize(cross(v0, v1));
    float3 n1 = normalize(cross(v1, v2));
    float3 n2 = normalize(cross(v2, v3));
    float3 n3 = normalize(cross(v3, v0));

    float3 g0 = acos(dot(-n0, n1));
    float3 g1 = acos(dot(-n1, n2));
    float3 g2 = acos(dot(-n2, n3));
    float3 g3 = acos(dot(-n3, n0));

    return g0 + g1 + g2 + g3 - 2 * FB_PI;
}

if (dot(worldPos - lightPos, lightPlaneNormal) > 0) {
    float halfWidth = lightWidth * 0.5;
    float halfHeight = lightHeight * 0.5;
    float3 p0 = lightPos + lightLeft * -halfWidth + lightUp *  halfHeight;
    float3 p1 = lightPos + lightLeft * -halfWidth + lightUp * -halfHeight;
    float3 p2 = lightPos + lightLeft *  halfWidth + lightUp * -halfHeight;
    float3 p3 = lightPos + lightLeft *  halfWidth + lightUp *  halfHeight;
    float solidAngle = rectangleSolidAngle(worldPos, p0, p1, p2, p3);

    float illuminance = solidAngle * 0.2 * (
        saturate(dot(normalize(p0 - worldPos), worldNormal)) +
        saturate(dot(normalize(p1 - worldPos), worldNormal)) +
        saturate(dot(normalize(p2 - worldPos), worldNormal)) +
        saturate(dot(normalize(p3 - worldPos), worldNormal)) +
        saturate(dot(normalize(lightPos - worldPos), worldNormal))
    );
}

// 線の最も近い点を返す(制限なし)
float3 closestPointOnLine(float3 a, float3 b, float3 c)　{
    float3 ab = b - a;
    float t = dot(c - a, ab) / dot(ab, ab);
    return a + t * ab;
}

// 線分の最も近い点を返す(制限あり)
float3 closestPointOnSegment(float3 a, float3 b, float3 c) {
    float3 ab = b - a;
    float t = dot(c - a, ab) / dot(ab, ab);
    return a + saturate(t) * ab;
}

// 球は線分の最近傍点に配置される。
// 矩形平面は以下の正規直交枠《orthonormal frame》で定義される。
float3 forward = normalize(closestPointOnLine(P0 , P1, worldPos) - worldPos);
float3 left = lightLeft;
float3 up = cross(lightLeft , forward);

float3 p0 = lightPos - left * (0.5 * lightWidth) + lightRadius * up;
float3 p1 = lightPos - left * (0.5 * lightWidth) - lightRadius * up;
float3 p2 = lightPos + left * (0.5 * lightWidth) - lightRadius * up;
float3 p3 = lightPos + left * (0.5 * lightWidth) + lightRadius * up;

float solidAngle = rectangleSolidAngle(worldPos, p0, p1, p2, p3);

float illuminance = solidAngle * 0.2 * (
    saturate(dot(normalize(p0 - worldPos), worldNormal)) +
    saturate(dot(normalize(p1 - worldPos), worldNormal)) +
    saturate(dot(normalize(p2 - worldPos), worldNormal)) +
    saturate(dot(normalize(p3 - worldPos), worldNormal)) +
    saturate(dot(normalize(lightPos  - worldPos), worldNormal)));

// そして、球の寄与を加える。
float3 spherePosition = closestPointOnSegment(P0, P1, worldPos);
float3 sphereUnormL = spherePosition - worldPos;
float3 sphereL = normalize(sphereUnormL);
float sqrSphereDistance = dot(sphereUnormL, sphereUnormL);

float illuminanceSphere = FB_PI * saturate(dot(sphereL, data.worldNormal)) * ((lightRadius * lightRadius) / sqrSphereDistance);

illuminance += illuminanceSphere;