[mental ray] Placeholder

mental ray Placeholder Tips
ジオメトリシェーダに引き続きというか絡んでというか、これもまた気になるネタ。


たとえば普段Mayaでレンダリングする際、全てのオブジェクトを単一シーンに読み込んでしまって~、みたいなことはしない。
大体の場合リファレンスしてレンダリングする。
つまりレンダリングするファイルには、必要最低限のシーンの情報だけあればOKということ。

MayaとRenderMan、mental rayなどのレンダラが異なる点は、レンダリングシーンが連番であるか否か、という点。

Mayaの場合、たとえば全部のオブジェクトをシーンに含めてしまっても、実は大したことない(いや、あるんだけど)。
なぜなら1パス1シーンだから。

ただRenderManやmental rayは、1パスの1フレ1シーン。
1フレ辺りのデータ量が大体同じだと仮定して(実際にはそんなことはない)、10秒のシーンではおよそ240倍のデータ量となる。
これはシーンのトランスレートの手間などを考えると無視できる数字ではないことが容易に分かる。

なのでRenderManやmental rayでも、効果的にオブジェクトのデータを扱いたいと思うのは当然で。

RenderManならReadArchive、じゃあmental rayは?というと、Demand Geometry、Placeholderと呼ばれるような同等の機能があるっぽい。

これは元々On DemandなGeometryなわけなので、どちらかと言えばメモリ容量の削減のために考えられた仕組みなのかもしれないんだけど、他の用途にも使える気がする。

他の用途と言うのは、つまりMayaで言うところのリファレンス的なもの。
的なもの、というのは全く同じものではないから。

Mayaならデフォメーションのためのデータを与えておけばMaya側でデータをコネコネやってレンダリングしてくれるわけだけど、mental rayはベイクされたポイントデータを要求する。
つまりジョイントがどうの、とかそんなものは加味してくれない。まぁ当然だけど。

なので、ほんのちょっとでも動いたらそれは効果的に~の対象にはならない。
いや、もしかするとそういうことが出来るかもしれない、ともおもう。これはまた前述のGeometry Shaderによるところなんだけど。たとえば差分ファイルだけ出しておけば、とか。でもまぁそれはまた別の話。

というわけで、とりあえず動かないものに限定して話を進めてみる。
動くものに関しての効果的な取り扱いはまたいずれ:)

mental rayでPlaceholderとして静的なオブジェクトを扱う場合、たぶんざっくりこういうことをやればOKなはず↓
・エレメントのシーンをmiで出力しておく
・miの対象オブジェクトのオブジェクト定義を編集
 →編集内容に関しては上記リンクを参照

これでおそらくPlaceholderの機能は最低限使えると思う。
が、使い勝手はこれで本当にいいのだろうか?

たとえばバウンディングボックスのサイズはどうする?
それが分かったとしてそのサイズのボックスを置く?それでホントにシーン作れる?

バウンディングボックスはみんなどうやって合わせてるのか若干謎だけど、
大体の見栄えはProxyオブジェクトを用意することになるのかな。

で、miを出したとして、デフォルトだとProxyオブジェクトのポイントデータが出ちゃってる可能性があったりする。それをイチイチ手で消す?
というかそもそも人力作業??

多分ここでまたジオメトリシェーダの出番なのかも。
これを使えば最上位に1個ジオメトリシェーダ突っ込んでしまえば、バウンディングボックス問題も作業時のプレビュー問題も解決するはず・・・?
それはないか。でも全部コンバインしてあれば多分OK。
それにmi書き換えでは不可能なMayaからのプレビューレンダリングも可能。
幸いなことにサンプルのソースコードも公開されている。 
 

と、こういうことをやればかなり効果的にmiファイルを作成することが出来そうな気がする。
効果的に、というのは、シーンデータとオブジェクトデータの出来る限りの分離。

シーンデータとはシーンの情報だけ持っていれば良いと考えられる。
レンダリング設定、ライト、カメラ、その他細かなオブジェクトなど。

オブジェクトデータとはそのまま、キャラクタ、背景、プロップetc…

これががっちり分けられた時点で、すごく使い易いシーンになるのは想像に難しくない。
データ自体の扱いは若干煩雑になるけど、その恩恵を考えると大した問題ではないかなと思う。

そういえば3DelightとかPRManはオブジェクト別出ししてReadArchiveしてたような。
詳しく見て無いからなんともいえないけど、やっぱりそういうことをしたほうが良いって事の表れなはず!!

 
で、だ。
 

これを考えてるときに思ったのは、mental ray for Mayaのトランスレータでホントに全部まかなえるのかというところ。
やつは多分正直にシーンを全ベイクしてるはず。
それってとりあえず使えるデータ、というものでしかないような気が。
本気でmi扱いたいと思ったら全ベイクで出すのとかはあまりしたくないんじゃないかな・・・?
ストレージがいくらあっても足りないし。

やはり大手のプロダクションはトランスレータも自作なんだろうな、と勝手に妄想する僕でした。
WETAがLiquid作ったのもmtorじゃ不足!!というのがあったからなんだろうな。

なんにせよ、トランスレータ自作なんて手間とか考えても無理なのでスルー。
とにかく効果的にmental rayとMayaを使うには、外部データを読んでジオメトリシェーダでウッハウハ、ってのが一番なのかな。
出来る限りmiに手を入れないで、シェーダレベルで物事を解決してしまえる手段というか。
もちろんそこが本当に整った形になるかどうかは検証してみないとだめだとは思うけど。

僕がその存在を知ったときは「何それ食えんの?」ばりの扱いを受けたジオメトリシェーダ、
ここまでパイプラインの核をなすような使い方が出来るとは思いもしなかったワイ。
恐るべし。。
 
あとPlaceholder使えば、そこそこ手軽に群集とか作れそうかも?
そうなってくるとパーティクルデータを参照してオブジェクト配置して、とかいろいろアレですね。
サイクルのオブジェクト数体をmi連番にしといて、パーティクル動かして外部ファイルに出して、でっかいボックスとかにGeoShaderアサインしてパーティクルとオブジェクトのサイクルデータアサインして、Render!!!!とすればなんとなくいけるのかな。

なんか具体的な使用に入る前にいろいろ検証だの調べものだのばっかりでそろそろアレだな。
ぼちぼちシェーダとか書いてみたい。
シェーダを制するものはmental rayを制す・・・!?

 
と、これだけ書いたけど、半分以上は想像と妄想なので間違ってるところあれば是非ご指摘ください(;;)ノシ

———————————————————— 追記
こちらを見る限り、Placeholder = RenderProxyって事みたいなんだけど、RenderProxyに関してはこの間rva君がBSP2がどうの、とか言ってたような。。

一体何が違うんだ・・・

といったところで次のキーワードはこちら。
LAmrUG : Assembly Tips

special type of placeholderって書いてある。
これがRenderProxyのことか?

あとでシミュレーション中にでも読む。

ちなみに今2連泊中!!

死ぬ(^^)
自分がくさすぎて死ぬ(^^)

なのであまりこんなことやってる場合じゃない。
あ、処理終わった。

仕事再開(・・)ノシ

「[mental ray] Placeholder」への13件のフィードバック

  1. がんばってますね.
    考えたら考えただけ,try-n-errorをやった数だけ,経験として蓄積していくものだと思います.大いに悩みましょう.トランスレータは,Mayaに付属の物で十分やれますよ.工夫次第だと思います.

    一つだけ.マテリアルは.miには含めず,レンダリングシーンに入れるようにした方が良いと思いますよ.そうでないと,ショット毎の調整が出来なくなってしまいます.いや,できるような仕組みがmentalrayにはあるんですが,それをMayaで使えるように整備するのはかなり大変なので.

  2. >ますおさん
    励ましのお言葉ありがとうございます(・・)ノシ
    忙しい最中の方が脳が効率良く動いてるような気がします。。
    長い間は持ちませんが・・・

    > トランスレータは,Mayaに付属の物で十分やれますよ.工夫次第だと思います.
    なるほど、そうでしたか。
    まだUserDataやmiTextなど、mental rayっぽい機能をどう使うのかがイマイチわかっていなかったりするのでなかなかイメージわかないところですが、こちらも引き続き調べて試していければと思っています。

    > マテリアルは.miには含めず~
    なるほど。これは言われてみれば確かにその通りですね。
    ただちょっと想像が付かないのが、Placeholderで読んだオブジェクトの中の細かなオブジェクトに対してのマテリアルのアサインが、読み込み元のデータで行えるのか、というところです。
    1個1個全部別のPlaceholderで読んで、その数と同じだけのトランスフォーム作ってGeometry Shaderアサインしてさらにマテリアルアサインして、、みたいなワークフローにする必要があるなら、元のモデルを複数用意してしまって読込先変えてしまえばいいのでは、とも思います。
    おそらく僕がますおさんの言ってることが全部理解できてないからなんだと思いますが、、

    んー、でもマテリアルは確かに調整出来たほうが、、
    というか出来ないと、、、

    とりあえずいろいろ試すにしてもmental ray standaloneのライセンスが最低1本は必要ですね。
    さてどうやって調達するかな、、、
    具体的な話はこの仕事が終わってから上司に相談という方向で考えることにします。

     
    風呂入って寝たら一気にパワー回復(したつもり)!!
    もうしばらくの辛抱、頑張れ自分!!!

  3. >Placeholder = RenderProxy
    そういうことみたいですね
    MAYAでそのままやると強制的にBSP2になる上にmr standaloneでしか設定できないのでなんとも微妙な仕様ですが

    >たとえばバウンディングボックスのサイズはどうする?
    >それが分かったとしてそのサイズのボックスを置く?それでホントにシーン作れる?
    MAYAだと適当なジオメトリにProxy設定すると自動で大きさ変えてくれますが、BOX状にしか大きさ取ってないので
    自分でローモデルを用意した方が使い勝手は良いです。

    >ただちょっと想像が付かないのが、Placeholderで読んだオブジェクトの中の細かなオブジェクトに対してのマテリアルのアサインが、読み込み元のデータで行えるのか、というところです。
    現状MAYAでは1つのmiに対して単一のマテリアルしかアサインできないっす。。。。
    そういう場合は色々やる必要はありそうですね。期待してまっすwww

  4. >rvaくん
    >Placeholder = RenderProxy
    そういうことみたいですね

    いや、もしかしたらPlaceholder > RenderProxy = Assembly、かも・・・?
    http://www.lamrug.org/resources/assemblytips.html

    これを見つけたとき、前にrva君がMayaからExportする場合assemblyがどうのとか言ってたのを思い出して。
    まだ上のURLの中身読んでないけどそういうことなのでは、と思ってます<Assembly

    実際はどうなんだろう。

    >BBox
    なるほど、やはりそういう感じですか。
    前にどこかがデモやってたRenderManのReadArchiveでまさにそういうことやってた。
    本格的に使うとなるとProxyオブジェクトの扱いも考えたディレクトリストラクチャ組まないとねー、ということになるね。

    >マテリアル
    やはり、、、
    ツールでカバーするのか、知らない何かがあるのか、諸々調べる必要ありそうですね。

    今後ともよろしく(・・)ノシ

  5. そろそろ全体的な「パイプライン」を考える時だと思いますよ.
    publish/import的なマネージメントを視野に入れると解決できる事が多いです.

  6. >ますおさん
    そろそろ全体考えないとアレだろうなとは思ってました。
    何にせよ全ては今の仕事終わってからですね、、、

    ぼちぼちshaderも書きたいですねー。

  7. 某プロジェクトではプレビュー用にハードウェアシェーダ作ってました。とあるタコ仕様のためキャラ毎にジオメトリファイル(ポリゴン情報xフレーム数)のメモリイメージを1つのファイルに出力、群集シーンにはProxy置いといてハードウェアシェーダアサイン、シェーダが対応するファイルを読み込んでダミーの代わりにViewに描画してました。それでもファイルアクセス数が半端じゃないんでおまけでセレクトされたキャラだけ表示後はダミー(球とかボックスとか)表示する機能つけてました。ボトルネックは(もちろん)ファイルアクセスです。

  8. セレクトされたキャラだけジオメトリをファイルから読んで表示、選択されていない残りダミー(球とかボックスとか)表示、です。

  9. >hohehohe2さん
    あれ、某プロジェクトってmental ray使ってたんですか?
    ハードウェアシェーダでもファイルにアクセスしたりとか出来るんですね。
    ファイルアクセスはもうどうしようもないんでしょうねー。
    メモリが今後ものすごく増大すれば問題なくなるかもですが、それを上回るほどのファイルになっていくこと請け合い!!ギャーーー

    んー、興味深いので今度是非いろいろお聞かせください。

  10. あーレンダリングはmentalrayじゃなくてrendermanです。
    プレビュー用のハードウェアシェーダはMayaのプラグインなんで何でもやりたい放題でした。
    ファイルアクセスはいつでも厄介なんでなんか対策用意してくれてるかも、mentalray
    知らないんでなんとも言えないですが・・・

    > んー、興味深いので今度是非いろいろお聞かせください。
    Winの同一フォルダに30万ファイル入れるとファイル削除だけで数時間かかるとか、いろいろありますよw

  11. >hohehohe2さん
    > RenderMan
    ですよね。合ってた:)
    > プレビュー用のハードウェアシェーダはMayaのプラグインなんで何でもやりたい放題でした。
    あーーーーー、そういうことですか。
    なるほど。それなら確かにやりたい放題ww
    > ファイルアクセスはいつでも厄介なんで
    どうですかね。なんとなく必要最小限なのでは、と思ってたりします。
    C/C++なんてライブラリ腐るほどあるでしょ!自分で探しなさいよ!の精神で・・・?

    > 興味深い話
    既に興味深いwwwwww
    やはり今度是非ww

  12. はじめまして。
    面白いお話ですね。ついつい自分も気になっていたので書かせていただきます。

    >サイクルのオブジェクト数体をmi連番にしといて、パーティクル動かして外部ファイルに出して、でっかいボックスとかにGeoShaderアサインしてパーティクルとオブジェクトのサイクルデータアサインして、Render!!!!とすればなんとなくいけるのかな。

    僕もこれは気になっていました。
    ただ気になっていたのは、ReadArchiveなどの場合はデータが一方通行であること。
    地面の変化に対応させる場合はReadArchive内データにアクセスできないものなのでしょうか・・

    ILMのジュラシックパーク3の記事でも同じような連番ジオメトリデータをパーティクルの軌跡から選び出してレンダリングしようとしたらしいですが、不自然な為にパーティクルの結果からジョイントを変形しSkinシミュレーションしたジオメトリをRIBで出力し、RendermanのDSOでLOD的な事をしてレンダリングしたと書いてありました。
    これでは結局ジオメトリデータは膨大ですね・・
    共有のジオメトリデータにパーティクルや地形とのインタラクションのプロパティを渡すことは難しいという事なのですかね。。

  13. >ガリさん
    はじめまして。コメントありがとうございます:)

    > 僕もこれは気になっていました。
    > ただ気になっていたのは、ReadArchiveなどの場合はデータが一方通行であること。
    > 地面の変化に対応させる場合はReadArchive内データにアクセスできないものなのでしょうか・・

    これはパーティクルの方で制御すれば良いんじゃないでしょうか、と思ったのですが、場合によるんですかね。

    > ジュラシックパーク3
    なんと。そんな大層なことが行われていたんですね・・・!!
    そもそもパーティクルの軌跡から選べるほどのジオメトリデータって・・・。
    それ作るだけでも大変そうです・・・

    てかジョイント云々てことは、各パーティクルに対してそこそこ最適化されたジオメトリをパーティクルシミュレーション後に作成してレンダリング、ってことなわけですね。

    ぶっはーーーwwwwww
    それ作るだけでかなり手間ですねww
    ある程度ルール決めとかはあって限定的なものなのかもしれませんが、、にしても、、、

    んー、、

    僕はとりあえずパーティクルのローカル空間で滑らない程度のウォークサイクルが出来ればそれぐらいでどうよ、と思っていました。

    少ないリソースで豊かなバリエーションが生まれるならそれは確かにかなり魅力的です:)

    いやー、奥が深い。

コメントを残す

メールアドレスが公開されることはありません。