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

日曜研究室

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

技術

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

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

ベイク処理を実装した。
上の画像が出力されたテクスチャ。
下の画像がそのテクスチャをモデルに貼りつけたもの。
総フォトン数1万、放射輝度推定に用いたフォトンは各テクセル100個ずつ。
p10k_n100_v100_t
p10k_n100_v100
なんだか鉛筆の下書きに絵の具で色を塗ったように見える。
エッジが鉛筆で書いたように見えるのは多分テクスチャの隙間のせいだから、ベイクのときにその隙間を埋めるような処理を追加すれば解決するかも。
絵の具っぽく見えるのは、多分トーンマッピングの処理がテキトーなせい。

放射輝度推定の結果を浮動小数点テクスチャに格納してるんだけど、それを画面に表示する際には0.0〜1.0に収めるためにトーンマッピングの処理が必要になる。
そのトーンマッピングの処理は、現状だと輝度0から最大輝度の間を100の区間に分割し、区間ごとのテクセル数を計算して、輝度の小さいグループから順番にテクセル数の割合に応じて0.0〜1.0に割り当てるという処理になってる。
そのせいで最終的な画における輝度の変化が必要以上に少なくなってしまいのっぺりとした見た目になってるんだと思う。
また、輝度の区間をまたぐ部分でマッハバンド的なものが現れてる。（単にフォトンマッピングでありがちな色むらだけじゃなく、縞模様みたいなものが見える。）

次の画像は、総フォトン数10万、放射輝度推定に用いたフォトン500個の場合のもの。
この画像だとマッハバンドがよく見える。
p100k_n500_v100

次の画像は、総フォトン数1千、放射輝度推定に用いたフォトン10個の場合のもの。
フォトンの少なさによる推定の誤差と、テキトーなトーンマッピングによるマッハバンドが悪い意味で相乗効果を起こして、結構ヤバい見た目になってる。
p1k_n10_v100

実は、フォトン数1万の場合で全ての処理に60秒ほど、10万の場合で5分ほどかかるようになってしまった。
しかもその処理時間の95%以上をベイク処理で費やしてる。
正確にはベイク処理の中の、フォトンマップの検索処理にほとんどの時間がかかってるみたい。
（アップした画像は512×512だけど、実際のベイク処理は1024×1024で行っている。）

フォトン数100万ぐらいまでは気軽に実行出来るようにしたいので、その辺の高速化を考えたい。
GPU向きとまでは言わないけど、並列処理に適したデータ構造にはなってるので、マルチスレッド化するだけで結構速くなるはず。
ただ、まずそこに手をつける前に工夫できるところがないか考えたい。

あと、トーンマッピングの処理もちゃんと実装しよう。

コメントを残す

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



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

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