日曜研究室 LLVMによるプログラミング言語の実装 xv6ソースコードリーディング 技術 日記
日曜研究室

日曜研究室

まだ庭の小石の数を数え終わっていない

技術

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

投稿日
2013/4/26 金曜日
カテゴリー
技術
タグ
著者
Take it easy!

一様グリッドに放射束を蓄積する方法を諦めて、別の方法を実装してみた。
前回、普通にフォトンマップにkd木を使う方法+αに戻すと書いてたけど、思うところがあってそれとも微妙に違う方法にしてみた。

フォトン追跡中はテクセル単位で放射束を蓄積→追跡後テクセルをkd木に登録→そのkd木と八分木を利用した放射照度キャッシング法で放射照度を推定、という流れ。
IC_P10m_n500_116sec一千万フォトン、近傍500フォトンで推定、処理時間2分弱
放射照度の推定をシーン空間で行うので、テクスチャの継ぎ目は目立たなくなった。

見れる画になるようパラメータを選んで計算してるのでこんな感じだけど、実はまだ2点ほど問題がある。
やはりテクセル単位で放射束の蓄積を行ってるのでポリゴン毎のテクセル密度の違いによる収束スピードの差が依然として存在するのがひとつ。
一千万フォトンでこのレベルならあまり問題無いような気もしなくはないが、100万フォトンとかに減らすとテクセル密度の違うポリゴンであきらかに明るさに違いが出る。

もうひとつは、多分これは実装ミスだと思うけど、キャッシュを利用した推定の精度が悪く、キャッシュの効果範囲を広げると油絵のようになるというか、画像編集ソフトのぼかしブラシでなぞったような感じになってしまう。
上の絵ではキャッシュの利用率を82%ぐらいにしてて、つまり18%ぐらいのテクセルは真面目にkd木を近傍探索して放射照度を推定してるからこの程度で済んでるけど、これをキャッシュの利用率を95%ぐらいにするとかなりやばい見た目になる。
上の絵でも直接光が当たってる部分の縁にその片鱗が多少現れている。
たいして複雑なシーンじゃないので、例えば10×10=100テクセルにひとつキャッシュがある程度（キャッシュ利用率99%程度）でも、全体的にぼやけた感じにはなるだろうが、本来ならそれなりに見れる絵になるはず。

八分木はサクっと自力で実装したものではあるが、テストを行ったので多分問題ないはず。
多分、推定の実装に問題があるんじゃなかろうか。
その部分は数式をみただけで感じたままに実装したので。

コードもごちゃごちゃしてきたし、色々見なおそう。

しかし放射照度キャッシングの効果は絶大だなぁ。
まだ本領を発揮できてない状態だと思うけどそれでも全部近傍探索するより圧倒的に速い。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です



※画像をクリックして別の画像を表示

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。