Syoyo Fujita's Blog

raytracing monte carlo

Category: lucille

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)で統一してきそーな雰囲気がある.
そうなったときのことを考えると、 HyperShade 対応の作業は無駄に終わりそうという懸念がある.

あとは, 3d package soft に依存しない shader GUI が lucille にも欲しい.

現実

とはいえ、「今」を考えると、HyperShade -> RSL 変換は結構自分でもあるとうれしいし、需要もありそうである.

というわけですこし HyperShade I まわり, Maya の shader SDK あたりを調べてみました.

shader SDK

Maya には SDK に 3 種類のシェーダ SDK があるようです.

1. plug-ins

Maya プラグイン全体の SDK. この中でいくつか lambert とか phong とかのシェーダコードサンプルがあります. ただこれは maya plugin 神によれば maya でデフォルトで HyperShade に表示されているものと対応するものではないらしい.

あと、ここにある SDK は HyperShade 上にカスタムシェーダノードを表示させるのにも使われるようです.
MRenderUtil とかの OpenMaya API を使っています(Maya SW render API も使っているのかな?)

2. adskShaderSDK

なんか新しめ? のシェーダ SDK.
内部で mental ray を使うことを想定しています.
(1) に比べると、コードは簡潔かつモダンな感じです.

3. mentalray shader source

maya に標準で付いてくる mental ray shader に対応している感じです(mi base shader とか).
シェーダが、ソース付きであります.

HyperShade 評価

基本的には, python スクリプトで HyperShade のノード情報を自由に取得できるので、
パフォーマンスを気にしなければ python で HyperShade をスキャンしてシェーダグラフ構造作って,
そこから RSL コードを吐く、というステップを踏めば変換完了です.

が、maya plugin 神と一緒にいろいろ調査して、そうウマくはいかないことが分かりました.

– アトリビュートがアニメーションしていたらどうするか?(たとえば lambert.color アトリビュートがキーフレームアニメーションしているなど)

アニメーション値をベイクして, フレーム分の RSL を作る
-> RSL がいっぱいできてしまう. あと複雑な依存があるときにはうまくいかない気がする.

RSL は一つで、アニメーション値はフレームごとに RIB でパラメータで設定する
-> exporter と shader codegen のプログラムの分離ができない(RIB を吐くときに毎フレーム hypershade を評価しなければならなくなるので, export 処理の速度低下がおきてしまう)

– face 単位でテクスチャが貼られていたり、切り替わっているときにどうするか?

– expression がアトリビュートに割り当たっていたらどうするか?

んー、なかなか考えることはいろいろありそうです.

Advertisements

BSON as a next-gen scene file format.

BSON is the binary form of JSON-like document from mongoDB team.

http://www.mongodb.org/display/DOCS/BSON

BSON and JSON are simple and easy to use and modify through Python, C++, etc, thus I think BSON/JSON is a good candidate for a next-gen scene description format.

If you need to handle huge data, you could use C++ BSON binding for speed and storage.

Here’s example python script interacting scene data with BSON and JSON.

Sounds nice?…

If I found BSON(and mongoDB combination) is really nice after more investigations, I might adopt it as a lucille’s scene file format.

[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 を見てみました.
それなりにきちんとしている感じで、NUKE プラグインは書きやすそう.

あと、NUKER(?) から聞いたのですが、なんか NUKE は遅いらしいとのこと.
Shake と比べて速度が 1/10 とか.
そのためかどうか知りませんが、某スタジオの計算サーバ(数千ノード)の半分は NUKE 用のレンダーサーバに割り当てられているとか…

あと、なんか NUKE 結構バギーです. Windows 版を PLE で遊んでいますが、結構落ちます…

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 いじってみますかね.

ところで、NUKE って昔(2002 年ごろ?)は 1 本 300 万くらいしたような記憶があるのですが、
最近だと 45 万円くらいなのですね. リーズナブルな価格です.

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 機構のサポート).

プロシージャルに強い、というのは、プロシージャルのためのインターフェイスを用意するだけでなく、
レンダラ側で、プロシージャル専用言語を用意するとか、プロシージャルコードを Python で書けるとか、
マルチスレッドでもスケールアップしてプロシージャルのコードが動作するとか、
(MR の Geometry shader とかは、明示的にやらないとシングルスレッドコードとして実行されるんじゃないかな?)
Houdini の procedural コード(VEX?)と連携できるとか,
そんなあたりの、プロシージャルを書き、そして実行する部分を効率化することを強化するということになります.

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;
    Ci = i10000;
}

Ci = i10000 の expression 以外は DCE(Dead Code Elimination) されることが期待されます.

PRman だとシェーディング処理がそこそこかかります(DCE されていない).
3Delight(-O3 最適化オプション有効)だと一瞬でした(DCE されているようだ)

んー、PRMan のシェーダコンパイラ(やインタプリタ)は、あまり最適化してくれないようですね.