Investigation of the integration of Maya HyperShade and RenderMan SL

Maya HyperShade と RSL(RenderMan Shading Language) の連携(変換)について模索しています. 結論からいうと、HyperShade と RSL(1.0) の組み合わせは最悪なので、 目標としては lucille shader GUI plugin for Maya + LLL(lucille light transport language)を実現したい. 理由 まず、HyperShade がグラフベースのシェーダ(グラフ指向は、シェーダシステムとしてはよい方向性のデザインだと思う)、 それに対して RSL が手続き型の言語なので、RSL でシェーダグラフを表現するのが非常にめんどくさい. RSL2.0 を使う手もあるが、RSL2.0 もいろんな意味でアレなので、いっそ RSL2.0 に対応するなら  LLL に対応した方がいい. また、HyperShade 自体が Maya に限定された機能であること. Max/Maya/SI にすべてが mental ray が搭載されている今、 次は Max/Maya/SI の シェーダ GUI も mental mill(MetaSL)で統一してきそーな雰囲気がある. そうなったときのことを考えると、 HyperShadeContinue reading “Investigation of the integration of Maya HyperShade and RenderMan SL”

[Cont] 3D composite software

3D(立体視) コンポジットソフトの続き. NUKE + Ocula Ocula は基礎的な 3D 編集しかできないらしい. そのため、 実写 + CG が重なるようなケースでデプスベースの合成とか、 立体視でのレタッチとかが、十分できないらしい. CEATEC 2009 にて、3D に力を入れた発表をしていた某大手家電の 3D の技術担当と話をしたのですが、 「立体視での実写 + CG の合成はどうしてますか?」 と聞いたら、「んー、人海戦術ですねー。いやー(実写 + CG の立体視デモ作るの)大変でしたよー」なんて答えが返ってきました。 たぶん 1 frame ずつ手作業をしたんじゃないでしょうか… やはりまだ十分まともな立体視用の 3D コンポジットソフトは無いようです. Quantel Pablo 立体視コンポジット野郎に聞いたところ、Quantel の Pablo という編集(スタジオ)も、 ある程度立体視編集に対応しているそうです. ただこれはスタジオになるので使うとなるとハードルが高いですね. あと、やはり立体視の合成が十分できる機能もないそうです. NUKE その他 まー、そんなわけで、やっぱり立体視の合成は NUKE + (オレ様プラグイン)しかね? な結果となったので、ちょっとNUKE の SDK を見てみました.Continue reading “[Cont] 3D composite software”

NUKE + Ocula = 3D composite software?

最近はブームに乗って?立体視 CG もレンダラでどう効率的にレンダリングするかを考えなければなりません. いろいろ立体視について各社でお話を伺う機会があったのですが、 実写も CG も、単に 2 枚撮ればよいだけではなく、 立体視の制作のノウハウがたくさんあり勉強になりました. 特に、実写 + CG なコンテンツを作るときが大変らしい.  実写と CG パートの合成をどうするかとか. この場合になると、どちらかというとワークフローや 3D composite をどーするか、という問題になるそうです. んでワークフローはプロダクションごとに違うだろうからひとまず置いておき、 3D composite ってどーやるのがいいのかなー、なんかソフトあるのかなー、 それとも自作でペロペロっと作れるもんなのかな、と思い某海外プロダクションのひとに、 「どもども、ところでさ、今度立体視やるかもしれねーんだけどさ、3D composite ソフトでいいのない?」 って聞いてみたら、 「それだったら NUKE いいっすよー、んで 3D composite はプラグイン使えばでできるっすよー. 自作するのは時間かかって大変だから辞めといた方がいいよー」 って言われたので、NUKE についてちょっと調べたところ、 Ocula(オクラ?) っていう NUKE 用の立体視編集プラグインを見つけました. http://www.thefoundry.co.uk/pkg_overview.aspx?ui=39DEE70B-C88F-48F1-9BEC-99A9BAFE2850 というわけで、NUKE + Ocula っていうコンビネーションが 3D composite 用途ではオススメのようです. ちょっと lucille でどのような合成データとかに対応すればいいのか調べるために NUKE いじってみますかね.Continue reading “NUKE + Ocula = 3D composite software?”

ptlined() function signature differs from RI spec and RI impl.

RI spec と RenderMan 実装系では、ptlined() の引数が違います. RI spec 3.2. float ptlined ( point q, p1, p2 ) RMan implementations. float ptlined(point p1, point p2, point q) ついでに RI spec だと rotate() の返り値の型も違うんですよね. きちんと仕様の方は、修正しておいてもらいたいところ.

[RSL] specular() is implementation-dependent

RSL の specular() が、実装依存であることが分かりました. RI spec に載っている specular() の式と、prman などで使われている specular() の内部実装の式がなんと異なる! Advanced RenderMan にもそんな注意文がかかれていました. さすが RenderMan, 見事なダブルスタンダード?ですね. aqsis のソースを見ると、RI spec の式で、1.0 / roughness のところを 1.0 / (roughness / 8) とすると prman の式と近くなるようです. lucille はそのようなレガシー(?)なあやふやさまで再現する気はないので, specular() は RI Spec 通りにして、prman のふるまいをエミュレートするのは別関数化したいなぁと思っています. ま、一番いいのは specular() は使わずに、独自できちっと反射モデルや BRDF 式をシェーダ内でコーディングすることですかね.

LLL(Lucille Light transport Language) idea proposal

レンダラ神から、以下のように啓示をうけました. SYOYO君には、言語的に不完全なrenderManのSLや、OSLなどではなく、言語的に奇麗で 完成された物を期待してます。そのついでにrenderMan SLやOSLもサポートしてますってくらい が良いかと。 うぉおおおおおおおおお おおおおおおおおおおお おおおおおおおおおおお おおおおおおおおおおお! さすがレンダラ神!なんでもお見透しである! 言語的に奇麗で完成されたシェーダ言語がやはりこれから求められている! そして OSL や MetaSL がそのようなものになるとは言えないだろう! そこで、言語的に美しく完成された次世代シェーダ言語、 Lucille Light transport Language(LLL)の提唱ですね!分かります! LLL とは? とはいえ、まだそれほど LLL についての具体的な案はありません. 漠然とこんな感じかなぁと思っています. – Composable(ノードベース GUI との親和性が高いように) – 関数型的な言語仕様 – Python 的な良さを入れてみたり(インデントが重要とか) – サンプリングとシェーディングを切り分ける — サンプリングもシェーダに入っていると、bidirectional sampling とかが非常にやりずらい. サンプリングの手続きは別で記述できるようにしたらいいのではないか? ここらへん、いろいろなシェーダ野郎と議論して定義していきたいなぁと思って思います. とはいえ、世界でみてもこんな話題ができるシェーダ野郎(言語設計とコンパイラが書けるシェーダ野郎)は一握りなのですけどね 🙂 彼らをいかに引き込めるかがカギとなるんじゃないかなぁと思っています.

DJV imaging

http://djv.sourceforge.net/ こんなツールを見つけました. CG プロダクションむけ画像ビューア & プレイバックビューア. DJV(だいじょうブイ)と、日本人には非常に覚えやすい名称になっています 🙂 正直、3delight の i-Display のようなよくできたフレームバッファドライバを作るのは面倒なので、 こういうのがあれば「こっちを利用して」、と言ってしまいたい. lucille 用には今 rockenfield がありますが、まあ機能とかでいったらこの DJV のほうがはるかにいい出来ですしね. LUT テーブルとかにも対応していますし. 似たようなフレームバッファドライバをがんばってまた作るよりは既存のもので代用して、 レンダラの開発に注力したいというのもあります. open source なので、lucille から DJV にレンダリング結果をダイレクトに画像転送させる機能とか 追加してコントリビュートしたいなぁ. あと linux だと EXR の表示がどうもおかしいので、それも直してあげたい. HDR(RGBE)にも対応していないので、その機能もかな. ま、ちょっとソース見てみますかね. おまけ あと、ESC で終了するのもいいですね. rockenfield も ESC で終了します. 以外と ESC で終了させることができる GUI アプリって無い気がします. ESC で終了させることができるとオペレーションがすいすいできます. 特にコマンドラインがメインのひとはそう思うんじゃないでしょうか. そのかわりセーブとかしていないと大変ですが 🙂

Go procedural | Houdini campaign

http://www.sidefx.com/index.php?option=com_content&task=view&id=1548&Itemid=66 go procedural と称して、houdini が半額キャンペーンやっています. これを機会にちょっと Houdini 環境も整備しようかな. go procedural プロモーションでは、なぜプロシージャルベースの手法が必要か、以下のように述べられています. CG 業界は爆発的に成長していますが、スタジオは多量の高度にリアルな視覚効果のショットを、 少ないリソースでこなしていかなくてはならなくなってきています. この爆発的増加を解決するために、多くのスタジオは Houdini を利用したプロシージャルな手法を選択しています. これを読んで、こんなことを想像しました. – ユーザの目は越えてきており、高品質で物量のある VFX を作らなくてはならなくなってきている. -> 人手でそれを解決するには自ずと限界がある -> よって、モデリングやアニメーションをプロシージャルでやることでその問題を解決しようというのが Houdini の go procedural なのだろう -> ではそうなったとき、レンダリングはどうなるか? -> プロシージャルで多量に複雑に生成されたジオメトリ、テクスチャをレンダリングするには高速、高品質なレンダラが必要だ … というわけで、これからはレンダラも高速、高品質、プロシージャル対応なものが必要とされてくるに違いない! まあ物量が増えて、求められるクオリティが上がってくるのは間違いないので、その点では go procedural は、 大規模でも高速にレンダリングするという lucille の方向性とマッチしています. lucille をプロシージャルに強いレンダラにしてみましょうかね. もちろん、プロシージャル対応はどのような形式になるにしろ、対応は必須となるでしょうが. (たとえば RIB の Procedural, MentalRay で言う Geometry shader 機構のサポート).Continue reading “Go procedural | Houdini campaign”

Poor shader optimination in PRMan

あまり使うことはないと思いますが、 以下のような、何もしないけど重いループが PRMan ではコンパイル時の最適化で除去されません(-O2 をつけてコンパイルしたとしても). (このシェーダを使うと、レンダリングに時間がかかる) surface myloop() { float i; for (i = 0; i < 100000; i += 1) { } } 一方、3Delight(-O3 オプション有効)はこのループを除去します. よってこのシェーダを使ったレンダリングは一瞬で終わります. 次に、以下のような Ci にいろいろ代入するけれども、最後の Ci 代入だけが効果がある例. surface myshader() { float i0 = 0.0; Ci = i0; float i1 = 1.0; Ci = i1; … float i10000 = 10000.0; CiContinue reading “Poor shader optimination in PRMan”