little things of mine

遅ればせながら”Inception”を観てきました． Inception 日本でもとっくに公開しているので，みなさんもうご覧になったでしょうね．自分はなぜかタイミングを失って今まで観てませんでした．さて． 面白かった！ 久しぶりにストーリーに引き込まれる映画でした．正直言って，話が複雑な上に慣れない単語が多く，英語のままだとイマイチ理解できない細部がたくさんあったのですが，大筋は理解しました．最後がちょっと良く解らなかったのですが．．．（敢えて書かないでおきます） VFXも素晴らしかったですねー．Double Negativeだそうですが，パリのシーケンスなんか最高でした．クリーチャーやメカを作るのではなく，これぞVFX！という感じの仕事でしたね．ああいうプロジェクトに参加してみたいものです． 色々な記事を読むと，かなりの部分が実際のセットを使って撮影されたそうですが，無重力シーンとか，ホントに良くできてましたねえ．格闘する場面はワイヤーで吊るされてるんでしょうか？だとしたら，その状態であんな動きができるのだろうか？あと，グリーンバックもほとんど使われなかったそうです．rotoの人達メチャ頑張ったんでしょうね． 以下のリンクはCGではなく，セットのお話． fxguide – vfx knowledge – Inception 日本語字幕付きでもう一度復習したいです．

長い事気になっていた「CG Magic:レンダリング」をようやく読みました． cgmagic.net 結論から言いますと，素晴らしい本です！ “The Landscape of Computer Graphics Technology”という副題が付けられているのですが，これがまさにその通りで，部分発生的に発展したCG技術群を，同じ土俵に並べて俯瞰的に観察し，体系的に学ぶ事ができるようになっています． 最初，著者であられる倉地さんの某雑誌での連載をまとめたものだろうとタカをくくっていたのですが，実はかなり加筆されているようです．全体をテーマに沿ってまとめ直しもされています． 特に第一部の，BRDFから始まり，GI，volume renderingを経てsubsurface scatteringに至るまでの過程が本当にスバラシイ．「光とは何か？」「レンダリングとは何か？」という基礎であり本質の部分をキッチリと説明されていて，しかも理論本にありがちな理論だけで終わってしまうような事はせず，それがどのように使われたかという実践部分にまでちゃんと触れられています．これがある事で理解の度合いが桁違いに深まります．読み進んで行くうちに点と点が繋がっていくあの感じです． ただし，これはやはり技術書なので，誰にでも簡単に読める物ではないと思います．きちんと理解するには最低限の数学及び物理の知識（高校くらい？）は要求されますし，ある程度のセンスも必要でしょう．それでも自分は皆に勧めます．いつもは論文の表紙でしか名前を見ないような人達が何を考え，どんな問題を解決しようとしてきたのか，大げさに言えば彼らの奮闘の歴史を知るだけでも楽しいです．ええ，オタクな視点ですけど（笑）． 個人的な予想ですが，これから先，シェーディング及びライティングはより物理的というかもっと本質的な考え方を元にデザインされるようになるだろうと思っています．それが一般化してツールに標準搭載になった時，ユーザにもある程度その仕組みの理解が求められるようになるでしょう．その時に力となるのはやはり基礎となる学問的な知識であり，ツールのボタンの押し方ではありません．ツールは理論を元に作られています．画家が絵の具や筆の性質を知っているように，我々もツールの裏にある理論を多少なりとも知るべきです． 今回はテーマをレンダリングに絞って書かれていますが，今後は違う分野，例えばシミュレーション編とかも是非出して欲しいですね． 英語版も出るそうです．これもスバラシイ！ このような本が日本から出版された事を嬉しく思います．

SIGGRAPH2010開催中のホットニュース． Alembic こちらでtaikomatsuさんが和訳されています． Alembic – memlog AlembicはILMとSPIが共同で開発及び公開した，アニメーションをシーケンシャルジオメトリにbakeするためのC++ライブラリです．”alembic”という単語には浄化器，蒸留器という意味があるそうで，必要な物だけを抽出する，というようなニュアンスですね． ライティングやエフェクトはアニメーションされたシーンを元にして作業するのが普通なのですが，アニメーターがアニメートしたままの状態だと，リグやその他たくさんのアニメーション以外には必要のないデータも含んでいるし，何しろリグを毎回プロセスするのは色んな作業の邪魔になります．エフェクトなんかはそうでなくても重い作業が多いですからね．シーンも不安定になります．そもそもツールが別でリグが渡らない事も多い．そのため，ある程度の規模のスタジオでは，内部で特定のデータフォーマットを使ってbakeしたアニメーションをやり取りする事が多いのですが，Alembicはそのデータフォーマットとして使う事ができます． シーケンシャルジオメトリのデータフォーマットは，今までこれといった決めてがなくて各スタジオがそれぞれ試行錯誤していると思います．GTOもかなり良さそうに思っていたのですが，AlembicはILMが絡んでいる事からして，GTOを更に改良した物（GTOは元々ILMで使われていた）と考えていいのかも？だとするとこれは良い候補になりそう． ただ，こう言ったプロセスは，ある程度のパイプラインがあって，開発サポートが期待でき，大きなシーンやショット数をこなす必要がある場合に必要になる事だと思うので，規模の小さな場合は逆に手間になってしまう可能性もあると思います．あと，日本の某社の方に教えられたのですが，小さい所ではストレージとネットワークがネックになってしまうとも言っておられました． 今の所，ライブラリの使用例としてMayaのimporter/exporterプラグイン，PRManのprocedural primitive DSO，GTOからのコマンドラインコンバータ，その他ユーティリティがライブラリと一緒に公開されているようです．Pythonバインディングも一応あるようですが，これはまだまだこれからという雰囲気． Houdiniのプラグインもないが，これは自前でやれという事か．

“IRON MAN 2″を観てきました． Iron Man 2 | Trailer & Official Movie Site | Now Playing んー．なんと言いましょうか．正直に言いましょうか． 「つまんなかった」 映像は良かったのですが，ストーリーのダルさが映像を楽しむのを邪魔してる感じ，と言えばいいかな．普通，逆な事が多いと思うんですけど．1の方がキレがあって断然良かったと思います． VFXはメインがILMとDouble Negative．その他に結構な数のスタジオが参加していました．そのせいかも知れませんが，出来に少々バラツキがあったように感じました．コンプの甘いショットも結構あった．バトルシーンは物量増えたにも関わらず，流石にクオリティ高かったです．恐らくはメインの二社によるものでしょう． 最後の終わり方からすると，3もありそうですね．

twitterで話題になっていたので，まとめようと思います． この話は突き詰めると，Reyesとレイトレという根本的なレンダリングアルゴリズムの違いに帰着するのですが，まあここではPRManとmentalrayという事にしておきます．あと，最初に言っておくとV-Rayやその他最近のレイトレレンダラは色々と進歩していて，ここで書いている事は必ずしも正しくない場合もあると思いますが，基礎してとらえて下さい． マイクロポリゴンというのは，何か特別なポリゴンを指す訳ではなく，そのサイズが大まかにピクセルと同じかそれよりも小さいサイズの物をそう呼ぶ事が多いようです．そういう意味では，PRManとmentalrayのそれは違いがありません．強いて言えば，PRManのマイクロポリゴンはquad，mentalrayのはtriangleという事くらいです． さて，ではどこに大きな違いがあるのかというと，まずその生成のされ方に違いがあります． PRManはbucket毎に処理を行い，NURBSでもポリゴンでも，全ての種類のジオメトリをbucketのサイズに近いサイズまで一度分割します．これをsplit processと呼びます．その後，スクリーンに入っているかどうかの判定をして，もし入っているようなら，今度はsplitされたジオメトリを更にマイクロポリゴンまで分割します．これをdice processと呼びます． この時点ではまだ各マイクロポリゴンはバラバラではなく，メッシュ状態を保っていて，マイクログリッドと呼ばれる事もあります．なぜメッシュである必要があるのかというと，PRManではこの後にDisplacement shaderが実行され，各マイクロポリゴンの頂点が移動する可能性があるからです．メッシュでなければ，動かした所が割れてしまいます． 次に各マイクロポリゴン毎にSurface shaderを実行し，シェーディングします．PRManのマイクロポリゴンはシェーディングされるジオメトリの最小単位です．一つのマイクロポリゴンは一色にflat shadingされます．この後にメッシュはバラバラにされ，各マイクロポリゴンの前後判定と，どのピクセルに含まれるかを調べます．これが1 bucket毎に起こる処理の（大まかな）内容です． 一方，mentalrayは（scanlineモードもあったりしますが）基本レイトレーサですから，ポリゴン分割はレイとの交差判定が起こる前に終わっている必要があります．そして，その分割処理はオブジェクト単位で行われます．PRManのようにbucket毎に分割はしません．しかし，最近のmentalrayには分割処理の方法にfine approximationというモードがあり，PRMan「みたいな」処理をします．つまり，元のジオメトリをある程度の大きさに分割（PRManでいうsplit）し，更にそのサブジオメトリを再分割します（同 dicing）．この場合，サブジオメトリは個別のbounding boxを持つので，レイが交差判定しようと試みたサブジオメトリだけを再分割すればよく，オブジェクト全体を割るよりは効率的になります．結果，分割数を上げる事ができるので，fineなディティールも出せるというわけですね． 分割の後，Displacement shaderが実行されるのはPRManと同じですが，Surface shaderは各ポリゴン毎に実行されるわけではなく，純粋にカメラレイが当たった交点で実行されます（実はこの違いはReyesとレイトレのそれぞれを象徴する重要な要素なのですが，その話はそれだけで長くなりそうなので，またいずれ）． 余談ですが，mentalrayには他にも，面のcurvatureを基準にしたり，視線との角度を基準にしたりと様々な分割モードがあって，ユーザがその場に応じて使い分けられるようになっています．設定次第ではピクセルサイズまで分割する事もできます．ただ，adaptiveな分割はうまく動かないケースが結構あったりして頻繁に変更しなければならないし，一番の問題はアニメーションの途中で分割のされ方が変わってしまうため，フレーム毎にシェーディングの結果が違う場合があるのです．これが理由で自分はadaptiveな分割はほとんど使った事がありません． さて，一次レイ（カメラレイ）に関してはこんな感じなのですが，二次レイ（反射や屈折，GIレイなど）になるとまた色々と面倒な話になります． PRMan方式は基本的にレイトレと相性がよくありません．カメラからのレンダに関してはピクセルという明確な区分領域があるのでうまく動くのですが，レイは数学的に「線」ですから，領域がありません．つまり，ピクセルのサイズという大前提が崩れるのです．bucket毎に処理単位を分ける事もできません．今でこそPRManでも普通にレイトレが使えますが，マイクロポリゴンをそのままトレースする訳にもゆかず，様々なhackでどうにか形にしている感じです． これは予想ですが，PRManでは二次レイが当たったジオメトリはピクセルサイズまでは分割していないと思います．もっと荒いはずです．これはテクスチャを張ったオブジェクトを鏡に映してみるとわかります．結構像がボケます．以前は二次レイから見たジオメトリの大きさを推量するためにconeを使っていると聞きましたが，今ならray differentials的な何かを使っているのではないでしょうか． この点，mentalrayは基本がレイトレーサですから，別に二次レイが飛ぼうがなんだろうか，基本的には何も変わりありません．せいぜい，たくさんのレイがオブジェクトに当たりまくって，大量のポリゴンを保持するために多くのメモリを必要とするくらいです．メモリが必要なのはPRManも同じですからね． と言うことで，一口にマイクロポリゴンと言ってもその使われ方には大きな違いがあります．displacementのディティールという意味ではあまり違いがないように感じるかもしれませんが，ディティールの善し悪しは分割数だけではなく，ジオメトリをどのようにサンプルするかが非常に重要なので，ポリゴンのサイズだけでは語れません．今のところ，displacementのディティールはmentalrayでピクセルサイズまで割っても，まだPRManに分があるように思います． このテの話は色んな方面からツッコミが来そうで怖いのですが，とりあえずこれにて．