レイトレーサーのアーキテクチャについて

この節ではコードを書かない。現在の私たちは交差点に立っていて、アーキテクチャに関する決断を下さなければならない。混合密度を使ったアプローチを取ると、レイトレーシングでよく使われるシャドウレイが使えなくなる。一方で光源に限らずドアの下の明るい隙間や窓といった明るくなると思われる場所を自由にサンプルできるので、私はこのアプローチを気に入っている。しかし多くのレイトレーサーは処理を分け、ライトに向かう一つ以上の終端レイ (シャドウレイ) と物体表面の反射分布に従う一つのレイを生成する。シャドウレイを選択して収束の速さのためにシーンの柔軟性を犠牲にすることもできた。これは個人的な好みである。

これ以外にもコードに関して問題がいくつかある。

まず PDF の構築が ray_color() 関数にハードコードされている。クリーンアップすべきであり、ライトに関する情報を ray_color() 関数に引数として渡す方法が考えられる。BVH の構築と違ってサンプルの数に限りが無いので、PDF の構築ではメモリリークに気を付けなければならない。

次に鏡面反射レイ (を使うガラスと金属) はもはやサポートされない。散乱レイの PDF をデルタ関数とすれば数式上は上手く行くが、それを浮動小数点を使って実装すれば悪夢となる。鏡面反射を別にして処理することもできるし、表面の粗さは \(0\) にならないと決めて NaN が発生しない鏡面反射に非常に近い PDF を実装することもできる。私はどちらを選んでもよいと思っている (両方とも試したが、どちらにも利点があった)。ただ今までに滑らかな金属とガラスのコードを実装したので、ここでは f()/p() の計算を行わない完全鏡面マテリアルを追加する方法を取る。

さらに背景関数を扱う設計も欠いており、環境マップや複雑な機能を持つ背景を追加できない。環境マップは HDR となっている (RGB が \(0\) から \(255\) の整数で表され \(0\) から \(1\) の小数と解釈されるのではなく、最初から float で表される) 場合もある。なお出力はこれまでも HDR だった: 最後に切り捨てていただけである。

最後に、私たちのレンダラは RGB を使っているが、より物理ベースな ──自動車メーカーが使うような── レンダラでは、多くの場合スペクトルカラーが要求される。偏光さえ必要になる場合もある。映画用のレンダラでは RGB が必要だろう。両方のモードで動作するハイブリッドなレンダラを作ることもできるが、当然それは難しい。ここでは RGB のまま進み、本の終わりでもう一度この問題に触れる。