私的メモ。
I think this 'Realistic Interactive Grass Shader' works now?! Only Y Position of Grass Blades; still need to add X and Z directional bending.#madewithunity #gamedev pic.twitter.com/9BPRamybMd
— Andy Touch (@andytouch) February 8, 2019
おはござ！Pocolです。
今日は，
[Jimenez 2016] Jorge Jimenez, Xian-Chun Wu, Angel Pescec, Adrian Jarabo，
“Practical Realtime Strategies for Accurate Indirect Occlusion”,
SIGGRAPH 2016 Courses: Physically Based Shading in Theory and Practice, https://blog.selfshadow.com/publications/s2016-shading-course/, 2016.
を読んでみることにします。いつもながら，誤字・誤訳があると思うので、ご指摘いただける場合は正しい翻訳例と共に指摘していただけるとありがたいです。
こんにちわ、Pocolです。
今日はSIGGRAPH 2019 Advanced in Real-Time Rendering in Gamesのコースで発表された，
Stephne McAuley, “A Journey Through Implementing Multiscattering BRDFs & Area Lights”を読んでみようと思います。
図は引用しませんので，図についてはhttps://advances.realtimerendering.com/s2019/index.htmのページからスライドをダウンロードして参照してください。
Slide.1
ノートなし
Slide.2
ご紹介にあずかりましてありがとうございます。そして、皆さんおはようございます。
この話は、今年の2月にNatashaからI3Dでの講演を依頼された時のことです。ご存知ない方もいらっしゃるかもしれませんが、I3DはSIGGRAPHと同じようなコンピュータグラフィックスのカンファレンスで、インタラクティブレンダリングに焦点を当てており、学術関係者とゲーム業界の専門家が一堂に会しています。Natashaは、最初から最後まで研究してビデオゲームに仕上げるということがどういうことなのかを説明できるような講演ができたらいいと提案してくれました。当時は、実際に何か話すことがあるのかどうか、本当に自信がありませんでした。私が最後に出荷したゲームは1年以上前の『ファークライ5』でしたが、制作開始時にリサーチをする傾向があり、それはもう何年も前のことで、私の記憶からは消えてしまっていました。しかし、Natashaが尋ねてきたので、私はとにかくイエスと答え、かなり一般的な話のタイトルと説明をして、考え始めました。
それと同時に、私は多重散乱BRDFやエリアライトの研究をしていました。最初のうちはすぐに結果が出たのですが、数週間が経つにつれ、解決しなければならない問題がどんどん出てきました。そこで、一方では研究を製品に移すためにどうやって話をするかを考え、他方では研究を製品に移すために研究を実施していましたが、多くの困難にぶつかっていました… そしてしばらくして、ようやく2つと2つを合わせた結果、このような話になったのです。
ここでは、私がこれまでに行ってきた多重散乱BRDFやエリアライトの研究、直面してきた問題点、そしてその解決策について説明します。もちろん、未解決の問題もありますので、皆さんのご協力をお願いします。また、これには有用なビジュアルや、あなたのゲームにもこれらの機能を搭載したいかどうかの情報が含まれていることを期待しています。最後に、これを実装したときに学んだことを簡単にまとめておきます。
Slide.3
ファークライ5の最後に、私たちのマテリアルシステムが少し古くなってきていると感じていました。確かに、以前はかなり良かったのですが、2012年のディズニーのBRDFモデルをベースにしていたのですが、ディズニーのディフューズモデルではなく、Lambertianのディフューズを使用していました。多くの研究が出てきていたので、そろそろアップグレードをして、そこに何があるのか、そしてそれが私たちにどんなメリットをもたらすのかを見てみようと思ったのです。
アーティストの問題点もいくつか挙げられていました。一般的に、人々はまだより多くのスペキュラが見えることを望んでいましたし、もう一つの願いは、拡散のための少し柔らかいフォールオフでした。さらに、もちろん誰もがゲームをよりリアルに見せたいと思っていますし、より良いマテリアルととライティングはそのための重要な手段です。
Slide.4
ここ数年で最も興味を持った論文は、Eric Heitzらによるこの優れた論文でした。 多重散乱を真に私の目に留める最初の論文であり、私たちが標準的なスペキュラーモデルからどれだけのエネルギーを失っているのかを実感させてくれました。 これは私にとって啓示でした。私はこれまでエネルギー保存の啓蒙に多くの時間を費やしてきましたが、実際には多くのエネルギーを失うことに満足していたことに気付きました。
しかし、私はこの問題をどうすればいいのか全くわかりませんでした。この論文では、いくつかのかなりブルートフォースな解法が書かれていましたが、リアルタイムの近似値を見つけるための明確な道筋が示されているわけではありませんでした。
もちろん、最終的には誰かがそれをやろうとしていたのですが…。
Slide.5
そこでソニー・イメージワークスのクリス・クラとアレハンドロ・コントフの出番です。彼らは、エネルギーを維持するために設計された簡単なトリックによって、SIGGRAPH 2017 で多散乱スペキュラへの近似を発表しました。それはいくつかの簡単な数式と簡単に計算可能なLUTに減少したので、これは非常に多く成功したものに見えました。
Slide.6
かなりシンプルなアイデアです。失われたエネルギーを補うBRDFが必要だと述べています。
Slide.7
そこで、BRDFによって与えられた方向において反射されたエネルギーそして平均エネルギーに基づいて、フィットするBRDFを見つけます。これは、すべてうまく動作します…
Slide.8
…しかし、実際には、エネルギーはバウンスごとに(サーフェイスによって吸収され）失われるので、いくつかの失われたエネルギーが必要です。そこで、無限のバウンスの損失を合計して、次の式で多重散乱BRDFを計算します。ここでの\(F\)はもちろんフレネルであり、各バウンスで失われる平均エネルギーの何分の一かを与えてくれます。
Slide.9
しかし、これを実施する必要があるとしたら、何をすればいいのでしょうか？そうですね、3つのことを計算する必要があります。
与えられたサーフェイスラフネスについて1から与えらた方向におけるエネルギーを減算する，与えられたラフネス対する平均エネルギー，そして与えられたスペキュラーカラーについての平均フレネルの3つです。これには半球上での積分とフィットが必要になるので，Visual StudioとMathematicaを取り出しました。
Slide.10
最初に私は、反射エネルギーを差し引いたものを得るために、半球上についてBRDFを積分しなければなりませんでした。そして，これを角度の余弦とサーフェイスののラフネス（または、我々の場合ではスムースネス）でパラメータ化された2D LUTに格納します。
Slide.11
次に，与えれた方向において反射されたエネルギーを取る必要があり，与えられたラフネスに対して平均エネルギーを得るために半球上について積分します。そして，そのデータを Mathematica に取り込み，フィットを見つけました．
Slide.12
平均フレネルを得るためにShclickのフレネルの単純な解析的積分に投げて，次の関数とシェーダ上で我々が使用することができる参照テーブルで終わります…
この論文の実装は特に難しいものではありませんでしたが，Mathematica の知識とLUTを生成するためのC++コードを書く時間が必要でした．
それでは結果を観てみましょう！
Slide.13
ここからは球の列から始めます。左から右へとスムースネスが増していきます…
Slide.14
多重散乱スペキュラーをオンにして……そして……..何か違いがあると思いますか？実際には、前後に切り替えれば、大まかな球体に小さな変化が 見られますが、はっきりとは分かりません。これでは、私たちが望んでいたような大成功は得られません。
でも、あきらめる前に、金属で試してみましょう。
Slide.15
再度、金色の球体の多重散乱スペキュラーオフから始めます。
Slide.16
…そして、切り替えてみると、すごい違いがあります。本質的には、鏡面反射率が大きいほど エネルギーが少なくて済むので、 跳ね返りごとに失われ始め、 大きな効果が得られます。
実際、多重散乱スペキュラーに関する論文では、最も粗い金属を助けることに言及していますので、私はそれらにもっと注意を払うべきだったかもしれません。
だから、私たちが求めている全体的なイメージでは大成功にはならないかもしれません。典型的なファークライの「ポストカード」ショットには、誘電体である木や岩や土などの自然が多く含まれています。しかし、私たちは金属製の乗り物や武器を持っています。実際、私たちの担当アーティストはこの効果をとても気に入ってくれています。
Slide.17
多重散乱スペキュラーがうまく機能していたので、新しい拡散モデルを導入することにしました。
Slide.18
Lambertianディフューズはかなり貧弱なので、次のような改善が欲しかったです。
1. 多重散乱が考慮されている - 私たちは、単一散乱からエネルギーを失うことをスペキュラーから学んでいますが、これを拡散についても解決できるか？
2．サーフェイスのラフネスに反応する。これは、より興味深い材質を提供してくれるでしょうし、うまくいけば遠方でのディテールの保存性も向上します。例えば、岩や木の幹のような強い法線を持つ物体には問題があります。それらが距離を置くと、ミップマップは平坦になり、以前見たような強い拡散照明は見られなくなります。理想的には、ある種の見た目のフィルタリングを行いたいのですが、これは既存のスペキュラの見た目のフィルタリングとうまく調和するかもしれません。
3．法線の分布に反応する – 鏡面にGGX分布を使用している場合、拡散にも同じことができるか？
4．拡散 vs 鏡面はエネルギー保存です。たぶんこれは拡散が明るすぎる vs スペキュラという意味で、本来改善しようとしていたスペキュラの量が減ってしまうということなのでしょう。
Slide.19
ありがたいことに、他の誰かがこれらの条件をすべて満たすモデルを考え出していました。Sledgehammer gamesのDanny Chan氏は、昨年、Advances in Real-Time Renderingという素晴らしいプレゼンテーションを行いましたが、その中にはゲーム内のマテリアルを改善するための素晴らしいアイデアがたくさんありました。
Slide.20
新しい拡散モデルのベースは、我々が多重散乱スペキュラーBRDFに興味を持ったのと同じ論文に遡る。Danny Chanは、提供されたソースコードを使って多重散乱拡散モデルのデータを生成し、フィットを見つけました。
Slide.21
プレゼンテーションで説明されているフィッティングプロセスは非常に複雑ですが、最終的にはシェーダで使用できる比較的シンプルな関数になります。
[このコードについてWillam Bussiereありがとうございます]
Slide.22
でも、一行だけ強調させてください。彼の論文では、Dannyは我々とは異なる表面の平滑性のパラメータ化に対してフィットしています。そのため、2つの間で変換するためにいくつかの余分な命令を追加しなければなりません…もちろん、自分自身でモデルを実行し、自分自身のフィットを行うことに時間を費やさなければなりません。
Slide.23
いくつかの結果を見てみましょう。ここでは、左から右に向かって滑らかさが増している球体を示していますが、ランバート拡散では全く効果がありません。
では、多散乱拡散をオンにしてみましょう。
Slide.24
粗い球について良い再帰反射が発生しているのを見え，そしてよりスムースな球については柔らかなファールオフが見えます。
実際、私たちのアートディレクターの一人は、常に拡散のための厳しいフォールオフについて文句を言い、フォールオフの柔らかさのために線形空間照明よりもガンマ空間照明を好むようになりました。だから、これはゲームに役立つものになりそうですね。
もう一つ興味深いのは、これらの写真の中の地上面がどのように変化しているかを見ていることですが、多重散乱拡散によって暗くなっています。これは実際にゲームで見ることができる多重散乱拡散の最大の効果の一つであるので、私はこれを指摘しています。絵葉書のように、空と地形の比率が変化し、画像全体に影響を与えています。これが私たちのライティングアーティストにどのような効果をもたらすのかは、今後見ていかなければなりません。
Slide.25
プロジェクターでは違いがわかりにくいかもしれないということを踏まえて、もう少し違いを強調してみることにします。右側の滑らかな球体の場合は、ちらっと見るような視野角でのエッジのフォールオフに加えて、グレージング光の角度でのより滑らかなフォールオフを見ることができます。左の粗い球についてはライティングを平らにする追加の再帰反射性を見ることができます。
Slide.26
新しい拡散モデルと鏡面モデルができたので、これで終わりかな？
悲しいことに……そうではありません……..まだまだです……..
Slide.27
ファークライには、スペキュラ用のGGXや拡散用のLambertだけでなく、実際には置き換えなければならないBRDFがたくさんあります。拡散照明をアップグレードしたいのであれば、理想的には事前積分された表面下散乱も更新し、さらにLambertのラップドライティングを模倣する方法を見つける必要があります。鏡面照明については、すべてのケースでエネルギーを節約したいのであれば、髪の毛や布にもそれを行う必要があるかもしれません。
Slide.28
でも、ライトの種類もいろいろあります。直接照明の場合は、単純な解析評価がありますが、これは簡単です。しかし、間接照明のための球面調和関数やキューブマップもあります。率直に言って、間接照明をBRDFに従わせることは必ずしも得意ではありません – 例えば、SHを使ったスキンの評価は今のところ何もしていません。しかし、環境ではなく、直接照明だけを対象としたスペキュラ照明の量を増やす大きな機会を逃しているように感じます。
Slide.29
問題点をまとめてみましょう。間接照明には多散乱BRDFがなく、表面下散乱BRDFもありません。これは、私たちのラップされたディフューズとスキンを含みます – そして最終的に私たちは髪のための解決策を持っていません。BRDFsは、布素材のエネルギー損失をほとんど補うことができるちょっとしたハックです。また、我々のエンジンでは、スキン上の間接的な拡散のためのソリューションを持っていないことにも注意してください、したがって、我々はすでに一緒に暮らしている既存の問題があります。
Slide.30
最初に解決しようとする問題は間接的なスペキュラで、これはほぼ確実にゲーム、特に我々のラフメタルに最も大きな影響を与えるからです。
Slide.31
ということで、やってみましょう。これが環境照明のために 解こうとしている基本式です この場合、環境照明はキューブマップから来ており、半球上で積分しています。問題は、ゲームではリアルタイムでピクセル単位での積分ができないことです。そこで、いくつかの近似案を用意しました。
Slide.32
2013年のBrian Karisの研究から、分離総和積分を用いて結果を近似しています。異なるラフネスに対してキューブマップを事前に積分し（高いラフネスの結果はキューブマップの下位のミップレベルに格納されます）、BRDF部分をLUTに積分します。これは、スクリーン空間の反射に対しても非常に有効です。- それらは事前積分されたキューブマップを置き換えるだけで、同じLUTを使用しています。
Slide.33
LUTを環境BRDFと呼び、Schlickのフレネル近似を使えば、2つのコンポーネントに分割することができます …
Slide.34
つまり、LUTは、出射角（視野方向）の余弦と表面のラフネスの2つの次元に過ぎません。\(F_0\)項、つまり鏡面反射率は外に因数分解されています。
Slide.35
最初は、これに多重散乱BRDFを加えるのは簡単だと思っていました。事前に積分しているので、積分しているBRDFにMSのBRDFを追加で追加するだけです。環境BRDFの多重散乱部分はこんな感じです。
Slide.36
しかし、一度平均的なフレネル項を展開してみると、結局のところ、物事はそれほど単純ではないことに気づきます。もしこれを既存の環境BRDFに追加するのであれば、\(F_0\)に線形依存性を持たせたいのですが、ここではそれがありません。そこで私は思いついたのですが、関数の指数を展開をして、何が得られるかを見てみませんか？
Slide.37
このような近似値が得られ、これは素晴らしくシンプルであり、環境マップBRDFに追加することができます。また、\(F_0\)の指数項をもっと増やして、また望めば2つの代わりに3つの私たちの4つのコンポーネントの環境BRDFを取得して環境マップBRDFに組み込むこともできます。
当時は、係数は2つで十分だと思っていました。誘電体の\(F_0\)項は0.1以下になる傾向があると思っていたので、その後の指数項はあまり重要ではないだろうと思っていました…そのときは、私は多くの高い鏡面反射率を持つ粗い金属のための最大の違いを作る多重散乱スペキュラを忘れていたと思います…
Slide.38
これは、環境マップBRDFを多分散項で更新したときに、うーん……うーん……..ほとんど違いが見られないことを意味しています。実際，8ビットでは違いがあるとは思えませんが，16ビットでは間違いなく違いがあります。
Slide.39
我々はこれが金属上でどのように見えるかを見た場合で、これは標準的な環境マップBRDFです…
Slide.40
… そして、これは多重散乱環境BRDFです。我々は、金属のための小さな違いがみえますが、どこにも我々が直接光で我々の結果を比較して、見えるべきはずの大きな違いはどこだかわかりません。
だから私はこれのための解決策に困惑していました…
Slide.41
…そして、この論文が出たのと同じ頃だ！自分が研究していたものと全く同じことに取り組んでいる人を見るのはいつも本当に刺激的です…そしてこれはゲームに本当に関連する問題を解決した論文でした。また、既存の研究を拡張して、Kulla と Conty の研究をリアルタイムの画像ベースの照明に適用できるようにしたのはとても素晴らしいことだと思います。
Slide.42
この論文は、環境BRDFの赤と緑のチャネルの合計は、実際にはその方向の出射エネルギーと同じであるという（他の人が持っているように）賢い観察を行います。また、この項が平均エネルギーを近似することができることを観察しています。
Slide.43
そして、この論文は、照明の多重散乱部分について、次のような簡単な式に到達します。もちろん、平均フレネルのような項が簡単に計算できるのは助かります。しかし、多重散乱光は拡散性があることに注意して、キューブマップの低いミップレベルをサンプリングするか、放射照度を球面調和関数に格納することを推奨しており，放射輝度ではなく光の放射照度を取ることにしました。
今はそれでいいんだけど、ゲーム開発者の自分は怠け者なんです。また、たくさんの命令は節約したいです。特にテクスチャサンプルは可能な限り省きたいです。そのため，放射照射の部分はあまり好んではいません。
Slide.44
私たちは粗い金属で多重散乱の最大の影響を受けていますが、これは、私たちがサンプリングしている鏡面照明がかなり拡散していることを意味していますので、あまり重要ではないかもしれません。おそらく、放射照度のために放射輝度を代入すれば、まだ問題ないでしょう。
では、いくつかの結果を見てみましょう。
Slide.45
我々はもちろん金属を見ていきますが、これは標準的な環境マップBRDFを使用しています。
Slide.46
これはFdez-Agüeraの近似で、失われたエネルギーを本当に補っているので、これは素晴らしいことです。
Slide.47
そして私のFdez-Agüeraへの近似値です。…..これは……..ほとんど変わらないように見えます。少なくとも私の場合は 私の近似値が有効だったようです。
Slide.48
これが素晴らしいのは、単一散乱BRDFをスケーリングすることができる多重散乱BRDFの公式を提供してくれることです。他の事にも応用できるかもしれないので，かなり素晴らしいです。面白いのは、これを理解した後、私は…
Slide.49
… Emmanuel Turquin氏の技術レポートが出てきましたが、Heitz氏の元の論文から、多重散乱ローブが単一散乱の縮尺版に非常に似ていることを観察し、この近似を思いついたとのことです。これは、我々がFdez-Agüeraから導き出したものと大きな違いはありません。同じ分野の研究をしている人がいて、すぐに試すことができる非常に実用的な近似法を考え出したのですから、これは素晴らしいことです。既存の非常に成功した研究の上に構築し、議論に貢献したもう一つの例です。
結果を見てみましょう。
Slide.50
これが私のFdez-Agüeraの近似値です。
Slide.51
そして、これはEmmanuel Turquinのものです。この2つはかなり違っていて、特に色の面では、Emmanuel Turquinの方が少し明るいようです。根拠のある比較をする時間がないのですが、ここでは2つの選択肢があります!
しかし、この2つの多散乱スペキュラーBRDFへのアプローチがダイレクトライティングでどのように機能するのか、また、私たちが最初に実装したSony Imageworksのアプローチとどのように比較しているのかを見てみましょう。もう一度、金属球でテストしてみましょう。
Slide.52
ソニーイメージワークスのオリジナルアプローチです。
Slide.53
これはFdez-Agüeraに近似して、単一散乱ローブをスケーリングしたものです。ハイライトの形状にかなり大きな違いがあることがわかります。特に、中程度の粗さの球体では、エッジで多くのエネルギーを失っています。下端でもエネルギーが失われています。
Slide.54
そして、こちらはEmmanuel Turquinのものです。Fdez-Agüera の問題点はそのままに、ハイライトの形状が Sony Imageworks のアプローチと一致していませんが、粗い面では少し明るくなっていて、Sony Imageworks のアプローチと一致していることがわかります。このことから、環境照明ではTurquin氏の手法がベストだが、直接照明ではソニーイメージワークスの方がグレージング角度でエネルギーを保存しているのではないかと考えてしまうのです。しかし、やはり、グランドトゥルースとの比較が必要です。
私はまた、あなたが環境ライティングのための多散乱スペキュラのためのまだ別のソリューションが必要な場合は、ここで言及する必要があります、Stephen Hillは最近、同じ領域でいくつかの作業を行っており、最近のブログ記事では、彼は少し異なる方法で環境照明のための多散乱の問題を解決する4項の環境BRDFを提唱しています。あなたがこの問題にアプローチするためにさらに多くの方法を考えたいと思っているならば、十分に読む価値があります。
Slide.55
しかし、私が環境照明のこのトピックを見始めたとき、Fdez-Agüera の論文に何かがあり、私は完全に脱線しそうになりました。平均フレネルを計算する式の一つを見てみましょう。
Slide.56
私が本当に頭を悩ませたのは、この方程式にも他の方程式にも存在するπという係数が追加されていたことでした。Sony Imageworksの論文を自分で実装していたときは、これらの積分をπで割って正規化していたので、正しい結果が得られたように見えたのですが、自分の数学的能力にはすでに自信がありませんでした。しかし、自分の数学的な能力には自信がなかったので、自分が何をしたのかちょっと自信がありませんでした。だから、査読付きの論文で、自分とは違う方程式を見て、本当に混乱して、どうしたらいいのかわからなくなってしまったのです。私がやったことはすべて間違っていたのでしょうか？
さて、私は調べてみて、円周率が間違っていることを確信するようになりました。著者に問い合わせするためにメールを送ろうとしていたのですが、このツイートを見たとき…
Slide.57
ほっこりしました！（笑）。先に報告してくれた善良なサマリア人に感謝です。
Slide.58
問題のリストに戻りましょう。次は髪の毛の多散乱スペキュラについてですが…。
Slide.59
悲しいことに、これは今のところTODOリストに入っています。我々は単一散乱BRDFのスケーリングファクターを使って検討することができましたが、透過率と第二鏡面ローブではもう少し厄介です。この話はまた後日にしなければならないので、今のところはここまでにしておきます。
Slide.60
しかし、最後の３つの問題、表面下散乱の多重散乱と間接拡散についてはどうでしょうか？さて、これらの問題については、次のトピックに移ってから解決策を考えることにしましょう…
Slide.61
…それは、エリアライトです。
これはマテリアルの改良を補うもので、今度はライト自体の改良に目を向けたいと思います。
Slide.62
ライティングアーティストにはシネマティクスでの選択肢を増やしてもらいたいですし、エリアライトを使うことで、光の大きさを介した拡散のフォールオフをより制御できるようにしたいです。我々はまた、より目に見えるハイライトで、より広くよりスペキュラーを得られるでしょう。これは、アーティストがより滑らかなマテリアルをオーサリングするようになり、100%滑らかな表面が、無限に小さな鏡面ハイライトで少し変に見えなくなるという追加の利点があります。
Slide.63
エリアライトを見るとき、Eric Heitz氏らが2016年に発表した論文「Linearly-Transformed Cosines」を使って調査することは、技術的にはどんなBRDFでも動作するポリゴンライトを使ったリアルタイムのシェーディング方法を説明したもので、迷うことはありませんでした。
Slide.64
LTC を選択したのは、デモを含めた完全なソースコードが利用可能であることを知っていたため、ゲームに追加してすぐに試すことができたからです。実際、最も難しかったのは、GLSLデモをHLSLに変換する際に行列を転置しなければならなかったことです。完全なソースコードは、後になって変更を加えなければならないときにも、本当に役に立つことがわかりました。彼らは、すでにクワッドライト、ディスクライト、ラインライト、テクスチャマップされたライト、そしていくつかのスケーラブルなパフォーマンスオプションを提供してくれていたので、これで物事がうまくいくという大きな自信がつきました。さらに、デモやコードを見ると、これらのライトが堅牢で、ゲームに実装するのに適した性能を持っていることが明らかでした。
Slide.65
みなさんが同じ認識を持つようにLTCとは何かを簡単に説明しましょう。
LTCはかなりわかりやすいので、テクニック全体のマジックですね。まず、多角形のエリアライトを評価するためには、球面分布上で多角形を積分する必要があることを観察することから始めます。これは多くのBRDFにとって解けない数学的な問題ですが、多角形の形状を解析的に積分することができるクランプされた余弦分布があることがわかります。
Slide.66
そして、この分布を線形変換して任意のBRDFに適合させることができます。
Slide.67
そこで、線形変換された余弦にBRDFをフィットさせ、多角形上で積分するときに逆変換を適用すれば、答えはクランプされた余弦分布上で多角形を積分することになりますが、これは解法がわかっています。
Slide.68
しかし、LTCは常に1に積分しますが、BRDFは1以下に積分することがあります。 BRDFの大きさでスケーリングし、フレネル項も考慮する必要があります。そのため、我々は半球上のBRDFを積分し、LUTにデータを格納するだけです…
Slide.69
実際には、Schlickの近似をフレネルに適用すると、2つの成分が得られ、それをサーフェイスの\(F_0\)項に基づいて合成し、LTCを拡大縮小することができます。
さて、これは非常に馴染み深いものに見えるかもしれません……正確にはそうです。これは、わずかに異なるパラメータ化ですが、環境BRDFのそれと非常によく似た考え方です。これは後で非常に役に立ちそうです。
Slide.70
提供されたすべての優れたコードとデモのおかげで、実装は比較的簡単になりました。オフラインでは、BRDFのために2つのルックアップテーブルを生成します。最初のルックアップテーブルには、逆行列変換の座標が含まれており、その角度と粗さでBRDFに線形トランスフォームされた余弦近似を形成し、半球上でクランプされた余弦に戻します。2番目のルックアップテーブルは、与えられた視野角でその大きさによってBRDFをスケーリングするために、以前に議論した環境BRDFに非常に似ています。
Slide.71
スムースネスが増加する誘電体の球でこの見た目をみてみましょう。太陽の光の代わりに クワッドライトを使ってみます
Slide.72
特に滑らかな表面のスペキュラハイライトはかなり素晴らしいですね。ディスクもできますよ!
Slide.73
これもまた、かなりカッコいいですよね!
ディフューズも変わってきていますね。Lambertianディフューズは球体の上にクランプされているので、LambertianディフューズのLTCを実装することは些細なことです。我々は、エリアライトのサイズから素敵な柔らかいフォールオフを得ます。そして，それはアーティストが好きになることを知っています。
Slide.74
GGXとLmabertディフューズに対してエリアライトが実装されているので、これで万事順調ですよね！？
Slide.75
でも…また組み合わせの問題に戻ってしまいました。GGXのBRDFだけではありません。Lambert BRDFは半球上のコサインをクランプしただけなので、些細なことですでに解けていますが、ラップドディフューズはどうでしょうか？pre-integrated scatteringは？髪の毛と布？これらの問題は、我々の新しい拡散BRDFと鏡面BRDFで直面した問題と似ています。
Slide.76
しかし、実際には悪化している。あとは、エリアライトを多散乱拡散光や多散乱鏡面光にも対応させなければなりません。
Slide.77
本質的には、BRDFを評価しなければならない別のライトタイプを追加しただけです。
Slide.78
ということで、現在の状況をまとめてみましょう。布、多重散乱拡散、髪の毛の3つの基本BRDFについては、LTCを実装していません。また、非エリア照明パスのために実装した多散乱スペキュラもありません。最後に、ラップされたディフューズと事前積分済み肌散乱とLTCをどのように組み合わせればいいのかわかりません。
Slide.79
しかし、私たちにはお祝いの理由があります！LTCのソースコードが利用可能になりました 最も重要なのは 任意のBRDFに対してLTCを適合させるコードです これにBRDFを差し込んで、フィッティングを実行してLUTを作成すればいいのです。
Slide.80
ということで、まずは布と多散布のディフューズを動作させることから始めてみましょう。
Slide.81
そこで、まず多散乱拡散用のLUTの生成から始めましょう。逆行列はGGXと比較してあまり多くはありませんが、ラフネスと視野角はこのBRDFに対してより小さな効果をもつということを期待しています。
Slide.82
Lambertian拡散の結果から始めましょう…
Slide.83
望ましい効果が起こっているのがわかります。ライティングは、粗い面ではやや平坦になり、再帰反射性が高くなっていますが、滑らかな面ではわずかにフォールオフがあります。滑らかな表面は、グレージング視野角でも暗くなってきています。マテリアル上の拡散照明がポイントライトと全く同じ反応をしているので、求めていた効果が得られています。
Slide.84
Ashikhminの布BRDFにも試してみましょう! これはどのように動作するかを見てみましょう…
Slide.85
今回はポイントライトクロスの実装と比較してみます。私たちのクロスモデルで最大の再帰反射とシャープな効果を発揮するのは、粗いサーフェイスです。
Slide.86
これはかなり良さそうですね! 確かに違いますね、少し拡散しているような気がします。でも、今のサイズのライトがあるので、それはそれで期待できそうです。これならまだ、いろいろな素材に布の効果が得られそうだし、これはこれでいいかな。
Slide.87
しかし、私たちのエンジンでは、Ashikhminの布BRDFだけでなく、ディズニーのBrent Burleyが提案したような光沢のある素材を使用しています。これはBRDFなので、\(N \cdot L\)の項でスケーリングされています。つまり、効果的には、これはフレネルを使ったLambertianディフューズです。
Slide.88
ですから、これはエリアライトとして計算するのは実はかなり簡単なのです。私たちはLambertian拡散の評価を使い、大きさのフレネル成分と多散乱拡散のフレネルLUTを使って計算しています。技術的にはLambertian拡散のために1つのLUTを使うべきですが、すでに持っているLUTを使えばいいのに、なぜ別のLUTが必要なのでしょうか？我々は、Lambertian拡散に最も近いと仮定して、スムースネス0.5でサンプルを作成しています。
Slide.89
ポイントライトで照らすとこんな感じの光沢になります。ここでは効果を誇張して見やすくしていますが、左から右に向かって強さが増しています。
Slide.90
エリアライトで有効にすると、実際には、より多くのリム効果が得られるような微妙なものになります。しかし、このリム効果が残っているので、布のエリアライトが使えるようになり、この素材が布であることが伝わります。エリアライト用のAshikhminの布BRDFに少し似ているような気がします。
Slide.91
次の問題は多散乱スペキュラです。欲しいBRDFを実装したばかりですが、LTCで使えるようにしないといけませんね…。
今、最初は、これは布や多散乱拡散と全く同じで、異なるBRDFでフィッティングコードを使用するだけだと思うかもしれませんが、実際には、これはすでに議論したトピックと同じ問題を持っています – 間接的なスペキュラと環境BRDFです。
Slide.92
以前は、BRDFを(F_0\)への線形依存性に分解し、2つのコンポーネントをLUTに格納することができました。しかし、今回も多散乱BRDFは非線形に\(F_0\)に依存しているので、このトリックは使えません。
Slide.93
でも、解決策があります！環境BRDFと同じソリューションを使うことができます!
Slide.94
今、シングルスキャッタリングBRDFをスケールすることが可能な多重散乱BRDFについての定式を得ました。これは素晴らしいです。なぜかというと高速でシンプルかつLTCsに適用できるからです。環境BRDFから我々ができることと同じように大きさとフレネルLUTからエネルギー項を得ることができます。
Slide.95
Emmanuel Turquin公式を使うこともできますよ！試してみましょう。
Slide.96
まずは単一散乱スペキュラーから見ていきましょう。
Slide.97
多重散乱BRDFを得るためにFdez-Agüeraへの私の近似を使用してみましょう。
Slide.98
そして最後に、Emmanuel Turqinの解答を見てみましょう。もう一度言いますが、これは Fdez-Agüera のアプローチよりもわずかに明るいのですが，色が少なくなっています。
Slide.99
次に解決すべき問題は、ラップドライティングです。面白いのは、この問題はエリアライトだけでなく、多散乱拡散に対しても解決しなければならないので、もしかしたら両方に使える解決策があるかもしれません。
Slide.100
まずは、ラップドディフューズを簡単におさらいしてみましょう。入射光角の余弦であるランバーティアン拡散を球体にラップします。ラップ係数は、何の効果もない 0 から、照明を一周させる 1 の間で変化します。
これは素晴らしいことですが、他のBRDFではどうなのでしょうか？例えば、我々の新しい多散乱拡散モデルでは、入射角に依存する項と、出射角に依存する項があります。両方をラップする必要があるのでしょうか？エリアライトについてはどうでしょうか？
いい考えがあります…ここでのように入射光の余弦を操作するのではなく、直接法線を変えればいいのではないでしょうか？
Slide.101
光に向かって法線を回転させれば、確かに同じ効果があるのではないでしょうか？そして、我々は、我々が望むどんなBRDFでも、我々のすべての通常のライティング方程式で法線を使用することができます。
Slide.102
これは、単純な軸と角の回転だけに集約されます。しかし、回転角度は球体の周りにどれだけ遠くにするかに依存します。法線が光の方向を向いているとき、cosθが1のときは、全く回転したくありません。一方、ラップしたい球体の周りで一番遠いところにいるとき、cosθが-wのとき、θがπ/2になるところまで回転したいです。
しかし、シェーダコードでは、実際にはコストのかかる逆余弦を避けたいので、代わりに角度の正弦をブレンドすることができます…
Slide.103
…それははるかに、はるかに速い！
Slide.104
光の方向とラッピングファクターに基づいて法線を調整するために使用できる比較的シンプルなシェーダ関数になります。
Slide.105
でも、正規化はどうなんでしょうか？もし照明を球体の周りにさらにラッピングしているのであれば、効果的にエネルギーを追加していることになります。
Slide.106
球体のキャップの表面積を見ることで正規化できることがわかりました。
Slide.107
球体の最遠距離におけるcosθの定義を思い出し、それを球体のキャップの表面積に代入すると、次の式が得られます。
Slide.108
そして、それを半球の表面積と比較すると、次のような単純な正規化係数が得られます。
興味深いことに、実は過去にラップした拡散照明の正規化についてのブログ記事を書いたことがあるのですが、その時に考えた正規化係数がこれです。突然、別の正当な理由を見つけたのには驚きました。
Slide.109
より良く見える結果をご紹介します。
ちょっと不正確なのは認めます。パフォーマンスのために角度の代わりに角度の正弦波をブレンドしているので、正規化係数はBRDFには正しくありません。しかし、これはゲームなので、パフォーマンスのためには「十分」であるべきだと考えています。
試してみましょう。
Slide.110
点光源を見ることから始めましょう。そして，われわれの多重散乱ベースのディフューズモデルです。
Slide.111
球体の50％を包むことができます…
Slide.112
…と100％で、すべてが持ちこたえているようです。ラフな球体は、フラットな照明ではまだラフな感じがしますが、これはまさに私たちが目指しているものです。
Slide.113
次はエリアライトとLTCで結果を確認します。
Slide.114
再度、球体の50％を包むことができます…。
Slide.115
…そして100%です。期待通りの結果が出ています。これはかなり素晴らしいですね！これでラップドライティングをすべてに適用できるようになりました この問題が解決したと考えてみましょう。
Slide.116
いま、ラップドディフューズがが終わったので、次にpre-integrated skin scatteringを見てみましょう。それはある意味では非常に似ています…
Slide.117
スキンのためのPre-integrated scatteringは、SIGGRAPH 2011でEric Penner氏が発表した技術です。pre-integrated scatteringのトリックは、異なる曲率の球体上のランバート拡散を、スキン散乱の拡散プロファイルで積分することです。
Slide.118
多重散乱拡散のためにこれを解かなければならないとしたら、新しいBRDFの上に積分する必要がありますが、これはLambertと比較して2つの余分なパラメータ、すなわち視野角とラフネスを持っています。もちろん、もし実際にこれを研究していたら、フィットを見つけたり、次元を小さくしたりできるかもしれませんが、エリアライトの問題を解決することはできません。
Slide.119
しかし、ゲームで使用されているスキンの散乱については、ここでは別の解決策があります：分離可能なスクリーン空間のサブサーフェス散乱です。これはスクリーン空間内で実行され、既存のライティングバッファをぼかすので、技術的にはどんなBRDFでも動作します。さらに良いことに、これは間接的な拡散照明でも動作します。
ファークライ3では、プレインテグレーテッド・スキャッタリングとスクリーンスペース・スキャッタリングのどちらかを選択しなければならなかった時、我々は間違った馬にベットしていたように思えます。まあ、前者の方が実装時間とパフォーマンスの両方ではるかに速かったのですが、今は… 後者の方がはるかに柔軟性があるように思えます。本質的には、BRDFとライティングの選択と直交しており、その直交性はしばしばレンダリング技術において本当に重要になることがあります。
Slide.120
悲しいことに、これは今のところ、私たちのTO Doリストに入っていますが、それはまた後日に戻ることになります。
しかし，より将来性をもって問題を解決してくれそうな気がします。
Slide.121
最後の未解決問題は、髪の毛にLTCをどのように適用するかです。
Slide.122
まあ、悲しいかな、これもTO DOリストに載っている。マーシュナーの髪には ３つのローブがあります 本質的には反射、透過、第２バウンド反射です。おそらく、これは本当に高価なもので、各ローブのLTCルックアップをする必要があるでしょうか？あるいは、別のエリアライト近似を見つけなければならないかもしれませんし、点光源のソリューションに戻ってしまうかもしれません。しかし、繰り返しになりますが、多重散乱スペキュラーのように、髪の毛のための直感的な答えはないようです。もちろん、どんな助けももちろん大変ありがたいです！
Slide.123
しかし、もう一つ・・・この未解決の問題を覚えていますか？どのようにして我々の多散乱拡散を 球面調和関数に保存された間接照明に適用するのでしょうか？
Slide.124
我々は…またしても解決済みの問題にリンクしています…
クランプされたコサイン分布を球面調和関数に投影し、それを利用してSHに投影された照明を評価することができます。しかし、我々が求めているのは、任意のBRDF（この場合は多散乱拡散BRDF）を球面調和関数に投影することです。
Slide.125
しかし、たまたま、線形変換された余弦から、BRDFを近似することができるクランプされた余弦分布への写像ができたのです。これを使って問題を解決することができるかもしれません。
Slide.126
エリアライトの場合は、光源の座標を取り、LTCの逆行列を使って回転させます。SHバンドをエリア光源のように扱い、LTC逆行列を使って回転させ、コサインローブで評価します。そして最後に、エリアライトにLTCを使うときと同じようにBRDFの大きさで拡大縮小します。
Slide.127
しかし、SHは回転不変なので、実際にはコサインローブを回転させることができます。
Slide.128
シェーダコードの例です。SH も行列 R で法線の空間に回転させているので、コサインローブを上に向けて回転させていることに注意してください。つまり、このコードをさらに最適化することができるということです。
それでは、いくつかの結果を見てみましょう。
Slide.129
これらの写真のために照明の設定を少し変えてみました。これは夜明けに、スカイライティングだけで撮影したものです。右手に太陽が昇ろうとしているのがわかりますが、その方向の空はきれいなピンク色をしています。
今、私たちは私たちのマルチ散乱間接拡散をオンにすると…
Slide.130
ラフな左手側の球体の上に平坦な照明を得ますが、球体が右に向かってスムースになると、視野角を見るためのより強いフォールオフを見ることができます。多重散乱直接拡散で見たように、地上面も少し暗くなっています。
グランドトゥルースと比較してみましょう。
Slide.131
これは本当に近い！実際には、我々が見る唯一の本当の違いは、球体の底部がグランドトゥルースにたいして明るくなっていることですが、我々はランバートを比較するならば、我々は実際に同じことを見るでしょう – これはSHのリンギングによって引き起こされています。
グランドトゥルースにアスタリスクを付けたのは、このような状況での絶対的な真実の主張にはいつも少し警戒しているからです。我々は、半球上のSHをサンプリングし、BRDFでスケーリングすることにより、これを生成しました。
近似を見ることにに戻りましょう …
Slide.132
だから、これは素晴らしいことですが、あなたがそれらの行列の乗算と正規直交基底の構築があまりにも多くの時間がかかるかもしれないと感じる場合には… もっと安い方法があります SHを全く回転させずに、BRDFの大きさでスケールします。比較してみましょう。
Slide.133
そのため、色は移りますが、全体の強度は変わりません。これはかなり極端な例ですが、SHでも照明が違うので、一般的にはそれほど問題にならないのかもしれません。しかし、マグニチュードによるスケーリングでは、滑らかな表面のちらっと見える視野角でのフォールオフを得ることができ、オブジェクトにより明確な定義を与えます。
これは、もう少し研究が必要ですが、私はこれが打ち破るための有望な道であることを願っています。
Slide.134
結論としては、今の状況を振り返ってみましょう。多重散乱拡散とスペキュラ、そしてエリアライトを実装しました BRDFは、直接照明、間接照明、エリア照明に対応しています。ラップドライティングはあらゆる状況で機能し、布用のエリア照明を実装しました。
Slide.135
しかし、悲しいかな、まだ次のような問題が残っています。現在のものは何も私たちの髪の毛のシェーディングでは動作しませんし、スキンの表面下散乱についても動作しません。少なくともスキンについては、分離可能なスクリーン空間部分散乱を使用する計画がありますが、髪の毛は間違いなく研究領域にあります。
Slide.136
ということで、旅も終盤に差し掛かってきました。多重散乱BRDFとエリアライトの最新の研究をゲームに取り入れてみましたが、最初に期待していたよりも少し複雑なものになってしまいました。しかし、この旅が、研究とゲーム制作の融合について一緒に学ぶことのできるいくつかの洞察を与えてくれたことを願っています。
Slide.137
1つ目は、ソースコードがかけがえのないものであるということです。Danny Chanの多重散乱拡散モデル用のシンプルなシェーダコードを持っていたことは、すぐに実装できたので、とても良かったです。また、LTCを使用したエリアライトのデモがあったので、ゲーム内でのエリアライトの動作バージョンをすぐに作ることができました。しかし、おそらくそれ以上に重要なのは、LTCのフィッティングコードがあったことです。
Slide.138
このことは、私たちを「結論 #2」（洞察力を実装から分離すること）にうまく導いてくれます。LTCの特徴は、エリアライトを使ったGGXのスペキュラの結果をリアルタイムで得られるということではありません。研究はその実装の詳細についてではありません。LTCを使ってどんなBRDFでも表現できるという洞察力を研究しているのです。私はその洞察をさらに利用して、球面調和関数による間接的な拡散を助けるためにLTCを使用しています。
これは、論文を書くときだけでなく、論文を読むときにも覚えておくといいと思います。私のチームのメンバーが、月のためのBRDFについての論文を実装したことを覚えています。その論文には太陽の光からのBRDFが含まれていましたが、空の光のモデルも提供していました。本当に、スカイライトモデルは、研究者がレンダリングしているイメージを完成させるために、ただそこにあっただけなのです。しかし、私の同僚は太陽モデルと空のモデルの両方を実装しました。さて、論文の中の真の洞察を見極め、周辺情報を忘れてしまうのがゲームの私たちの仕事ですが、時には研究者の仕事として、論文の中の重要な洞察が、恣意的な実装の詳細ではなく、何であるかを確認することもあります。
だからと言って、100％実装に関する論文ができないわけではありません。ある意味では、Fdez-Agueraの論文は、ある特定のケースでどうやって何かを動作させるかに焦点を当てた、素晴らしい例です。そして、ゲーム開発者として、私はこれらの論文が大好きです。*しかし*個人的には、このモデルを使用して、それをより多くのユースケースに拡張し、それが他の問題に提供する洞察を見ていました。
Slide.139
既存の作品の上に構築していたように思えます。Fdez-Agüeraが環境照明に対する多重散乱を見ていたように、Emmanuel Turquinが独自の多重散乱モデルを開発していたように。ある分野での研究が多ければ多いほど良いのです。研究が成功すれば、それをゲームで使う可能性が高いので、それはさらに重要なことです。そして、使用されているものをさらに推し進めるために研究を行うことは、本当に役立ちます。
環境マップBRDFという概念でさえ、何度も出てきています。それを利用して BRDFのエネルギーを与えられた方向に求めることができましたし，LTCのスケーリングにも非常に似た概念が使われていました。ゲームの中ではすでにこの技術の一部を持っているという事実は、それに基づいたさらなる論文の実装を容易にします。
ここにも注意の言葉があります。近い将来、私はエリアライトを使いたいので、BRDFの評価にLTCを使うことになりそうです。つまり、もしBRDFを実装するのであれば、ぜひともLTCで動作するようにしたいのですが、そうでなければ問題が生じます。成功している既存の仕事の上に構築するということは、すでに使われているものを理解し、それを使って研究を進めようとすることでもあります。あるいは、15年後にはLTCをやめてレイトレーシングの研究に戻ってくるかもしれないということを理解することです。
しかし、既存の仕事の上に構築することのもう一つのメリットは、その中にある問題を解決しているかもしれないということです。そして今日はたくさんの問題にぶつかりました。
Slide.140
実装時間を決して甘く見てはいけません。そして、それは私から来ているのですが、私は最初、新しいBRDFに加えてエリアライトをゲームに入れることの早さに本当に喜んでいました。そして、自分に足りないケースがたくさんあることに気がつきました。スキン、髪の毛、布。新しいBRDFは必ずしもエリアライトとうまく機能していなかったし、この２つの研究はかなり独立していたので、私はそれを統合しなければならなかったのです。まだまだやるべきことはたくさんあります – スキングレンダリングのための全く新しいテクニックを実装し、パフォーマンスを確認し、髪の毛のためのソリューションを発見する必要があります。
私はこれを多くの人に言っています – 私が一緒に仕事をしているアーティストやプロデューサー、ハードウェアメーカーから最新の機能を実装してほしいと言われている人、彼らの研究を実装してほしいと言われている学者、そして最新の機能をエンジンに搭載しようとしているグラフィックプログラマーなどです。あなたが思っている以上に時間がかかることがよくあります。確かに、最初の実装は簡単かもしれませんが、そんなに時間はかからないかもしれません。しかし、これは80:20のルールの一つだと思うのが好きです。私たちのエンジンは信じられないほど複雑で、機能がいつもうまく噛み合っているとは限らないので、最後の20%の作業には80%の時間がかかっています。
Slide.141
さて、旅の最後に短いエピローグの時間です。実際にゲーム内にエリアライトを入れて、使えるようにしてみたらどうなるのかな？そうですね、アーティストが使えるようにして、パフォーマンスを管理する方法を与えなければなりません。さらに、エリアライトを有効にしたり無効にしたりできる機能にすることも試してみたいと思いました。
Slide.142
それによって、次の2つの大きな目標ができました。私たちは、アーティストに光のフォールオフをコントロールできるようにしなければなりませんでした。また、エリアライトが無効になったときに、オムニやスポットライトにフォールバックできるようにすることも決めました。
Slide.143
まずはこれらのコントロールを見てパフォーマンスを上げていきましょう。既に持っている 2 つのファールオフコントロールがありますが、それをエリアライトに使用します。最初の最も重要なものは半径のフォールオフで、ライトから一定の距離を超えると何もレンダリングされないようにします。
Slide.144
SIGGRAPH 2013でBrian Karis氏が提案したこのウィンドウ機能を使って、それをやろうと思っています。\(d\)を光からの距離、\(r\)をその半径とすると、この関数は境界でゼロへの滑らかなフォールオフを与えます。
Slide.145
次はコーンフォールオフです。技術的には、片面クアッドライトの場合、光源の前の180度の平面全体に光をキャストする必要があります。しかし、これでは画面上のスペースがいっぱいになってしまうので、スポットライトと同じように範囲を制限したいのです。ファークライでは、スポットライトの内側と外側の円錐角をアーティストがコントロールできるようにしています。それがどのように機能するのかについては、ポイントライトに戻ってしまう解決策についてお話しするときに、もう少し詳しく説明します。
Slide.146
最後に、我々が使用する傾向がある別のフォールオフ関数は、逆二乗法距離で，それは距離で光強度を減少させます…
Slide.147
… しかし、エリアライトでは、これは半球上の光源の統合ですでに説明されています – 光が遠ざかるにつれて、ポリゴンの投影サイズが小さくなり、光の強度が減少します。つまり、これは上で説明した窓関数であるフォールオフ関数とは根本的に異なるものであり、これは光の統合自体の特性です。ですから、エリアライトの場合は無視しています。
Slide.148
パフォーマンスを適切にコントロールできるようになったので、ポイントライトへのフォールバックの話もできるようになりました。これはローエンドのプラットフォームのためのもので、エリアライトはハイエンドのためのものです。
Slide.149
私たちの場合は、同じ場所にあるスポットライトに置き換えて、内側と外側の角度、半径が同じになるようにしています。単純に同じ場所にある点状の光に置き換えただけで 同じフォールオフ特性（つまり半径、内角、外角）を持っていれば 光源付近の光が足りないことに すぐに気がつくでしょう しかし、これは、そもそもエリアライトのフォールオフとして内側と外側の円錐角を使用することの問題でもあります – 円錐はどこから来るのでしょうか？もし光源の中心にあるのであれば、本質的にはエリアライトを少なくとも光源の近くで点光源にすることになりますが、これは理想的ではありません。
（また、ここではクアッドライトの場合を中心にお話しますが、ディスクライトへの拡張は些細なことです。)
Slide.150
代わりに、我々は、エリアライト光源を包含する錐台の位置に光を戻して移動することができます。実際、エリアライトの影をどこに落とすかについて、これに似たアイデアがSIGGRAPH 2014 [Lagrade 14]でSebatien LagradeとCharles De Rousiersによって提案されました。そして、光源の後ろにある光の部分をカリングします。
Slide.151
これは、コーンの角度が落ちるためのコーンの頂点をどこに置くかを教えてくれるので、エリアライトが有効になっているときにも役立ちます。これは、同じ位置から同じ角度でフォールオフするので、2つが一致するのに本当に役立ちます。
これは、プロジェクターの距離を計算しなければならないことを意味します。円錐が出ているところから、光の後ろの方へプロジェクターと呼んでいるものを移動させるための距離です。
Slide.152
これは、外角と光源の直径を使ったかなり簡単な三角法です。
光の直径は、このように四角い光源の対角線の長さを使います。
Slide.153
そう、これはつまり、光が正方形であることから逸脱していくと、もっと悪くなる近似値だということです。これは楕円コーンをサポートすることで改善されるかもしれません。そして、これは言うまでもなく、四角いライトよりもディスクライトの方がはるかに良く動作します。しかし、ディスクライトであっても、楕円になることを考えると、理想的には楕円コーンのサポートが必要になります。
ここでは、異なるコーン角度のライトに対して、実際にどの程度フォールバックが優れているかを見てみましょう。
Slide.154
外角が100度と比較的狭いクアッドライトです。内角を90度にしており，外角に近いです。内側と外側を使用して光に任意の形を提供するために使用する必要はありませんので、かなり外角に近いですが、むしろちょうどソフトなフォールオフです。
Slide.155
これはスポットライトのフォールバックで、少し暗めの色になってしまいます。
Slide.156
120度のクアッドライトに戻りましょう。
Slide.157
繰り返しになりますが、フォールバックは非常に近いのですが、わずかに暗くなっており、フォールオフの形状の変化がより目に見えてわかります。
Slide.158
最後に、140度のライトを見てみましょう。
Slide.159
ここで変化が顕著に出てきます。フォールバックは、実はエッジに近い方が明るいのです。
これは予測通りとみることができます。スポットライトに関してコサイン角から来るのはフォールオフのみですが，クアッドライトについては与えられた角度において光源が見える度合いから来る”フォールオフ”を持ち、より多くの視射角を得ると見える度合いがより少なくなります。
しかし、全体的には、これらのフォールバックは非常に受け入れられています。実際には、ライティングアーティストの一人がエリアライトでは十分な違いが出ていないと苦情を言ったほどです。私はこの方法の勝利としてその苦情を取りました。
Slide.160
聴いてくださった皆さん、ありがとうございました。そして、どんな質問にも喜んでお答えします!
こんにちわ、Pocolです。
今回は予防線を先に張っておこうと思いまして，記事を投稿します。
頑張って執筆している書籍のタイトル名ですが、まだ正式タイトルが決まっていません。
一応仮で「基礎から学ぶ」というのが今現在入っていますが，基礎というのは全然優しくありません。
「簡単なんでしょ？」とか勘違いされている方がいると，「全然簡単じゃねぇ！」とか怒る人もいるかもしれませんので，予め言っておきます。『簡単じゃないです。』
「基礎から」と言ってるだけで「簡単である」とは書かないように気を付けています。
「基礎＝簡単」と思っている方がいらしたら，それは大いなる間違いです。
今回の執筆の書籍は，かなりガチ目な路線を狙いました。勿論，「基礎から」と仮題がついているので基本から説明するように心がけましたが，残念ながら執筆者の技量もあるため，読んだ人全員に理解できるものは提供できないのではないかと考えています。
ここ大事なので，もう一回言います『読んだ人全員に理解できるものではないかもしれません。』
勿論，星1がつくのは覚悟です（寧ろ、昨今だと星1が付かない方があからさまにオカシイような気さえします）。
万人受けする書籍ではありませんが，なるべく受け入れられるように努力はしました。
クソだと言ってもらうには一向に構いません。
それよりも，この書籍が役に立ったと1人でも言ってくださる方がいらっしゃったら，自分はそちらの意見の方が大変ありがたいです。
もともと救えないと思っていたものが，救える。それだけで本を書いた価値があります。
わからないものが分かったとか，ふーんと思っていたことがちゃんと納得できるようになったとかのご意見・ご感想があれば，今後の励みになります。
特に欲しい意見としては，「〇〇〇までは分かったが×××は…という理由で，全く理解できなかった。難しすぎる」とか「〇〇〇の説明がイメージつかなくて，わからないとか」とか今後につながる具体的にわからなかった理由や改善点というがあれば是非頂戴したいです。
「この本クソ！」みたいな意見は既に分かりきった当たり前の内容でして，なんの改善にもつながりません。どのレベルに合わせて書くべきかなどの修正方針にもつながりませんし，そもそも万人受けできるように努力はしていますが，それを目標とはしていませんし、当然問答無用に「クソ！」などいう人は分かりきっていまして，わからない人も多かれ少なけれいるだろうと目算していますので，単なるdisりは承知の上でして何にもなりません。出来ればどこがクソなのか理由を書いていただけるだけでもありがたいです。「こうしろ！」という意見を持ったdisりの方が改善につながりますので，具体的にどこがダメなのか？どうすると良くなるのか？なぜそう思うのか？などの生の声が頂戴したいです。
何の理由もなく「クソ！」という人は一定数いるようですので理由がないものに対しては，こちらで改善が図れません。先ほども述べましたとおりに「具体的にどこがダメなのか？」できれば「こうするともっと良くなる」という意見がありましたら，是非頂きたいです。
…というわけで先に予防線を張っておきました。
出来れば購入する際も，本当は書店などで立ち読みして本当に、本当に買うべきもの値するかどうかをきちんと判断していただいた上でご購入頂きたいです。
立ち読み等でご自分の目でご確認いただいてから，購入していただくのが確実かと思います。
きちんと自分が望むものと一致しているかどうかをご判断頂いてから，ご購入頂きたいです。
もう一度言いますが，専門書ですので，万人受けする書籍の類ではございません。
ネット等で様々なご意見があると思いますが，ご自分の目でこれは買うべきなのか？買わないべきなのかをきちんと確認した上で，後悔が無いようにご購入いただくのを強く推奨いたします。
そのためには，書店等で実物を見ていただいた上で買うのが最善であり，これを強く強く推奨いたします。
こんにちわ，Pocolです。
最近、最適化の話とかを見るのがちょっとハマっています。
NVIDIAがthread-group ID swizzlingという最適化テクニックについての記事を投稿しています。
L2キャッシュを再利用できるようにアクセスパターンを変えることにより最適化を行うテクニックのようです。
2Dフルスクリーンのコンピュートシェーダを用いるものに重要となるテクニックだそうで，ポストプロセスやスクリーンスペース系の技法を実装する際には重宝しそうです。
上記のテクニックはGDC 2019で紹介されているもので，バトルフィールド5ではRTX 2080(1440p)で0.75msの改善があったと報告されています(SetStablePowerState(TRUE)での動作だそうです）。
また，GDC 2019で紹介したソースコードにバグがあり，X方向（N）に起動するスレッドグループの数の倍数である場合にのみ動作するものだったそうです。
修正したソースコードについても提示がされています。
上記の記事のHLSLコードが実際動くのか，コピってみて試したのがだめでした。
NVIDIAのWebページの方では，いくつかHTMLの変換ミスがあるっぽくてアスタリスク(*)が無くなったりしていて，そのままコピペしてもビルドエラーになるので注意してください。
そこで，D3D11で動くように実装を修正してみました。下記のような感じです。
// スレッドサイズ.
#define THREAD_SIZE (8)
// Shader Model 5系かどうか?
#define IS_SM5 (1)
///////////////////////////////////////////////////////////////////////////////
// ColorFilterParam structure
///////////////////////////////////////////////////////////////////////////////
cbuffer CbColorFilter : register(b0)
{
uint2 DipsatchArgs : packoffset(c0); // Dispatch()メソッドに渡した引数.
float4x4 ColorMatrix : packoffset(c1); // カラー変換行列.
};
//-----------------------------------------------------------------------------
// Resources.
//-----------------------------------------------------------------------------
Texture2D<float4> Input : register(t0);
RWTexture2D<float4> Output : register(u0);
//-----------------------------------------------------------------------------
//! @brief スレッドグループのタイリングを行う.
//!
//! @param[in] dispatchGridDim Dipatch(X, Y, Z)で渡した(X, Y)の値.
//! @param[in] groupId グループID
//! @param[in] groupTheradId グループスレッドID.
//! @return スレッドIDを返却する.
//-----------------------------------------------------------------------------
uint2 CalcSwizzledThreaId(uint2 dispatchDim, uint2 groupId, uint2 groupThreadId)
{
// "CTA" (Cooperative Thread Array) == Thread Group in DirectX terminology
const uint2 CTA_Dim = uint2(THREAD_SIZE, THREAD_SIZE);
const uint N = 16; // 16 スレッドグループで起動.
// 1タイル内のスレッドグループの総数.
uint number_of_CTAs_in_a_perfect_tile = N * (dispatchDim.y);
// 考えうる完全なタイルの数.
uint number_of_perfect_tiles = dispatchDim.x / N;
// 完全なタイルにおけるスレッドグループの総数.
uint total_CTAs_in_all_perfect_tiles = number_of_perfect_tiles * N * dispatchDim.y - 1;
uint threadGroupIDFlattened = dispatchDim.x * groupId.y + groupId.x;
// 現在のスレッドグループからタイルIDへのマッピング.
uint tile_ID_of_current_CTA = threadGroupIDFlattened / number_of_CTAs_in_a_perfect_tile;
uint local_CTA_ID_within_current_tile = threadGroupIDFlattened % number_of_CTAs_in_a_perfect_tile;
uint local_CTA_ID_y_within_current_tile = local_CTA_ID_within_current_tile / N;
uint local_CTA_ID_x_within_current_tile = local_CTA_ID_within_current_tile % N;
if (total_CTAs_in_all_perfect_tiles < threadGroupIDFlattened)
{
// 最後のタイルに不完全な次元があり、最後のタイルからのCTAが起動された場合にのみ実行されるパス.
uint x_dimension_of_last_tile = dispatchDim.x % N;
#if IS_SM5
// SM5.0だとコンパイルエラーになるので対策.
if (x_dimension_of_last_tile > 0)
{
local_CTA_ID_y_within_current_tile = local_CTA_ID_within_current_tile / x_dimension_of_last_tile;
local_CTA_ID_x_within_current_tile = local_CTA_ID_within_current_tile % x_dimension_of_last_tile;
}
#else
local_CTA_ID_y_within_current_tile = local_CTA_ID_within_current_tile / x_dimension_of_last_tile;
local_CTA_ID_x_within_current_tile = local_CTA_ID_within_current_tile % x_dimension_of_last_tile;
#endif
}
uint swizzledThreadGroupIDFlattened = tile_ID_of_current_CTA * N
+ local_CTA_ID_y_within_current_tile * dispatchDim.x
+ local_CTA_ID_x_within_current_tile;
uint2 swizzledThreadGroupID;
swizzledThreadGroupID.y = swizzledThreadGroupIDFlattened / dispatchDim.x;
swizzledThreadGroupID.x = swizzledThreadGroupIDFlattened % dispatchDim.x;
uint2 swizzledThreadID;
swizzledThreadID.x = CTA_Dim.x * swizzledThreadGroupID.x + groupThreadId.x;
swizzledThreadID.y = CTA_Dim.y * swizzledThreadGroupID.y + groupThreadId.y;
return swizzledThreadID;
}
//-----------------------------------------------------------------------------
// メインエントリーポイントです.
//-----------------------------------------------------------------------------
[numthreads(THREAD_SIZE, THREAD_SIZE, 1)]
void main
(
uint3 groupId : SV_GroupID,
uint3 groupThreadId : SV_GroupThreadID
)
{
uint2 id = CalcSwizzledThreaId(DipsatchArgs, groupId.xy, groupThreadId.xy);
Output[id] = mul(ColorMatrix, Input[id]);
}
基本的には，いったんフラットなID（つまり通し番号）にして，そこから再算出するみたいな計算しているみたいです。
cpp側は下記のような感じです。
// カラーフィルタ実行.
{
auto x = (m_TextureWidth + m_ThreadCountX - 1) / m_ThreadCountX; // m_ThreadCountX = THREAD_SIZE. シェーダリフレクションで取得.
auto y = (m_TextureHeight + m_ThreadCountY - 1) / m_ThreadCountY; // m_ThreadCountY = THREAD_SIZE. シェーダリフレクションで取得.
auto pCB = m_CB.GetBuffer();
CbColorFilter res = {};
res.ThreadX = x;
res.ThreadY = y;
res.ColorMatrix = asdx::Matrix::CreateIdentity();
m_pDeviceContext->UpdateSubresource(pCB, 0, nullptr, &res, 0, 0);
auto pSRV = m_Texture.GetSRV();
auto pUAV = m_ComputeUAV.GetPtr();
m_CS.Bind(m_pDeviceContext.GetPtr());
m_pDeviceContext->CSSetConstantBuffers(0, 1, &pCB);
m_pDeviceContext->CSSetShaderResources(0, 1, &pSRV);
m_pDeviceContext->CSSetUnorderedAccessViews(0, 1, &pUAV, nullptr);
m_pDeviceContext->Dispatch(x, y, 1);
ID3D11ShaderResourceView* pNullSRV[1] = {};
ID3D11UnorderedAccessView* pNullUAV[1] = {};
m_pDeviceContext->CSSetShaderResources(0, 1, pNullSRV);
m_pDeviceContext->CSSetUnorderedAccessViews(0, 1, pNullUAV, nullptr);
m_CS.UnBind(m_pDeviceContext.GetPtr());
}
たまに触らなくなると，すぐに忘れるので思い出せるようにメモしておきます。
前提として
// コンピュートシェーダ側.
[numthreads(dimX, dimY, dimZ)]
void main(...)
{
...
}
// cpp側 pCmdList->Dispatch(A, B, C);
としておく。
グループが A * B * C 出来上がる
例えば，Dispatch(3, 2, 1)とした場合は， 3 * 2 * 1 = 6個のグループになる。
(0, 0, 0), (1, 0, 0), (2, 0, 0)
(1, 1, 0), (1, 1, 0), (2, 1, 0)
という感じ。
上記のuint3型6つのものがSV_GroupIDとなる。
コンピュートシェーダでは，これらのグループごとにスレッドが生成される。
つまり，dimX * dimY * dimZ のグループスレッドができあがある。
例えば，[numthreads(2, 2, 1)]とした場合は，
(0, 0, 0), (1, 0, 0)
(0, 1, 0), (1, 1, 0)
と4つのグループスレッドが出来上がある。
上記のuint3型4つのものがSV_GroupThreadIDとなる。
一番細かい単位は，実行するスレッド。つまりディスパッチされたスレッドで
グループIDとグループスレッドIDから決まるので24個のディスパッチスレッドIDが生成される。
例えば，
a : [0, A)
b : [0, B)
c : [0, C)
の半開区間を用いて、SV_GroupIDを(a, b, c)として表し，
x : [0, dimX)
y : [0, dimY)
z : [0, dimZ)
の半開区間を用いて，SV_GroupThreadIDを(x, y, z)として表したとする。
このとき，SV_DispatchThreadIDはuint3型であり、そのIDは
(a, b, c) * (dimX, dimY, dimZ) + (x, y, z) で表される。
グループ番号は，SV_GroupThreadIDとnumthredsから算出され
SV_GroupIndex = x + (A) * y + (A * B) * z;
で求まる。
例えば，
[numthreads(2, 2, 1)]とした場合は0～3までの4グループ
[numthreads(10, 8, 3)]とした場合は0～239までの240グループ
となる。
Microsoftのドキュメントに図が載っているので，以上を踏まえて読むと分かるはず。
https://docs.microsoft.com/ja-jp/windows/win32/direct3dhlsl/sv-dispatchthreadid
こんにちわ、Pocolです。
先日お伝えしたVisual Studioとの格闘についに勝ちました。
そんなわけで，DirectX ShaderCompiler用のカスタムビルドルールをGithubの方に公開しました(https://github.com/ProjectAsura/dxc_rule)
これで，GUIでポチポチしながらVisual Studioのみで完結して作業をすることが出来ます。
Githubにアップされている3ファイルが必要になります。これをプロジェクトファイルと同じディレクトリに配置してください。
まずは，ソリューションエクスプローラーから「ビルドの依存順序」>「ビルドのカスタマイズ」を選択し，「既存ファイルの検索」を選択し，dxc.targetsを指定します。これで，カスタムビルドルールが適用されるようになります。
あとは，HLSLファイルを作成し，ソリューションエクスプローラー上から右クリックで「プロパティ」を選択します。
先ほど設定した，dxc.targetsによって「DXCコンパイラ」が選択できるようになります。
あとは，お好みでプロパティを設定してみてください。一応大体純正のやつ同じ感じにしています。
出力ファイルの項目にRootSignature出力やシェーダリフレクション出力を追加しています。
欲しかったメッシュシェーダ(Mesh Shader)や増幅シェーダ(Amplification Shader)も対応しています。
これで快適なメッシュシェーダプログラミングが楽しめるはずです！
そんなわけで，今回はカスタムビルドルールについて紹介しました。では ノシ
久しぶりホームページを更新するために，サンプルプログラムを作っているのですが…
あれ？Visual Studio 2019で設定できなくね？
…と思ったので，DXC用のカスタムビルドターゲットを作ることにしました。
とりえあず，UI構築ぐらいまではザックリやりました。
ここまで、順調。
で，いざビルドしようとさせてみたら…何かコンパイルが走っていない。
何故だ？（まぁ設定がオカシイのですが，どこがオカシイのか分からな過ぎて見当がつかんのです）。
こういうVisual Studioを拡張するとか魔改造する的なブログ記事が日本語だと全然ヒットしないんですよね～。
皆お行儀よくVisual Studioを使っているということなのかしら。
そんなわけで苦戦中です。メッシュシェーダのビルドが走るのはいつになることやら…。
まぁ、batに逃げる手もあるのですが，何か負けた気がするのでもうちょい粘ってみます。
一応、https://ventspace.wordpress.com/2019/03/08/fully-featured-custom-build-targets-in-visual-c/を参考にして対応進めています。
より良い参考ページとかがあれば是非教えてください。
※追記
どうやら下記のMSBuildのリファレンスを参考に実装すると良さそう。
https://docs.microsoft.com/ja-jp/visualstudio/msbuild/msbuild-reference?view=vs-2019