拙訳「Introduction to Real-Time Shading with Many Lights」

問題#

単なるバッチサイズの話から掘り下げてみると、ジオメトリのチャンクサイズに基づいてライトを割り当てなければならないという基本的な問題になる。

いくつかの大きなオブジェクトと大量の小さなライトがある場合、ジオメトリの一部にしか影響を与えないライトが多く、無駄なシェーディング計算しなければならなくなる。

一方で、大量の小さなオブジェクトといくつかの小さなライトがある場合、個々のオブジェクトでライトの影響範囲を求める、似たような処理を繰り返さなければならなくなる。

これらの状況はシーン中に混在するため、パフォーマンスのバランスを良好に保つのは困難に近い。

一般に、三角形の大きさやライトの密度変化が関わってくると、この話はうまく解決できなくなってしまう。

まとめ#

シェーディングパス#

各ライトの｜境界領域《bounding volumes》をジオメトリとしてスクリーンに描画することでラスタライザがライトの割り当てを行う。

フラグメントシェーダはGバッファの内容を読み取ってシェーディングを行う。

計算した色はフレームバッファにブレンドする。

これなら、各ライトを独立して処理できる。

Stencil Buffer Optimization#

[Arva and Aila 2003Arva, J. and Aila, T. 2003. Optimized shadow mapping using the stencil buffer. Journal of Graphics Tools 8, 3, 23–32. 10.1080/10867651.2003.10487587.]

ステンシルシャドウと要領は同じ。

• ライトボリュームの背面を描画して、深度テストに失敗した所のステンシルをマスクする
• ライトボリュームの前面を描画して、ステンシルテストに合格した所のシェーディングを計算する

これにより、ライトボリュームの外にあるピクセルを除外できる。

シェーディングが必要なところだけを的確に狙い撃つため、効率が改善する。

モダンなハードウェアで大量のライトを扱う状況に対して効率的に実装できるかは不明。

その他のバリエーション(variants)#

• Deferred Lighting
  • Gバッファには法線とshininessのみを格納する
  • Gバッファをもとにライトの影響を計算して、拡散色と鏡面色をバッファに格納する
  • 最後に、もう一度ジオメトリを描画して、マテリアルにライトの影響と掛け合わせる
• Light PrePass
  • 基本はDeferred Lightingと同じだが、スペキュラが単色
  • deferredとパフォーマンスは似たりよったり
  • それよかシェーディングモデルの制限が増えてたりする

まとめ#

帯域の問題#

伝統的なdeferred系では同じピクセルにライトがオーバーラップすればオーバードローが起こる。

オーバードローが起これば、それだけGバッファの同じ場所からの読み出しが発生することになる。

模式的には以下の様になる。

for each light
    for each coverred pixel
        read G-Buffer
        compute Shading
        read + write frame bufferCopy

ここで問題になるのは、Gバッファの読み書きが最深のピクセル毎ループで行われること。

なので、ループの外に出してやればいいのでは、と考える。

for each pixel
    read G-Buffer
    for each affecting light
        compute Shading
    write frame bufferCopy

こうすれば、計算志向の構成になる。

読み書きも1回になって、帯域の問題も解決できそうに見える。

この変形では、ピクセルごとに、関連するライトのすべてに対してシーケンシャルにアクセスする必要が出てくる。

グローバルなライトのリストを使うのは非効率すぎる。

ピクセルごとにライトｎリストを用意する方法は遅いし容量を食う。

モダンなシェーディングの解き方#

モダンな｜解法《solution》は、似たようなピクセルのグループでリストを作ること。

for each pixel
    read G-Buffer
    for each possibly affecting light
        if affecting
            compute Shading
    write frame bufferCopy

サンプル間のコヒーレンシが高まる。

コヒーレントなアクセスを行う。

必要なストレージが小さくなる。

リストは保守的。タイル内のいずれかのサンプルに影響を与えるかもしれないライトをすべて格納する。

計算パフォーマンスをいくらか帯域に逃がすことは、モダンなGPUでは良い戦略である。

しかし、同時に、ブルートフォースと比べて最適解に著しく近づく。

モダンなDeferred Shading#

1. Gバッファにシーンをレンダリングする
2. ライトを割り当てる
3. フルスクリーンパス（CUDAやコンピュートシェーダ）
   • 各ピクセルで、Gバッファから読み出したデータとライトリストのライトすべてを使ってシェーディング計算する

モダンなForward Rendering#

1. オプショナル: Pre-Zパス、または、ジオメトリパス
2. ライト割り当て
3. ジオメトリパス
   • ライトリストのライトすべてを用いて、ほぼ通常通りのシェーディング計算を行う

まとめ#

Tiled Shading Gridの生成#

（このデモでは）スクリーンを32x32ピクセルのタイルに区切る。

各タイルは、タイル内のピクセルのいずれかに影響を与えるすべてのライトを格納したリストを持つ。

このリストはそのピクセル間で共有されるため、メンテナンスとフェッチのコストは小さくなる。

ライトがリストに入るかどうかは、スクリーン空間上でライトとタイルとの接触判定を行って決める。

Depth Range Optimization#

タイルごとに最大最小深度を求めておいて、その値を用いてオブジェクトの無い空間にあるライトをカリングする。

これをしないと、普通はパフォーマンスがだだ下がる。

Tiled Forward ShadingではPre-Zパスが必要な理由でもある。

Tiled Shading Light Grid#

すべてのライトは、ライトのインデックスを格納するリストと、タイルが参照しているインデックスのリストの範囲を格納するグリッドに処理される。

まとめ#

Troublesome Tiles#

深度に不連続な部分があると、タイル内で取り得る深度範囲が大きくなる。非常に奥行きのある場合も同様。

深度範囲が大きいと、どう頑張っても影響外でしかないライトを無駄に集めてしまう。

Tiled Extensions#

この問題に対する緩和策がいくつかある。

この緩和策の問題点として、

• 傾斜やマルチレイヤーを扱えないなど、一般性に欠ける。
• 透明処理が扱えない

キーアイデア#

深度方向にも分割する。

関係するサンプル点をグループ化したクラスタを用いる。

関係を定義するのは3次元のユークリッド距離を使う。要は、空間的に近いかどうか。他にも、法線や反射率なんかも使える。

froxel = frustum voxelと大体同じもの。

プロパティ#

3次元的な分割を行うことで、さらなる局所化やサンプルグループごとに一貫したボリュームができる。

つまり、シーンのライト密度と実行時シェーディングコストの間に相関が生まれる。

制御性とパフォーマンス予測性が大事。

クラスタキー#

2Dタイルの座標i,jと、サンプルのview空間での奥行きを示す対数関数kを使って、3Dグリッドを表現する。

この対数による分割では、クラスタはできるだけ正方形になるように調整されている。

つまり、ある種のLODのようなもので、viewパラメータを広めにとってもクラスタ数が爆発しないようになっている。

ライト割り当て#

Tiled Shadingと同じように、ライトとクラスタが重なるかどうかを見つける。

クラスタごとのリストに記録する。

バリエーション#

クラスタグリッドをsparseにするかdenseにするか

クラスタがexplicitかimplicitか

deferredかforwardか

階層的にするか否か

透明処理のサポート