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

フォトンを飛ばすのを休憩中に，某L的なものを適当に作ってみました．ダウンロードはこちらです．左ボタンドラッグで円を動かせます．右クリックで初期化します．スペースキーを押すと以下のような物体のシミュレーションができます．

剛体のような何か


ひものような何か


水のような何か


ゼリーのような何か


泡のような何か


ある時点までは，結構真面目に方程式を解いていたのですが，安定しなさすぎるので適当物理に切り替えました．謎パラメータが多すぎるので使い物にはならないと思いますが，粒子ベースの方法なのでそれなりに動いているようには見えます．まあ，真面目に解いても謎パラメータが多いのは変わりませんけど…

全体としては一つのソルバーなので，全部混ぜることも可能です．剛体が複数に分かれないのは単なる手抜きです（つまらないので，そのうち直すかも（10/07/10：直しました．破壊とかも可能））．手法的には複数の既存の方法の組み合わせで，シミュレーション自体は3次元で動作しています．中身に興味があればメールでもください（BBSには書き込めません）．気が向いたらGPUで実装してみようかな．

adaptive samplingはunbiasedか

関連した話なので連続で書きますが，一般的にadaptive samplingはbiasedです．さらに言えば，adaptive samplingの各ステップがunbiasedなので全体としてもunbiasedだぜ！という議論は間違いの可能性がかなりあります．例えば，関数を半分に分けて，前のステップでサンプリングした値に比例してサンプル数を分配するアルゴリズムを使うとします．ここで，サンプルは適切に重み付けして，各ステップではunbiasedにサンプリングするとします．一見するとunbiasedになりそうです．

ところが，こんな単純な方法でもunbiasedになるとは言えません．例えば，一番初めのステップが何らかのimportance samplingをしていて，どちらか片方をサンプルする可能性が高いとします．そうすると，次のステップでのサンプルは片方に偏ります．これの「一番初めと次」の組み合わせを繰り返して得られたサンプルの分布はadaptive samplingの方法によって任意に変わるので，アルゴリズム全体としてunbiasedと言えるかは非常に怪しくなります．ただし，adaptationを途中で止める場合は，その後のサンプルだけを使えばunbiasedになります．計算統計のadaptive importance samplingで使われているのはこの方法です（もしくは，各ステップを別々の関数からのサンプルとしてもunbiasedになります)．

要は，最初から最後までのサンプルを全部使おうとすると，サンプルの間に依存性があるので，unbiasedかどうかは怪しいよという話です．実のところ，consistentかどうかも微妙になる場合があるので，「各ステップがunbiasedだから全体もunbiased」という議論は話半分に受け取った方がよいと思います．

まあ前の話と同様，実用上はあまり関係ないんですが．

「unbiased」のbiasedな使い方

世の中には「unbiased = 正しい」という考えが蔓延していますが，これは完全に間違いです．unbiasedというのは，手法の単なる統計的性質の一つにすぎません．また，unbiased, biasedと勘違いしがちな概念としてconsistent, inconsistentという性質があります．で，これらの概念はそれぞれ独立に成り立つのでは，という考え方はどうもあまり見られないようなので，ここでちょっと書いておきます．

さいころの目の平均値を計算する場合，それぞれの例は以下のようになります．

• biasedかつinconsistent：出た目の和/振った数 + 0.00001
• biasedかつconsistent：出た目の和/(振った数 + 0.00001)
• unbiasedかつinconsistent：最初に出た目
• unbiasedかつconsistent：出た目の和/振った数

ompfでは既に述べましたが，GPUSPPMを更新しました．



質問が結構来ていた，フルスペクトルなレンダリングとぼけた反射の例を追加しました．古いバージョンもまだダウンロードできます． RGBとスペクトルの相互変換はガウス分布で近似したものを使っているので，XYZなどの曲線のテーブルが必要なくなります． 最適化のコードを書いてなるべくエラーが小さくなるように近似したので，RGBとスペクトルの相互変換コードは他にも役に立つかもしれません． ガウス分布と最大値・最小値へのクランプで近似していますが，どうもフィッティングをうまくやればクランプは必要なさそうなので，そのうちこっそり差し替えるかも．

GLSLは各社のコンパイラの挙動が違いすぎてヤバイということにようやく気がつきました．JITコンパイラをベンダに任せるのは駄目なんじゃないだろうか． HLSLみたいにコンパイラ部分は標準で提供して，もっと低レベル部分を各ベンダに任せるほうがいいのでは？少なくともHLSLではGLSLほどヤバイ違いには直面したことがありません． まだ使ったことないですが，DirectComputeも同じ仕組みだと思います．OpenCL大丈夫か？

full-spectral renderingは空気感が出る，もしくは光を波として扱うなどと思った・書いたことがある人は，パストレーシングで点光源のコースティクスをレンダリングする刑に処します．

言いだしっぺの法則により，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先生のコードと同じ環境でコンパイルできます．