little things of mine

必要な物を一通り作り終わって，基本的な部分は動きました． 予想よりも速度低下が防げて，light shader一つで完結できるような形が作れたのでそれは良かったのですが，PRManのシェーダを書いている時に大きな問題が判明． PRManはシェーダレベルでarea lightをサポートしていない！ surface shaderから呼ばれたlight shaderは光源毎に一度しか呼ばれず，light shader内でいくら複数サンプルを取っても，各サンプル毎にはsurface shaderに返らないのです．これは即ち，surface shader内でサンプル毎のlight vectorとlight color(RSLでは”L”と”Cl”)が取得できない訳で，BRDFが正しく評価できません． いくつか回避策があるにはあるんですが，shading systemとしてはどれも気持ちが悪いし，既にあるsurface shader全てを修正しなければなりません．いずれにせよ，パイプライン的に深い部分での変更になるので，少し話し合いが必要そうです． うーん，やっぱりPRManはhackに弱い．できない事が多いです．その分敷居を下げているのは分かりますが，もう少しlow levelへのフックも用意してくれると嬉しいんですけどね． この辺の仕組みはmental rayに分があります．

どうやら仕事で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が出来そうで楽しみです．

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だそうです．スゲエ． [...]

皆さんご存知の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 [...]

会社の同僚からの情報． 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の連中が開発しているという安心感みたいなものもありますね(笑)． もちろん，実制作では安定度やバグの少なさは必ず要求されますし，細かい所では問題も出てくるとは思います．どのくらい問題になるかは実際にプロダクションレベルの映像を制作してみないと分かりませんが，それは今後の期待と相殺かな？ うーん，仕事で一度使ってみたい．