Posted by ますお on Nov 8, 2006 – 11:43 pm
どうやら仕事でIBL担当になりました．
IBL担当ってなんだよって事ですが，要はHDRIがあるから，ちゃんとプロダクションでIBLが使えるようにしろって事みたいです．今までのは無視でイチから整備しろと．
とりあえずPRManでサポートされているenvironment mapのimportance samplingを試してみましたが，これがなかなか厳しい． プロダクションレベルのジオメトリで許容する品質にしようと思うと，時間がかかり過ぎてとても使えません．keyとfillが分けられないのも辛い．
つー事で，しょうがないから自前でどうにかしようと思います．目標は満足できる品質内での高速化と利便性です．いくつかアイディアはありますが，果たしてどこまで上手く行くか．
何はともあれ，まずはHDRIのサンプリングです．最近はIBLと無縁だったので，少しリサーチしてみましたが，今は便利なツールがあるんですねー．
LightGen Plugin
Light Map Gen
こういうの使ってもいいんですが，光源を別で生成しなきゃいけないのはパイプライン的によろしくない．変更も面倒になります．やっぱり光源のサンプルはon the flyでやってくれるのが理想なので，自前のlight shaderを書く事にします．
サンプリング方法は色々とあるようですが，やっぱりオラァな人がベタ褒めしてるこれとかでやってみましょうかね．
Recursive Wang Tiles for Real-Time Blue Noise
HDRIをcosine-lobeとspecular kernelでconvolutionしておく事も考えましたが，これもやはり変更が面倒な点でパイプラインに易しくないので，まずは全てレンダリング中に解決してしまう方法を試そうと思います．
久しぶりにまともなR&Dが出来そうで楽しみです．
Posted by ますお on Aug 7, 2006 – 3:17 pm
siggraphから帰ってきました．
Bostonはとても良い所でしたが，日中はかなり暑かった．さすがは東海岸．
今年は人が少なかったように感じましたが，もしかしたら会場が非常に広かったせいかも知れません．しかし会場の間取りがあまり良くなく，部屋の移動にとても時間がかかったり，出入口が判りづらい場所にあったりしてイマイチな感じでした．建物自体は新しいようで，設備等が充実していて良かったんですけどね．
カンファレンスはなかなか面白かったと思います．製作に関連のありそうな物を中心に聴いて周りましたので，以下に印象に残った物を列挙します．
[ Davy Jones ]
Pirates of the Caribbean2のタコ親父に関するプレゼンがいくつかありました．結論から言うとかなりの部分がアーティストの技量により達成されたとの事．まあそれでもstanfordと共同開発のシミュとか，最近のグラフィックカードでもローテーション出来ない程のヘビージオメトリとか，相当に注意深くマネージメントされたIBLとか，色々と驚きはありましたが．因みに全てのDavy Jonesとその手下(半人間な一人を除く)はやはり100% CGだそうです．これも驚き．
[ Fluid ]
今年はどちらかというと実際に現場で使われた話が多かったので，先端技術から段々とこなれてきたようです．中でもILMが”Poseidon”で製作したPoseidon号が沈没するシーケンスは圧巻でした．あと，一部では割と有名なScanlineというドイツのスタジオが製作したR&D demo reelがElectric Theatreに入っていました．コンプ無しのone-pass renderだそうです．スゲー．
[ Rhythm&Hues ]
R&Hは”The Chronicles of Narnia”で相当ステップアップした模様．たくさんの要素技術をこのプロジェクトで実装したようです．やはり実務ベースで作られた物は強いですね．それぞれの技術にはそれ程派手さが無いものの，全てが上手く調和して良い結果を出している印象でした．特にライオンのAslanはその集大成とも言うべき物です．
[ King Kong ]
Wetaも”King Kong”においてかなりの規模でR&Dしたようでした．特に凄かったのはKongのfacial animationで，人間のfacial motion captureをゴリラの顔にtransferする技術が他社の物と比較しても郡を抜いて良くできていました．残念ながら技術的な詳細は語られませんでしたが，Wetaの大事な差別化技術になると思われます．
また，1933年のNYCが建造されて行くシーケンスの解説もありました．モデルはGPSデータから3Dを起こすツールを開発，現代と1933年のギャップはハンドメイドで埋めたそうです．また，小さなビル群のモデルとテクスチャはproceduralに生成するシステムを開発したとの事．
[ CGIStudio++ ]
Blue Sky Studioのプレゼンで，謎だった彼らのレンダリングパイプラインに関する興味深い事実が色々と分かりました．BlueSkyのレンダリングシステムは現在CGIStudio++と呼ばれているそうですが，まず驚きなのがモデラーがモデルした全てのsubdivision surfaceは大量のbezier patchに変換される事です．以前にpatchを直にレンダリングするという話を書いた事がありますが，てっきりpatchでモデルするんだと思っていました．subdiから変換するってのは凄い．limit surfaceをbezierに変換できるって，どんなsubdivision schemeを使っているのでしょうねえ．もしくはある程度のエラーは許容しているのかも知れません．subdiから変換したpatchをcolorizeした絵を見せていましたが，凄い量のpatchでした．displacementに関してはbumpで代用，もしくはモデリングで対処しているらしい．
当然こういう事をするとまともにテクスチャを描くのが不可能になります．UVに依存するシェーダも殆ど使えません．で，彼らの出した結論は，「テクスチャマップをしない」でした．マテリアルとテクスチャは全てproceduralに生成し，surfaceにアタッチする代わりに，メタボールのようなガイドを使ってworld spaceでその影響範囲を指定する方法です．アサインされるモデルはアニメーションが付く前のinitial pauseで行われ，このモデルは恐らくリファレンスジオメトリとしても使われているはずです．ただ，機械のメータやロゴなど，どうしてもマップが必要な物もあるので，そういう物だけは普通にテクスチャマップが使用されているそうです．
非常にユニークなシステムですが，これはフォトリアルではない絵を作る事が前提のシステムでしょう．フォトリアルにするには大量のテクスチャがどうしても必要になります．しかしながらとても興味深い仕組みですね．技術的にはなんとなく想像が付きますが，それを実装してユーザ用のツールとパイプラインを構築し，きちんと成果を出している所がスバラシイ．
あと，彼らのfurはイマドキ(？)ながらvoxel furでraytraceableだそうです．スゲエ．
細かい物以外ではこんな所でしょうか．
今年もやはりリアルタイム系の話題が元気で，たくさんのプレゼンがありました．段々とリアルタイムで出来る事はオフラインに近付いて来たようですが，そのクオリティ(特に周波数)が追い付くにはもう少しかかりそうです．
paperはあまりチェックしなかったので，暇を見てproceedingsを眺めてみたいと思います．
Posted by ますお on Jul 21, 2006 – 3:03 pm
皆さんご存知のOpenEXRですが，ちょっとしたきっかけでソースを読みました．
OpenEXR
興味深いのは，OpenEXRでは画像を16-bit floatとして扱っている部分です．え？16-bit integerじゃないの？32-bit CPUでどうやって計算すんの？そもそも16-bit floatってどんなビット並び？
ドキュメントによると，OpenEXRでの16-bit floatは，符号に1ビット，指数部に5ビット，仮数部に10ビットとなっています．もちろんこんな型は現在の一般的な32-bit CPUでは規定されていません．
では，OpenEXRはどうしているのかというと，これこそがOpenEXRの「キモ」なのですが，C++のクラスとして”half”という型を定義し，演算子をオーバーロードする事で演算を可能にしています．演算その物は32-bit floatに変換してから行われるのですが，この変換は前もって作られたテーブルをルックアップする事で高速に処理できるようになっています．
なるほど，16-bitという事は，表現できるビット並びは僅か65536個です．これくらいなら全部をテーブルにしておいても全く問題ありません．素晴らしいアイディアです．
また，同じようなテクニックが，画像全体に演算が必要な場合にも用いられています．与えられた関数で65536回(全てのビットパターン)の演算を先に行い，テーブルを作っておくことによって実際の画像に適応する時はテーブルルックアップで済ませるわけです．65536というのは256×256ですから，これよりも大きなデータを処理する場合は確実に速くなり，大抵はRGBかRGBAチャンネルを持つ画像ですから，更に効率が良くなります．
これ，下手すると32-bit floatな画像を普通に処理するよりも速いんじゃないですかねえ．
さて，こんなに高度なトリックを駆使したOpenEXRですが，なぜもっとシンプルに32-bit floatを使わないのでしょうか？ILMは社内で使うHDRI画像フォーマットに，32-bit floatではなく16-bit floatを採用しました．その理由として，OpenEXRのサイトで次のように書いています．
32-bit floating-point TIFF is often overkill for visual effects work. 32-bit FP TIFF provides more than sufficient precision and dynamic range for VFX images, but it comes at the cost of storage, both on disk and in memory.
最近はHDDの容量も巨大になっていますし，ファイルサイズは問題にならなさそうに感じるかもしれませんが，塵も積もれば山となるので，ファイルサイズが半分になるのは大きな魅力です．ディスク上でのサイズもそうですし，ネットワークトラフィックも少なくて済みます．
こういった話は規模が小さい場合には問題が顕著にならないと思いますが，大きなプロジェクトになると予算に響いてくる重要な問題になります．
Posted by ますお on May 3, 2006 – 7:23 pm
会社の同僚からの情報．
NVIDIAのGelato 2.0には，なんとフリーバージョンがあるそうです．
NVIDIA Gelato 2.0
さすがに製品版と同じものではなく，プロダクションに必要な機能は省かれているようですが，あまり突っ込んだ使い方でなければかなり行けそうです．
GelatoはGPUを使用したアクセラレーションが良く話題にされますが，個人的にはレンダラとしてかなり理想に近い機能を持っていると思います．その理由としては，
- mocropolygon
- raytrace
- displacement
- motion blur
- point primitive，curve primitive
- シェーダ用簡易言語とDSO shadeops
- shading network
- スクリプト言語(Python)へのバインディング
- C++ API
あとは元Exlunaの連中が開発しているという安心感みたいなものもありますね(笑)．
もちろん，実制作では安定度やバグの少なさは必ず要求されますし，細かい所では問題も出てくるとは思います．どのくらい問題になるかは実際にプロダクションレベルの映像を制作してみないと分かりませんが，それは今後の期待と相殺かな？
うーん，仕事で一度使ってみたい．
Posted by ますお on Mar 30, 2006 – 8:11 pm
Adobe RGBはどんな時に効果があるか．
それは，sRGB以上の色を表現できるデバイスで表示する時であり，一番多いのはプリンタで出力する時でしょう．最近のインクジェットプリンタは高性能で，Adobe RGBの範囲を表現できる物も少なくありません．画像データがAdobe RGB空間の色を保持していれば，より豊かな色を再現できます．
しかし，一般的なモニタはsRGBまでしか再現できない事を昨日述べました．つまり，Adobe RGBが正しく表示できるかどうかは，画像表示アプリケーションに依存する事になります．理想的には，モニタで画像を表示する全てのプログラムがきちんとプロファイルを認識し，最も近しいと思われる色で表示してくれれば問題無いのですが，まだまだそういう状態には程遠いようです．
よって，Adobe RGBによる恩恵は確かにありますが，最終的に出力するデバイスに依存する事になります．むしろ，プリントはしない，見るのはモニタ上だけというような場合には，sRGBで保存する方がトラブルが少ないと思います．
ここで一つ考えられる事があります．Adobe RGBの方が沢山の色を表現できるんだから，Adobe RGBで保存しておいて，必要があればsRGBに変換すればいいんじゃない？確かにそうかも知れません．しかしながら，Adobe RGBからsRGBに完全に変換できる式が存在しない限り，8bit/channel同士のテーブル変換ではあまり正確には変換できないと思います．
そもそも違う色空間による結果の違いは，大元のデータが8bit/channelよりも広いレンジを持っている場合においてのみ意味のある話です．例えばデジカメのCDDからの出力，physically basedなレンダラから出力された輝度の値などです．モニタ上で一から描かれた絵にはあまり意味がありません．
ですから，デジカメであればRAWフォーマットのファイル，レンダラならHDRなファイル(.exrとか)で保存をしておけば，必要な場合にどちらにも変換，tone mappingが可能になりますから，出来る限りそうする事が好ましいでしょう．ディスクスペース的には厳しいかも知れませんが，仕事で高品質な画像を扱い，環境の許す場合は是非そうすべきだと思います．
そろそろ，画像なら8bit/channelという常識を見直す時期なのかも知れませんね．
