lucille 開発日記

レイ経路の測度と経路積分

測度と確率 からの続きで、 メトロポリス光輸送(MLT)を始めとしてパストレーシング、双方向パストレーシングの基礎となる経路積分式とその定式化のためのレイ経路の測度を見ていきたいと思います。より詳しいことは Eric Veach の博士論文の 11 章(MLT部分)を参照してください。

最終的に示したいのは、画像のピクセル色(放射輝度)というのは、以下の経路積分式(path integration formulation)で表現できるということです。

I_{j} は j 番目のピクセル色(放射輝度)、x はレイの経路(path)、f_{j}(x) は測定寄与関数(measurement contribution function)で、レイ経路 x がピクセル j にどれくらい寄与するか(実際にはレイ経路 x がピクセル j を通る場合のみ非ゼロで、それ以外のピクセルではゼロになる)を表す関数、Ω はすべてのレイ経路の集合(レイが取りうる経路のすべての組み合わせ)、u(x) はレイ経路 x の測度(面積の直積測度)になります。

つまりはこの式が示したいことは、ピクセル j の色というのは、いろいろなレイ経路 x の内、 ピクセル j に飛び込んでくるレイの和であるということです。

この定式化により、MLT などのレンダリングアルゴリズムの導出が容易になります(というか導出しやすいためにこの式の形に持ってきている)。

f_{j}(x) は、

とすることができます。 h_{j} はピクセル j のフィルタ関数(x が ピクセル j を通る時のみ非ゼロで、それ以外はゼロになるような関数)であり、f は画像のピクセル全体に渡って一定の値の測定寄与関数です(つまりはレイの放射輝度)。f は画像平面を通らない場合はゼロになります。

レイ経路の測度

上記の積分を考える上で重要になる、積分区間 Ωと 積分測度 u() について見ていきたいと思います。

まず、Ωk を、長さ(跳ね返り回数)が k のレイ経路 x

x = x0 x1 ... xk

が取りうるすべての集合(組み合わせ)とします。k >= 1 です(k=0 だとレイが点になってしまうので)。
たとえば、 k = 3 の時のレイ経路の一例を挙げると以下のようになります。

簡便のために各サーフェスで 1 つの点のみにしていますが、実際には各サーフェスには無数の点が存在します。

図では x0x1x2x3 を結んだものを例として示しています。

この図の例で、レイの経路 x (k = 3)は、

(x0, x1, x2, x3)
(x0, x1, x3, x2)
(x0, x2, x1, x3)
(x0, x2, x3, x1)
(x0, x3, x1, x2)
(x0, x3, x2, x1)

の 6 通りの組み合わせがあります(以下 x0 は視点として固定して考えます)。

ここで、測度 u_{k} (レイ経路の長さが k の時のレイ経路の"面積"に相当するもの)をこの経路に対して定義します。

D はΩk の部分集合(つまりいくつかのレイ経路のまとまり)、dA(x) はサーフェス上の点 x での微小面積になります。

この式が意味する事は、レイ経路の束 D をレイ経路の面積とすると、それはレイ経路の各頂点の微小面積を掛けた(直積を取った)ものの積分だということです。数学的にはこれは直積測度(product measure)と呼ばれるものになり、いくつか重要な性質があるようです。

式の右辺の積分の中をまとめて、これを du_{k} にすることができます。

これはつまりレイ経路の微小面積として捉えることができます。

この u_{k}, du_{k}, D の関係は、以下の図による 2 次元での面積の定義を見てもらうと分りやすいと思います。

dx, dy が x 方向と y 方向の微小の長さ、 du(x, y) = dxdy が微小面積、 u(D) が求めたい領域 D (薄いブルーの部分)の面積になります。これをレイ経路の定義と照らし合わせて対応づけて見てください。

経路空間

Ωk を元に、すべての任意の長さのレイ経路が取りうる集合である経路空間(path space) Ω を定義します。Ωは単純に各 Ωk の集合の和になります。

定義では k = ∞ までですが、実際には有限の長さ(10 とか 20ぐらい)で打ち切るのが相場だと思います。

上述のレイ経路の図を参考にして、4 つの頂点(x0x1x2x3) が k =1, 2, 3 の時に構成される Ω と Ωk を図示すると以下のようになります。

(x0 は視点として考えるので固定です)。

ここでΩk のどの状態も一意(重なり合うレイ経路の組がない)であることが確認できます。これによりレイ経路を測度で論ずることができることが確認でき、 よって ΩがΩk の和で定義できること(重なりが無いので和をとっても重複部分が生じない)の確認にもなります。

最終的に、 経路空間の測度 u は以下のように定義できます。

つまり u(D) は、各長さが k の時にD が含まれる部分の集合(D ∩ Ωk)の測度の総和になります。D に含まれるレイ経路の集合のどれもが長さ k のレイを持たない場合は、 D ∩ Ωk はゼロになります。

一例を図示すと以下のようになります。

結局のところ、 レイ経路の測度というのは、各レイ経路の頂点の微小面積の積であり、u() はそれをすべての経路の長さにおいて統一して一つの関数で表現したものということになります。

そしてこの u を用いる事で、最初に提示した式、

という形の積分を定義することができるようになります。

実際のプログラムの実装ではこの測度 u というがそれほど重要に用いられることはありませんが、レンダリングアルゴリズムの理論を導出する上では非常に重要な要素になります。

次回は測定寄与関数 f について見ていきたいと思います。

light mapping

vray 1.5 で搭載されるという light-mapping(ライトマッピング) が面白そうなので、ちょこっと更新。

http://vray.info/newsread.asp?ID=81

いわゆるフォトンマップ以前の、フォトンマップの基礎となったライトマッピング(ライトからレイトレーシングを行う手法)とは異なる手法で、視点からのレイトレーシングになります。

視点からのレイの各跳ね返りでは、照明値をフォトンマップのように三次元空間データ構造に保存するようで、視点からフォトンを放出するフォトンマップと言えますね。

ライトマッピングの利点は、

o フォトンマップでは、ライトが複数ある場合、それぞれでフォトンの放出をセットアップしなければならないが、ライトマッピングでは視点からのみなので単純
o ライトマッピングでは、自己発光体、非物理的ライト、スカイライトなどのどの種類のライトでも扱える。それに対して、フォトンマッピングでは、再生成(reproduce)可能な照明効果のみしか扱えない(たとえば、自乗減衰しない点光源は扱えない)
o ライトマップはシーンのカドや小さな物体の周りの照明も正しく扱える。それに大して、フォトンマップは密度推定(density estimation)などの手法が必要になるが、これはときどき間違った結果になる。
o 多くの場合、ライトマッピングは直接に可視化できる(directly visualized)(つまりファイナルギャザーを必要としない!?)

サンプル画像を見る限り、ライトマッピングは非常によい結果が見受けられます。
またスピードもフォトンマッピングと同等で、かつアニメーションにも容易に適用できるとの事。

視点からのトレース時に、どのように照明値を計算するのかは分かりませんが、ある意味視点からのインポータインスフォトンマッピングのようなものになるのでしょうか?
コースティクスもきれいに表現できるのでしょうか?

もしコースティクスがうまく表現できないとしても、コースティクスはフォトンマップで行い、
そのほかの間接照明効果ではライトマッピングを用いるということができるでしょう。

多くの場合では、ライトマッピングは直接に可視化できるらしいので、間接照明の表現にグローバルフォトンマップで必要となるファイナルギャザーがいらないというのは大きなアドバンテージな気がします。

メトロポリス光輸送とも組み合わせることができたりするかな。

とまあフォトンマップに比べてこれでもかってくらいアドバンテージが述べられています。

個人的にはフォトンマップ本でメトロポリス光輸送がけっこうボロクソに書かれていて悲しかったので(近年のラージステップ MLT 法の提案などで、結構フォトンマップ本で書かれている欠点の多くはすでに解消されていると思います)、ポストフォトンマップとなるレンダリングアルゴリズムを支持したいところですね。

パストレーシング実装

MLT のパストレーシング部分を書き直して、独立してシンプルなパストレーシングを実装してみました。双方向パストレーシングの実装に向けての布石です。

pathtrace.c

上のレンダリング画像は、768x768 ピクセル、ピクセルあたり 1024 サンプルです。ポストプロセスとしてガウスフィルタを少し。

SIS とか EIHDRI とか QMC とか使わずに MC での力技なのでノイズが多いです。

コースティクスをうまく見せるために屈折はちょっとずるしてたりします。

ガラスの質感、うまくでていません。フレネル反射とかちゃんとやらないとダメですね。

ちなみに、シーンの参考にした元ネタは、 Kevin Beason 先生のレンダラ pane のレンダリング画像。

http://www.csit.fsu.edu/~beason/pane/