little things of mine

あまりに更新が滞り過ぎなので，SIGGRAPH 2011の感想を． 今年はSIGGRAPHがアメリカ国外で開催された年でした．場所はカナダのVancouver．近年Vancouverは映像産業の誘致を積極的に進めていて，今では多くのスタジオが支社を置いています．メジャーどころでは，Imageworks，Digital Domain，Pixar，MPC．ILMがもうすぐできるし，あとImage Engineは本社があります．他にもMethodやRainmaker，Prime Focusと言った中規模のいい会社もあります．今現在で最もホットな求人エリアなのです． さて，カンファレンスですが，今年も滞在期間が三日半と短かったのに加え，会社から聴講するように割り当てられたセッションが多くてあまり自由に動くことができず，何度も見たかったセッションを逃してしまいました．以下はその少ない中からどうにか拾ったものです． [ Courses ] “Production Volume Rendering 1” & “2“がとてもいいセッションでした．スピーカーは大手スタジオでボリュームレンダラを書いている開発者の面々で，基礎から実用の詳細まで語られていました．スピーカーの一人，Magnusのサイトからコースノートがダウンロードできます．TDは必見． Production Volume Rendering (SIGGRAPH 2011) — Magnus Wrenninge Magnusは更に本の出版を予定しているそうです．実際に動くレンダラのコード付きで，リリースは来年とか．こういう情報は今までほとんど表に出てこなかったで，自分も含め興味のある人はウハウハでしょう（笑）． [ Talks ] “Facing Hairy Production Problems“と，”Fur and Feathers“のセッションで，大手数社がhairやfur，featherのスタイリングやインスタンスのパイプラインをどう構築したかが紹介されたのですが，各社ノードベースのコアエンジンを自前で開発したところが多いようです．同じエンジンをスタイリングとインスタンス処理の両方に使うことで，巨大なデータを受け渡すことなくレンダリング時に最終的なデータを生成する事ができるようになります． こういうアプローチは今後いろんな所で進められると思います．うちらは”deferred pipeline”と呼ぶ事が多いのですが，要するにレンダリングされる直前まで実際のシーンを作るのはやめて，代わりに「そのシーンをどう作るか」を記述したレシピみたいなものを用意し，レンダリング時まで最終的なシーンの生成を先延ばしにしよう，という考え方です．Houdiniに代表されるようないわゆる”procedural”をより一般的な作業にまで広げた感じですね． 実はKatanaはまさにこういうパイプラインを構築するためのツールで，ライティングに必要な処理，例えばマテリアルやテクスチャのアサインなどを”deferred”にするためのものです． [ Technical Papers ] Paperはほとんど見れませんでした．．．これとか見たかったんだけどなあ． このくらいですね． Vancouverは以前にも何度か訪れた事があったのですが，やっぱりとてもいい場所です．自然が多くて街並みも綺麗．会場もLAのConvention Centerに比べるとだいぶオシャレでした． 来年はまたLAに戻るようですが，是非またVancouverで開催して欲しいと思います．

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に分があるように思います． このテの話は色んな方面からツッコミが来そうで怖いのですが，とりあえずこれにて．

今更ながらPRMan15の話題など． Pixar's RenderMan® / Press Releases いろいろな追加機能があるのですが，目立った物だけ紹介します． [ Volume Rendering ] 今回のバージョンで一番大きな追加機能はこれでしょう．PRManにモダンなボリュームレンダリングの仕組みが搭載されました．今までもボリュームをレンダリングする事は可能でしたが，「モダンな」と言うところが鍵です． ボリュームレンダリングと言えば，視線（ray）に沿ってdensityを積分してゆくray marchingが一般的ですが，これはサンプル数が十分でないとノイズが出やすく，ディティールも再現できないので，サンプル数を上げざるを得なくなり，その結果時間がかかってしまうものでした． PRMan15に搭載されたのは，frustum voxelを使った手法です．これは，通常のvoxel gridにperspectiveをつけたものと考えてもらえばいいかと思います．つまり，カメラに近い方が小さく狭く，遠くなるにつれて大きく広くなっているvoxel gridです．このようなvoxelを事前に生成し，次にそれぞれのvoxelにおいてシェーダを実行して各々のvoxel densityを計算，そのあと視線に沿ってdensityを足し算します． イマイチわかりにくいと思いますので，ray marchingと処理手順を比べてみます．ray marchingは，「初期ポイント→次のシェーディング点を探す→シェーディング→足し算→初期ポイントを移動」という処理をボリューム内部において延々と繰り返す必要があったのですが，frustum voxelの場合，「voxel grid生成→一度に全部シェーディング→足し算」とシンプルになります．また，シェーディング結果がシェーディングポイントの決定に影響を与えないので，並列化もできます．サンプリングポイントをdynamicに決められない事が欠点のように思えますが，frustum voxelは近い所をより多くサンプルするようになるので（voxelが小さくて狭いから），効率の良いサンプルが可能なのです（もちろんパラメータでの調整もできる）． 軽くテストしてみましたが，レンダリングも高速で，非常に良い結果が得られました．point cloudと相性が良いのも実作業では大きな武器になるでしょう．scatteringとかやれますからね． [ Struct Inheritance and Member Functions ] RSLで，structがメンバ関数を持つ事ができ，さらに継承ができるようになりました．これはshader writerにとっては非常にうれしい事で，シェーダの機能をオブジェクト指向っぽくモジュール化する事ができます．今までは関数にするしかなかったので，これは大きな進化です． 実際にこれをフルに使ってshader libraryのプロトタイプを書いてみましたが，かなり奇麗に書く事ができました．一部制限があって（関数をインターフェイスにできない），小さなhackも必要でしたが，全体的に見通しも良くなりましたし，拡張も継承を使って楽にできるはずです．あとは使う人達がどう感じるか，かな． [ Ray Differentials Shadeop ] ようやくray differentialsがシェーダ側で取得できるようになりました．新しいRSL関数，raydifferentials()が追加になっています（ray differentialsについては以前の記事を参照してください）．恐らくこれに伴った機能追加だと思うのですが，filterregionという，pre-definedなstructが用意されました．これはあるシェーディングポイントにおいて，適切なfilter sizeを2D/3Dで計算して返してくれるクラスです．PRManは以前でもtexture filteringのクオリティは高い方でしたが，さらに良くなるようです．特に二次レイ以降の結果向上は顕著だろう思いますが，まだテストし切れていません． [ Ptex ] Ptexについては前回の記事を参照してください． こんなもんでしょうか．他にも開発系の機能追加が多くあるのですが，今回も「使える」機能がたくさん追加されました．思わず「いいねえ」と言いたくなります． さて，あとは実践投入だ．

DisneyからPtexのコードがリリースされました． Ptex Overview PRMan 15.0でPtexがサポートされたので，その他の新機能を含めてまとめて書こうと思っていたのですが，思ったよりも早くDisneyからソースコードがリリースされたので個別に紹介したいと思います． texture mappingは，現在広く使われているUVベースの物が開発されてから，恐らく40年以上，基本的なアイディアは変わらずに来ました．逆に言えばそれだけrobustなものであったとも言えるわけですが，実用レベルでの様々な問題を長年解決できていなかった事も事実です．それらはこのブログでも何度が取り上げた事がありますが，アンチエイリアス，UV空間と実モデルのボリュームの違い，どんなモデルでもUVをきちんと作らなければならない事，などです． Ptexは，Disneyが2008年にEurographicsで発表した，新しいtexture mappingに関する手法およびデータフォーマットで，上記で挙げたような実作業上の問題をできるだけ解決すべく，Disney内部で開発された技術です．Ptexはper-face texture mappingの応用にあたる物と言えるので，細かい事を言えば「UVテクスチャ以来の新技術」というのは言い過ぎかも知れませんが，実用可能なレベルまで改良を施し，きちんと作品に還元できている点で，非常に評価できると思っています．元論文はこちらあります． Ptex: Per-Face Texture Mapping for Production Rendering 特徴を挙げると： – UVフリー – seam問題の解決を含む高品質なアンチエリアス – 部分ごとに解像度を調整可能 – 効率的なデータストレージ 詳しい仕組みは論文を読んでいただいた方が良いと思いますが，乱暴に言えば，ポリゴンフェイス毎に個別なUVを持ち，それぞれ違う解像度のテクスチャを充てている，と想像してもらえれば分りやすいと思います．全ポリゴンがそれぞれ個別なUVを持っているわけですから，テクスチャ座標を人間が作ってやる必要はありません．ポリゴンモデルができた時点で，全てtexture readyになるわけです．（それぞれのフェイスのUVは頂点ループの順番で固定できます） Ptexではそれぞれのper-face textureを全て一つにファイルに保持し，加えてメッシュの繋がり情報を保存しておく事で，複数のフェイスに跨がったフィルタを解決しています．それぞれのフェイスが別の解像度を持つ事は，必要な部分だけ解像度を高くする事ができるわけで，ファイルサイズの節約になりますし，アンチエリアスもディティールを殺さずに済みます． Disneyではprocedural patternもPtexに焼いているようです．個人的にこれはとてもいいアイディアだと思います．焼いてしまうとシェーダレベルで変更ができなくなるので逆行しているように見えますが，procedural patternは，voronoi diagramなど，物によって非常にアンチエリアスの難しい物があるので，むしろテクスチャに焼いてしまった方が問題が少なくなるケースも少なくないのです． さて，とても良さそうなPtexですが，スタジオレベルでの大きな問題が一つあって，それは「Ptexをどうやって作るか」という事です． Ptexの利点を最大限利用するには，フェイス毎にテクスチャをペイントする必要があります．Disneyでは自前の3D paintプログラムを開発してこれを解決したようですが，これはどこでもできる事ではありません． しかし，個人的にはこれには楽観視していて，PRManがすでにPtexをサポートしている事と，今回DisneyがPtexのライブラリとそのソースコードを公開した事で，比較早い時期にZBrushやmodo，BodyPaintのようなツールがPtexをサポートするのではないかと思っています．そうなれば普及は早そうです． 最近のVFX業界は，技術がどんどん（有償無償問わず）オープンになってきていますね．技術の均一化によって値段が更に下がり，単純作業はコストの安い海外へアウトソースされて行きます．これからは単一の技術が生き残る要因にならず，パイプラインのコア技術や優秀な人材など，スタジオの地力みたいなものが効いてくる時代になって行くのでしょう． なかなか厳しい時代になりそうです．

レンダラ込みのrelightingツールだそうです． The Bakery デモを見せてもらったのですが，まだリリース版ではないものの，とてもよく出来ていました．簡単に言ってしまえば，先日のKatana + renderer + relighting engineと言った趣きです．Katana同様，簡単なcompもできるようになっています．レンダラは専用で，外部の物（PRManとか）を使うことはできないそうですが，専用のレンダラを使うだけあって，ツールとrelightingエンジンとの連携は素晴らしく良かったです． レンダラはREYES + レイトレで，必要そうな機能はほぼ実装済みな感じでした．curve primitiveやpoint primitiveも使えるそうです．relightingのシステムとしては，レンダラがREYESであることからも分かるように，初めにmicro polygonに分割し，その情報をキャッシュしておいて，シェーディングとサンプリングの再計算を高速にするタイプの物です．PRManのそれと基本的には同じですが，PRManよりもいろいろな事ができるようになっていました．（というかPRManのrelightingはまだオマケみたいなもん） 最初にカメラからmicro polygon化してしまうので，視点の変更が起こるともう一度bakeし直す必要がありますが，実際のshot workではあまり問題にはならないでしょう．カメラは動かせませんが，displacementシェーダの変更には対応しているそうです．shadowも変更できるようですが，shadow mapが基本なようで，レイトレを使うとさすがに多少スピードダウンしてました．他にも，SSSやGIの変更にも対応していますが，これらはpoint cloudを使っていて，それをon-the-flyで再生成するのですが，オブジェクト毎にうまくローカライズされており，非常に素早いフィードバックが得られるようになっていました．他にもspherical harmonicsを使ったlighting情報をpoint cloudに保存できるなど，なかなか使いでのありそうな機能が搭載されています．例えば，IBLとかblurry reflectionに使えますね． 拡張性もなかなか良さそうで，shading networkも組めるし，custom shaderもC++や独自のshading languageで書けるそうです．procedural geometryもサポート．bakeするデータもカスタマイズ可能で，好きなデータをプラグインできるらしい． 話を聞いていて，PDIのやつに良く似てるなーと思っていたのですが，どうやらCEOとCTOは元PDIの人らしい．デモをしてくれたのも彼らだったのですが，同僚に顔見知りがいました．特にCEOはeffects leadだったようで，現場で必要そうな物をきちんと揃えているのはそういうことみたいです． ただし，全体的にやはり3DCG feature向けな印象が強く，shadow mapやpoint cloudを多用する辺り，photorealにするには一手間かかりそうな感じはします．あと，ツールとレンダラがほぼ一体化しているので，既存のパイプラインに組み込むのが簡単ではないかな．ほぼ構築し直しになりますね． 自前で作る時の良いお手本にはなりそうです．