Syoyo Fujita's Blog

raytracing monte carlo

Month: March, 2005

休載

ゴゴゴゴ… ゴ… ゴゴゴゴ…. ゴゴゴ…. ゴゴ..
    ゴ. ゴゴゴ…. ゴゴゴ….  ゴゴ..  ゴゴ..
ゴゴ…. ゴゴ…. ゴ….. ゴゴ….      ゴ….

SBR 2005 設営のため、4/16 あたりまで、休載します。

ゴ…. ゴゴゴ…..     
ゴ…..       
ゴ…..      ゴ…..
        
ゴ…..                    
ゴ…..               
ゴ…..
                          
ゴ…..              
ゴ…..

Advertisements

cell computing & boinc

セル(グリッド)コンピューティングで分散レンダリングを行うという
プロジェクトが始まっています。

http://www.cellcomputing.net/simple/index.php

レンダラには Aqsis が用いられていますが、実のところ、
裏では lucille や某国産レンダラが候補に挙がっていたのは云うまでもありません。
(とはいえ、いずれまた aqsis を降格させて lucille が復権する
シナリオもなきにしもあらず、かもしれません)。

さて、ネットワークで分散レンダリングを行ううえで、
一番の問題となるのは、シーンファイルのサイズである。

たとえば、分散レンダリングで映画レベルの CG を
レンダリングするというのも可能ですが、その場合
ファイルサイズ(テクスチャやジオメトリ)がギガバイト級になってしまい、
ネットワークでのシーン転送のほうが実際の
レンダリング時間よりもかかってしまうということになります。
(フレーム間での差分を送ることで転送量を抑えることもありえますが、
cell computing βirth が用いている boinc フレームワークでは、
これを実現するのは難しいっぽいようです)

そのため、実際のプロダクションにおける
レンダーファームでは、計算能力だけでなく、
ファイルサーバなどのストレージ管理も重要な役割を
担っていると思います。

よって、分散処理においては、データ転送時間が、各クライアントノードでの
計算にくらべて少ないアプリケーションが適しています。

その点では、CG の分散レンダリングという
アプリケーションは、あまり分散処理には向かないのかもしれません。
(ちなみに CG レンダリングでは、入力と出力の比率が
1000:1 となっているようです。from Shrek 統計情報より)

とはいえ、実際に cell computing βirth のプロジェクトを実行してみると、
シーンなどの転送のほうがレンダリングに比べて
時間がかかっていますが、それなりにうまく動いているし、
まったりとクライアントを立ち上げているだけでいろいろと処理が進んで
いるので、シーン転送のほうが時間がかかっているなどの
細かい点は気にはなりませんでした。

というわけで、maxwell render のようなきれいな画像がでるのであれば、
レンダリング時間、転送時間がいくらかかってもいい、という人は
結構いそうな気がします。

ちなみに、バイオ系のアプリでは、データ量が少ないので
分散コンピューティングに向いているそうですが、
ペタフロップス級のコンピューティングパワーが必要との
ことらしいです。CG よりも計算パワーがいるのですね。

boinc

cell computing βirth で用いられているクライアントソフトは、
SETI@home でも使われている boinc と呼ばれる
分散処理フレームワークソフトウェアです。

http://boinc.berkeley.edu/

とりあえずローカルで boinc サーバを立ててみましたが、
ワークユニットを作るところらへんでちょっと挫折。
とはいえ、boinc の API は使いやすいとのことなので、
lucille も boinc に対応させて、分散レンダリングを試してみたいですね。

 

ところで、lucille は cell computing とも関連があるし、 
cell チップに対してももしかしたら初の大域照明レンダラ on cell、
というネタがなきにしもあらずかもしれないし、
結構いろんな cell と関連がありそうな気がしてきました。
(そういえばアレは完全体になったあとどうなったんだろ。読み返さないといけませんね)

GI チップ

さて、これからの CG LSI の世界において、
次の大きな波(そして最後の希望?)となるのは、
やはり GI(大域照明) チップであろう。

略して GPU(Global illumination Processing Unit)。

cell が GI チップ足りえるかと、理論値から逆算してみましたが、
GI レベルまでは、うーんリアルタイムではまだまだかなぁ、という感じである。
SaarCOR などでやっているような coherent のある
一次レイと一次シャドウレイだけであれば、
なんとかなりそうではあるが、
結局それって昔からあるレイトレチップとどう違うの? となりそうだし。
(ちなみに、それなりの品質(100 万三角形程度)のリアルタイムレイトレ(30fps)を行うには、
3Tflops 程度が必要とされるといわれている。from 「並列図形処理」。
純粋に考えると GI はそれの 10-100 倍はかかるので、30T から 300Tflops
というところでしょうか)

というわけで、GI チップはきっと来るのは確実でしょうが、
それをメリケン人より先に実現したいなぁと考える
のは自然なことです。でも、実際するとなるとそれはそれで、
いろいろやんなきゃいけないのよねー、きっと。
検証フェーズが大変そう…

pantalone, blender to lucille exporter

blender から lucille(RIB) へ変換する、python スクリプトを作成しました。

名前は pantalone。

http://lucille.atso-net.jp/wiki/index.php?Pantalone

モデラーは国産のものをサポートしたいという気持ちがあるのですが、
しかし、クロスプラットフォームでフリーを考えると、
現状では blender に旗が揚ります。
また python で拡張が書けるのもいいですね。
(数十万ポリゴンのデータを処理するとなると遅くて問題ですが)

ところで、Alias が FBX というクロスプラットフォームの
ファイルフォーマットをあつかう SDK や plug-in を無償で
公開し始めています。

http://www.alias.co.jp/products-services/fbx/

COLLADA のオフライン版という感じでしょうか。

メジャーなモデリングソフトおよび Mac OS X にも対応と、
かなり Alias は FBX を普及させる考えがありそうです。
FBX は、バイナリフォーマットのようです。
バイナリフォーマットの仕様は公開されているのかな?
(個人的には、ファイルフォーマットの扱いやすさは
行ベーステキスト > バイナリ > 階層ベーステキスト >>> XML
と感じています。まあ単にパーサを書きやすいという
のが一番の理由です。あと XML は無駄にパース処理がかかりそうだし、
サイズがでかくなりやすそう)

FBX から .rib(lucille) へのコンバータを書くのもありですが、
FBX を blender がサポートすれば、

モデラ -> FBX -> blender -> pantalone -> lucille

と、ほぼすべてのモデリングソフトから lucille への
変換パスが成立しそう。

しかし、まさかついに les quatre pionniers(レ・キャトル・ピオネール, 最古の四人)
の名前が現れることになろうとは…

空間データ構造テスト

久しぶりに、ちょこっと商用レンダラの空間データ構造のテストをしてみました。

ソフトウェア: 3ds max
レンダラ: brazil rio(フリー版), vray(フリー版), mental ray(3ds max 付属)

テストの内容は、すんげーでかい平面ポリゴン 1 つと、
ちょー小さいハイポリなティーポット(25 万三角形)が 4 つ密集しているシーンです。

つまり、普通に一様グリッドで空間分割したら、
あるひとつのグリッドセルに 100 万三角形が含まれてしまい、
総当り判定になってしまうという状況です。

結果、Brazil と mental ray では、レンダリングバケットがハイポリな
ティーポットの部分にフォーカスが当たったところで、とまってしまいました(十数分ほど
まで走らせてみた)。ただし、2, 3 回平面ポリゴンとティーポットのスケール比を
変えたら、うまくレンダリングできることもありましたので、単に
空間データ構造構築時の数値計算誤差的なものが原因なのかもしれません。

で、結局わかったことは、 vray は今回ちょろっとテストしたシーンすべて
でしっかりとレンダリングできていたこと。やっぱすげーよ、vray。
(とはいえ、空間データ構造のデプス設定がデフォルトでは60 程度ですが、
これを変えるテストを別途やったら、やはりとてつもなく時間がかかることもありました)。

ところで、vray では、空間データ構造は SDtree(static raycast accelerator)
という名前のもののようですが、これは BSP とは違うのかな?

量子レンダリング 2

さて、SIGGRAPH のコースで解説される量子レンダリングは、
以下の SPIE に採択された論文が元ネタのようです。

M. Lanzagorta and J. K. Uhlmann,
Multidimensional quantum data structures,
Proc. SPIE 5436, 45, April 2004.
http://vlsicad.eecs.umich.edu/Quantum/papers/

(pdf のタイトルでは quantum rendering となっているけど、いいのかな?)

本論文では、量子アルゴリズムのひとつである、
Grover の量子探索アルゴリズム


http://internet.watch.impress.co.jp/www/article/2000/0524/grover.htm

http://www.jsme.or.jp/publish/kaisi/010102t.pdf

をレンダリングアルゴリズムに用いることで、通常 O(N) のクエリ処理が
O(sqrt(N)) で行えることを示しています。

本論文では、Z-バッファ、レイトレ、ラジオシティ、LOD の
4 つの CG アルゴリズムに Grover の量子探索アルゴリズムが適用できる
ことを取り上げています。

たとえば、Z-バッファによるポリゴンレンダリングでは、
通常 N 個のポリゴンを描画する場合、ポリゴンが覆うピクセルが平均 p 個で
あるとすると、O(pN) の時間が古典的なコンピュータではかかりますが、
これが量子コンピュータと Grover のアルゴリズムを用いることで、
O(p sqrt(N)) の時間で処理できることになります。

レイトレの場合では、N 個の物体との交差判定が、
O(N) から O(sqrt(N)) で可能となるそうです。

とはいえ、実際のアプリでは、このような総当り的な処理は行われずに、
Z-バッファやレイトレでは BSP などの空間データ構造を使って、
理想的には O(logN) に比例する
時間で処理するようにしているのがほとんどですので、
量子アルゴリズムによる O(sqrt(N)) というのは、
オーダーの観点から見るとそれほどアドバンテージ
がない気がするかもしれません。

とはいえ、そもそも量子コンピュータは実現すれば
現在の古典的コンピュータの 1000 倍以上の性能にもなるそうですし、
BSP などのちまちましたテクニックを使わずとも、N 個の
クエリ処理が純粋に O(sqrt(N)) の
オーダーになることを考えると、やっぱり量子アルゴリズムはすごそうです。

そういえば、Shor の因数分解アルゴリズムなど、
いまあるもの以外に量子アルゴリズムを新たに発見すると、
ノーベル賞ものだとか…

量子レンダリング

SIGGRAPH 2005 のコースにて、
たぶん CG の世界では初となりそうな、量子レンダリングの解説が行なわれるようです。

Quantum Rendering: An Introduction to Quantum Computing and Quantum Algorithms, and Their Applications to Computer Graphics
http://www.siggraph.org/s2005/main.php?f=conference&p=courses&s=32

中身の理論がどのようなものになるのかは、実際にコースを受講しないと
分かりませんが、既存の Z バッファ法やレイトレの問題を解決するアルゴリズムに
なるようです。

それにしても、そろそろ量子レンダリングが出てくると思っていたら、
ホントに実際に出てきましたね。皆思いつくことは同じということか…

http://lucille.sourceforge.net/blog/archives/000065.html