フォトンベイカー（仮）進捗その4

フォトンに色の情報を持たせた。

まだフォトンマップ（kd木）は実装してないので、レイトレースして放射輝度推定を行った結果ではもちろんなくて、昨日書いた脱線方式に似た方法で描いたもの。

具体的には、フォトンが持ってる色情報をそのまま利用して（といっても各色成分が1.0以下に収まるようにスケールしてる）、透明度を0.5固定にして glBlendFunc(GL_SRC_ALPHA, GL_ONE) でライティング無しのシーンにリアルタイムでブレンドしている。
いわゆる簡易的な確認方法なので、この画がみられるのも今のうちだけかも。

しかしこういう簡易的な方法でも色伝搬が確認出来てちょっと感動。
特に箱の側面はそれっぽい。

この脱線方式でもフォトン数を増やしたら精度が上がるんじゃないかと思って1000万フォトンで試してみたけど、確かにノイズは減ったけど簡易的な手法なもんでトーンマッピングとかやってないから明るくなりすぎてしまった。

フォトン数1000万、トレース時間140秒ぐらい

贅沢で無駄の多いメモリの使い方をしているものだから、1000万フォトンの場合でメモリ使用量が1GBを超えてしまったw
もう少し省メモリを心がけよう。

フォトンがポリゴンにぶつかったときに、その位置のテクスチャの色をサンプルする処理を今回実装して追加したけど、思ったほど処理速度の低下がなくてよかった。
具体的にはフォトン数10万の場合でフォトンのトレース処理に掛かった時間は以下のとおり。（数回実行して平均を取った）

テクスチャサンプル無し 1.54秒
テクスチャサンプル有り 1.60秒

これがあまりにも遅かったら、CPUじゃなくてテクスチャサンプルが得意なGPUで処理するようにしなければいけないなぁなんて思ってたけど、大丈夫だったみたい。
GL_NEAREST相当の処理しか行ってないけど、最終的に放射輝度推定でぼかされる事を考えると、この部分のクオリティを上げてもあまり意味がないと思う。
ちなみに、↑の処理時間が昨日投稿したときと違うのは、反射率の値を色の値に連動させるようにしたため。
反射率が低ければ反射回数も減るためトレースにかかる時間も減る。その逆もしかり。

次の予定はフォトンマップ（kd木）の実装だけど、その前にベイク機能をどう実現するか考えたい。
その結果によっては、レイトレース処理を実装せずに、一足とびに目的であるベイク処理を実装するかもしれない。
ベイクしてしまえばリアルタイムレンダリングで確認出来るから、確認のためにレイトレース処理を実装する必要はない。
といっても勉強のために実装したい気もするし、後々役立ちそうな気もするし、どっちに転ぶかは今のところ半々といったところ。