[Diary]
[Log]
[Projects]
[Articles]
[Parthenon]
[BBS(R/O)]
[Profile]
[Mail]

言いだしっぺの法則により，GPUでStochastic Progressive Photon Mappingを実装しました．



テストはRadeon HD 2400 Proで行いましたが，G80以降（GeForce8XXX）かR600（Radeon HD 2XXX/3XXX)以降なら動作すると思います．ここで公開するデモでは初めてGLSLを使いましたが，コンパイラの挙動が怪しい以外は結構書きやすいですね．GPUでrange queryを実装するのに変なことをしているので，あまり効率が良くありません．実行にはGLUTが必要です．テストしていませんが，たぶんコンパイルすればUNIXでも動作すると思います．ソースコードが付いているので適当に遊んでもらえれば幸いです（で，バグがあったらこっそり教えてください）．

ompfにも既に投稿しましたが，smallptのProgressive Photon Mappingバージョンのsmallppm
というのを作りました．オリジナルのsmallptは72文字×99行で，smallppmは79文字×128行となっています．無論，文字を詰めればさらに行数は減らせますが，あんまり短くしても読みづらいだろうと言うのと，2^7行という事でこのサイズに落ち着きました．

コンパイルはsmallptと同じですが，実行時にはフォトンの照射数を指定する必要があります．
一応OpenMPも使用していますが，全然効率よくありません．ただompfの投稿を見るとわかりるとおり，omp criticalが無くても多分動きます（その場合は並列化効率がアップします）．10億フォトンほど使うと以下のような絵が出ます(Core Duo 1GHzで16時間．下の絵は1024x768をリサイズしています)．



アルゴリズム的には，ハッシュを使ったグリッドでrange queryを実装しています．あとQMCも使っています．このシーンは点光源からのコースティクスの反射を含んでいるので，unbiasedなレンダラではレンダリングできないか（Maxwellとか），凄く時間がかかるはずです．16時間どころではありません．コードは自由に使ってもらってかまいませんが，誰かGPUで実装してください（言いだしっぺの法則発動！）
7.16: ちょっと更新してトーンマッピングとかを入れたので少し違う絵が出ると思います．
8.30: さらにちょっと更新しました．
10.29: mokeheheさんのご指摘により，BRDFの1/PIかけ忘れと，normの破壊的操作による問題を修正しました．

囲碁AIではモンテカルロ法が流行っていたらしいので（今，流行っているかは知らない）
普段モンテカルロ法を使っている自分としては，是非試さないといけないと思って
リバーシを作りました．ただ，いわゆる「原始モンテカルロ法」なので弱すぎです．

download
UCTを実装しないと話にならないのだと思いますが，
この辺GIで使われている各種モンテカルロ法と比べると面白いです．
MCMCも適用可能だと思います(関数値がバイナリなのでほぼ適用する意味がありませんが)．

ところで「WinOSi的な何か(!= WinOSi)」とは実はProgressive Photon Mappingでした．
日付を見るとわかると思いますが，こっちに来る前からアイデアはほぼ固まっていたのに，
最終的に論文が出るまで凄い時間がかかってます．主な原因は僕の説明不足．

掲示板を何とかしたい．

追記：今の状態が弱い理由と，UCTの仕組みが大体わかったのでそのうち実装します．

最近(でもないけど)作ったやつ．

download
mono rayのGPU ray tracingです．GeForce 8800 GTXで30-40Mrays/sec出るはず．
pixel shader 3.0以上と浮動小数点数テクスチャのサポートが必要です．
あまり作る気ありませんが，packet raysだと2-3倍ぐらい出ると思います．
まだちょっと気に入らない点がありますが，まあデモという事で…
ラスタライズしているだけじゃねえの，と疑ってもらえたら幸いです．

あと，improved seam carvingのデモ(forward energyのみの変更)．
以前と同様にzxcvで縦横拡大縮小です．試したところ，確かに改善する場合もあるけど，
根本的にユーザーの入力が無いと上手くいかない場合が多いですね．

またParthenon更新しました．それだけ．

あ，あとコレ試してなかったらどうぞ．
zxcvで縦横拡大縮小です．例のseam carvingの実装です．Flashのソレと違って拡大もできます．
拡大は論文とは違う方法で実装したので，ちょっと品質が違うかもしれません．

最近やる気ない．

Parthenon更新しました．それだけ．

CGじゃないよ

redqueen rendering toolのページに面白いデータがあったので，
Maxwellと今弄ってる「何か」でレンダリングしてみました．

まずはMaxwellの結果（画像が反転しているのは座標系を間違えたため）．


次に「何か」の結果．


うーん，やっぱりMaxwellはLS+DS+Eが全然ダメなようです．
微妙に見えている結果は他のパス（LS+D+S+Eとか）でしょうか．
ちなみにレンダリング時間はPentiumM 2GHzでどちらも約30分の結果です．

「何か」で，一眠りできるぐらいの時間をかけるとこうなります．

どうも，社会に出る前から社会人失格のBeeです．

Maxwell Renderのデモ版が出たということで，早速いじめてみました（嫌なやつ）．
以前にもちょっと触ったことはありますが，その時は時間がなかったので…
Maxwell RenderはUnbiasedと銘打ってますので，簡単に思いつく「いじめ」は
LS+DS+E（例：ガラスを通して見えるコースティクス）のレンダリングです．

まずガラスが無いもの


上記のシーンで中央のオブジェクトをガラスに閉じ込めたもの


「あれ？何だうまくいってるじゃん」と思うかもしれませんが，
透明なガラスに閉じ込めたのに，不自然に暗くなっています．
これは，LS+DS+Eが上手くサンプリングできていないのでしょう．
(実際，そういったシーン向けにAGSというオブジェクト(?)を用意して対策しているようですし)

次に同じシーンで光源の大きさを小さくしてみました．



両側に妙な形状のコースティクスが出ていますが，これは正しい結果だと思われます．

一般にBidirectional系の手法では，コースティクスを発生する
光源が小さくなると，LS+DS+Eのパスはよりサンプリングしづらくなります．
Maxwellによるレンダリング結果でも，中央のオブジェクトについて
明るい点のノイズ(たぶんLS+DS+E)が無くなってしまっているので，
その傾向が現れているといえるかもしれません．

同じようなシーンを今弄っている「何か」でレンダリングすると，



となりました．これが間違っている可能性もありますが，
予想されるように，中央のオブジェクトの明るさはほぼ変わりませんし，
Maxwellで完全に消えていた，後ろの壁側のコースティクスも，
ガラスを通して見る事ができます(これもLS+DS+Eです)．

どちらにせよもう少し「いじめて」みる必要がありそうですね．

WinOSi的な何か(!= WinOSi)を弄り続けてます．



この方法はかなり時間をかけないと，どうしても微妙なノイズが残ってしまいます．
それを改善すべく色々試していますが，なかなか良い結果が得られません．
この辺で一度放置して他の何かを実装しようかな…

あ，kd-treeとgridの中間的なアレは一応新規性はありそうでした．
でもあまりメリットが無さそうです．うーむ．

ちなみにACMのアレは気が付いたら期日終わってました．最低 > 自分

お勉強のためにWinOSi的な何かのテスト．



stanford bunnyの中にstanford bunnyが入ってます．
MLTでも苦戦するパスのLS+DS+E（例：ガラス越しに見えるコースティクス）が
簡単に計算できますね．この方向性で何か作ろうかなぁ…

ちなみにWinOSiが正確にこの方法かどうかは知りません．
かなり推測が入っています．コードを読むの面倒だし．

kd-treeとgridの中間的なアレは識者に相談中．

次の更新でParthenonにこんな機能が付くかもね．



例のおいしそうなヤツの応用です．
別のアプローチでやろうと思って考え中ですが，
現状でそれっぽいのでいいかなと妥協気味．

他にも色々と試してみたいことが溜まってますが，
今は（というかここ数年ずっと），こればかりやるわけにも行かない状況です．
今年の後半は状況が変わっているといいなぁ…

ところで全く関係ない話ですが，将来どう生きようか迷ってます．
自分はプログラマにも研究者にも向いていない気がするのです．
そういうレールに乗り始めているというのに…

これまた全く関係ない話ですが，JOJOな感じのfさんとyさんには話しましたが
kd-treeとgridの中間的な，レイトレーシング向けの
空間分割手法がひらめいたので検討中です．
うまくいけば，grid並に構築が高速で，kd-tree並にtight fitな手法になる予定．
…でも誰か既にやっていて，失敗していそうな気がする．

この所，嫌なことが多かったので，気晴らしに趣味コーディングをしました．
Lefebvreらによる"Perfect Spatial Hashing"です．


(click to download：デモがダウンロードできます)

画像は左から，元データ，ハッシュされたデータのテーブル，
オフセットテーブル，ハッシュ関数を元に再構築したデータです．
データ領域の判定には，論文中で提案されている，Position Tagを使用しています．
非常に適当な実装ですが，ちゃんと完全なハッシュ関数が構築できています．
…と言ってもこのサンプルじゃ何がなんだかという感じですけど．

デモでは，マウスの左ボタンを押しつつ，
元データ，ハッシュされたデータのテーブル，オフセットテーブル上で動かすことで
それぞれを変更できます．例えばハッシュされたデータのテーブルを弄ると，



と構築後のデータが変化します（凄くわかりづらいです！）．
オフセットテーブルを弄るとハッシュ関数の衝突が起こるので
再構築後のデータが消えていくように見えます．

ハッシュの構築は元データを更新するごとにインタラクティブに行われるので，
元データを弄っているときに多少マウスの引っかかりが起こるときがあります．

三次元への拡張も非常に簡単そうなので，気が向いたらやってみます．

…あ，SBR2006で言っていた
"Ray Tracing Animated Scenes using Coherent Grid Traversal"のデモも
そのうちアップロードします．

色々疲れた





…Stam先生に許諾してもらってSIGGRAPH2005のポスターの手法の
基本的な実装例をアップロードしました．Stam先生のコードと同じ環境でコンパイルできます．