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

日曜研究室

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

技術

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

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

現在こんな感じ。
CB2_P10m_n400-0.5一千万フォトン。近傍最大400フォトン、処理時間は199秒。

フォトンマップにkd木を利用せず（最終的に放射照度を推定するときはkd木を利用するんだけど）、フォトン追跡中は八分木に情報を格納するようにした。
八分木を使うことで「現在のフォトンの衝突点からある一定距離にある既存の衝突点を検索し、もしそんな点が存在すればそれに情報を追加していく」という処理がまぁまぁ効率的に行える。
そうすることで衝突点データの増大を防ぐことができ、メモリにやさしくなる。
また、テクスチャ等の幾何形状に依存したデータ構造ではないので、ポリゴンの継ぎ目やテクセル密度の違いも表面化しない。

八分木に格納した衝突点には、放射束を追加していくだけで、格納回数をカウントしたり、表面積を狭めていったりはしていないが、これもPPMと呼べるのかな？定義がはっきり分からないのでなんとも。

今のところ放射照度推定段階でめっちゃボカすことによりこのクオリティを実現してるが、そのせいで処理スピードが落ちてる。
が、フォトンマップに八分木を使った事による処理速度の低下は思ったほど全体には影響しなかった。
もちろん八分木をどのくらいの深さにするか、衝突点をどのくらいの面積と見なすか等によって違いはあるけど。

あと、ボカすことで間接照明はいい感じに滑らかになってるが、直接照明も滲んでしまっててちょっとかっこ悪い。
処理スピードの問題と合わせてなんとか解決したい。

以下は、同じ設定による別のシーンの結果。
CB_P10m_n400-0.5
TB_P10m_n400-0.5
どちらも200秒前後。

上はやはり、光源や手前の箱の影に直接照明のボケによる問題が見える。
下は、今回の方法による問題点よりも利点が目立ってる。
緑の球の滑らかさは以前のものと比べると段違いだ。
（これはベイクしたテクスチャを貼りつけたモデルをリアルタイムレンダリングした画像だが、かなり近づくとやはりポリゴンの継ぎ目はうっすら見える。）

とにかく直接照明のボケの問題と処理速度の問題をなんとかしたい。

コメントを残す

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



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

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