[Diary]
[Log]
[Projects]
[Articles]
[Parthenon]
[BBS]
[Profile]
[Mail]

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

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先生のコードと同じ環境でコンパイルできます．