前回フォトンマッピング法の実装に成功したが、直接照明も間接照明もすべてフォトンの情報を直接可視化することで表現してたので、ノイズが目立っていた。
何の工夫もしてないモンテカルロ法の宿命として、ノイズを半分に減らすにはサンプル数を4倍にしなければならないというものがあるが、1億フォトンを飛ばして30分かけて計算してもノイズが残るなど、まさにその宿命が顕になった。
続きを読む
前回フォトンマッピング法の実装に成功したが、直接照明も間接照明もすべてフォトンの情報を直接可視化することで表現してたので、ノイズが目立っていた。
何の工夫もしてないモンテカルロ法の宿命として、ノイズを半分に減らすにはサンプル数を4倍にしなければならないというものがあるが、1億フォトンを飛ばして30分かけて計算してもノイズが残るなど、まさにその宿命が顕になった。
続きを読む
前回に引き続きまたもやフォトンの反射率の計算や反射後の出力の計算、放射輝度推定の方法を変更した。
というのも前回参考にした方法でももう少し頑張ればまともな絵が出せそうな気はしてたが、それ以前に処理速度の低下が激しかったので内心やばいなと思ってた。
続きを読む
現時点でこんな感じ。
総フォトン数は10万、推定に使ったフォトン数は各80個。
続きを読む
ベイク処理を実装した。
上の画像が出力されたテクスチャ。
下の画像がそのテクスチャをモデルに貼りつけたもの。
総フォトン数1万、放射輝度推定に用いたフォトンは各テクセル100個ずつ。
なんだか鉛筆の下書きに絵の具で色を塗ったように見える。
エッジが鉛筆で書いたように見えるのは多分テクスチャの隙間のせいだから、ベイクのときにその隙間を埋めるような処理を追加すれば解決するかも。
絵の具っぽく見えるのは、多分トーンマッピングの処理がテキトーなせい。
続きを読む
OpenGLに慣れてれば簡単だと思うけど、慣れてないと難しいと思う。
この辺はやはりCUDAとかのGPGPU用のAPIに比べると、必要な手続きが多過ぎる感がある。
1から作る場合はCUDAの方が明らかに楽だけど、ターゲット環境の問題とかでCUDAを選択出来ないときや、すでにOpenGLを使ってるアプリに組み込むときOpenGLでGPGPUをやるのもいいと思う。
続きを読む
シーンにばら蒔いたフォトンを元にシーン内のある点の放射輝度推定を行うとき、レイトレースがよく用いられると思う。
カメラからスクリーンの画素の方向へレイを飛ばし、そのレイがぶつかった物体表面に関して放射輝度推定を行うのだ。
続きを読む
フォトンマップ(kd木)を実装した。
動作確認として、カメラから画面中心に向かってレイを飛ばし、物体とぶつかった地点pからいちばん近いフォトンTOP10をkd木を使って検索し、pから各フォトンの位置に線を引くようにしてみた。
線の色はフォトンの色に対応。
いつもの如くリアルタイムでグリグリ動くけど、画面録画がキビしいので静止画だけ。
前回と比べ見栄え的には後退したけれど、実装的には大きな一歩となった。
続きを読む
最近のコメント
名前
しゅごい
Jane Doe
FYI Avoid Annoying Unexpe…
Jane Doe
ご存じとは思いますが、whileには、”~の間”と…
peta_okechan
針金みたいなパーツを引っ張ると外れます。 他の方の…
虎徹ファン交換
虎徹の標準ファンを外す際に、どのようにして外されま…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…
花粉症対策2019 – 日曜研究室
[…] 花粉症対策についてはこれまで次の記事を書いてきました。https://…