2006年4月13日(木) 23:32
MLTすげえ
Indigo forumより.
http://www.flipcode.dxbug.com/board.php?topic=269
透明マテリアルでレンズをモデリングして、
適当なカメラ＆スクリーンを作ってみるというテストが行われている。
MLTは一度レンズを通るパスを見つけられれば
その後は摂動＆レンズ変異でレンダリングを続けられるので
それなりに面白い絵が取れるようだ。
ついにToycamをレンダラで再現する時代になったのか。
http://www.flipcode.dxbug.com/board.php?topic=269
透明マテリアルでレンズをモデリングして、
適当なカメラ＆スクリーンを作ってみるというテストが行われている。
MLTは一度レンズを通るパスを見つけられれば
その後は摂動＆レンズ変異でレンダリングを続けられるので
それなりに面白い絵が取れるようだ。
ついにToycamをレンダラで再現する時代になったのか。
written by nikq [/program] [この記事のURL] [コメントを書く] [コメント(4)]
Comments
TrackBacks
nikq::cube
『タイトルなし』
nikq さんこんにちは。
>MLTは一度レンズを通るパスを見つけられれば
>その後は摂動＆レンズ変異でレンダリングを続けられるので
>それなりに面白い絵が取れるようだ。
なのですが、とはいえ普通に実装しちゃうと lens path で staking しまくりなのがなやましいところです。。。MLT をやるとどうしてもリンク先のように輝点がでてしまうのですが、これくらいならポストプロセスのメディアンフィルタで十分消せそうですかね。
written by syoyo
『staking』
おお syoyo大先生だ
lucilleのコードは非常に勉強になります。ありがとうございます。
実際に物理レンズのシミュレートをしようと思ったら
最後のレンズパス部分だけ特別扱いするべきなのでしょう。
erptの論文でもポストフィルタについて触れられてましたね。
積分アルゴリズムだけで解決できないなら、
フィルタでの解決もアリなんでしょうか。
…少し寂しさを感じてしまいますけど。
いつかカールツァイスがCG用にレンズデータを
提供する時代になるのでしょうか。
written by nikq
『タイトルなし』
ソースコードは、pbrt の方が参考になると思います。私も pbrt の前身の lrt を参考にしましたから...
フィルタで解決が今のところ現実的な解だと思います。erpt も unbiased を謳っておきながら、結局フィルタリングや chain の経験的な打ち切りに頼っていますからね... 真に unbiased で clean で efficient なレンダリングアルゴリズムというのはまだまだ研究の余地があると思います。
written by syoyo
『pbrt』
PBRTはAdvanced GIと一緒に先日注文してきました。
今まで持ってなかったあたり、俺のやる気のなさがうかがえます。
ごめんなさい。買いました。届いたら読みます。
CPUの数にefficient、という方向性とかもアリですかね。
N cpuだとN^2倍くらい効率化するようなアルゴリズムとか。
あるといいなぁ。
written by nikq