- 2009/05/11 09:34
- CG
今興味のあること、今後実現させたいことを思いつくままに。
●レンダリング環境の統一。
ソフト間でレンダラが統一出来たらいいなと思う。
今のところ最有力なのは3Delightじゃないかと思うけど、Vrayも使い勝手やライセンス面から魅力的。
mental rayはー・・・どうなんでしょう。
押さえたいポイントは、
・高品位のレンダリング
→金かける以上、当然。
・拡張性
→シェーダ開発など。普段から頻繁にやれるかどうかは別として
・使いやすさ
→自分でツール書いてカバー出来るとかなら全然OK。難易度にもよるけど。
・パイプライン的観点での使いやすさ
→例えばRenderManだからといって常にRIBが出てほしい訳ではなかったりする。
3Delightの場合メモリに展開してレンダリング出来たりとか、今までの使い方を崩さずに使える。
もちろんRIB出してレンダリングするのも可能。
（これはmental rayもある程度同等の事が出来るのでは、と思ってますが、如何に。）
これらはつまり、MayaとHoudiniとか、MayaとXSI（というかICE）が使えたら色々とやりやすいなと思うから、です。
Mayaはそれだけで完結してしまうのと、他のツールと組み合わせるのとでは発揮できる力が違いすぎる気がする。
制作のメインとして使うツールであると同時に、ツール開発のフレームワークと考えるのが良さそうだというのが最近の考え。
あれだけ開発環境の整ったプラットフォームだし、やはり有効に活用したいわけです。
●Maya用メタノードネットワーク式リグフレームワークの開発。
メタノードネットワークは以前のMasterclassのネタ。
これをやることでネットワークはかなり整然とし、見やすくなる。
いろんな用途に使えそうだなと思ったけど、やっぱり特にリグ構築に向いている仕組みだと思う。
それの構築を、フレームワークを組んだ上で行えるようにすることで
GUIからの構築、スクリプトからの構築に対応出来るようにしたい。
もしかしたらスクリプトじゃなくてもいいかもしれない。独自のファイル形式を作る必要はあると思うけど:P
メタノードネットワークの性質上XMLなんかも相性いいかも、とは思う。
オープンなフォーマット使うと誰が見ても内容明らかになるし、それはそれで良さそうな気が。
●DBを介したパイプラインツール
言ってみればAlienbrain的なものになるんだろうと思う。
あそこまでの完成度を持たせられる訳が無いと思うけど、自社限定という考えで見れば
汎用性にかける部分があっても良い訳なので、ある程度はいけるかも。
結局スケジュールとかそういうのって、PMや制作進行がいても
ある程度以上のサイズのプロジェクトではたまにとっ散らかっちゃう部分があったりして。
それが追いきれないのはもはや仕方ないことだと思うんだけど、Maya使ってデータは操作してるわけなので、
そのタイミングで何かしら出来ることはあると思うのです。
DBを介した〜、というのは、多分WEBとも同期させたりとかしたくなると思うため。
そうなってくるとやっぱりDBが良さそうかな、と。
でもそんなに本気でサーバー立てて、とかしなくてもsqliteで全然イケる範囲だと思うんです。
あくまでもDBのこととか全然わからないド素人の意見ですが、なんとなく。
—
大体こんな感じです。
まだまとまってない部分ありますが、おおよそ。
結局何がしたくてこんなことを考えるかというと、やっぱり手動メインではいろいろ手間が多すぎる。
これは省けるだろ！みたいな手間はどんどん省きたい。もちろんそれはすべて最終クオリティのため。
そうなっていくとやはりある程度しっかりしたシステム、環境は必要で。
ただそういうものはいきなり言われても思いつかないものだと思うのです。
もし、「もっと効率的に仕事出来るようなシステム提案して。予算と時間はこれだけ。」と言われたらどうするか、
というイメージで自分の中でいろいろ考えてみてます。
まだ具体的な予算とか時間とか見積もってませんが、ぼんやりイメージだけ。
結局普段の制作において、ボトルネックになる箇所、面倒を感じる箇所は大体決まってる気がします。
なのでそこは幾分でもカバーしたい。
自前の何とかツールみたいなものは、こういうベースとなり得るものが固まってから、という気がしています。
もちろん簡単なものはボコスカ作ってけばいいと思うんですが。
今回僕が関わっている仕事ではここまでのことは全然無理でした。
というのも最初にDBを使ったシステムを考案したりしていたのですが、手間以上に使い勝手が悪すぎると感じていて、
結局担当者が辞めたのでそれを引き継いだ僕はほぼMayaベースのシステムで諸々組んだのです。
今までの使い勝手を継承したい、それでいてなおかつ面倒は省きたい、と思ってやったのですが、
やはり一発目から全てをカバーするのは無理で、責任を感じる箇所も多々あります。。
結局他の人に頼ってたりとか。
なので今後はこの反省を生かしてあれやこれややりたいな、と思っています。
が、リグに関しては僕はおよそ1年以上のブランクがある＆今後リグに力を入れたいとも思っていないという節があるので、
もし興味あれば誰か開発してみませんか。
アイディア出しぐらいなら僕も力になれると思うんですが:)
自分のやりたいことをやるために、自分で環境を整える努力をする、という姿勢や行動は嫌いじゃないので、
おそらくどこに行こうがこういうことはやると思います。
超絶に整った大規模スタジオだと出る幕ないかもしれませんが、、、ｗ
状況を変えようともせずに忙しい現状を嘆くばかりはしたくないなと思っています。
もちろんシステムでカバー出来ることには限界があるものだと思いますが、やらないよりはやった方がね。
そんな感じ。
- Newer: こんなの見つけた
- Older: Pixar to open Vancouver studio
Comments:10
- ますお 2009/05/11
日本のプロダクションで，という事になると，予算やら時間やら人材やらって話が絡んできて，
話が相当ややこしくなってしまうと思うんですが，個人的な意見として書かせてもらいます．最終的にはどのくらいのレベルの事がやりたいかに依存するとは思うんですけど，
レンダラを統一するにはレンダラに渡す情報（例えばマテリアルとかテクスチャ）をツール間で統一する，
つまり抽象化しておく必要があるので，パイプラインとして開発しなければならない物がとても多くなります．
レンダラ側でもそれを解釈するための仕組みを自前で作る必要があります．
DBを使ってasset managementとimport/exportの仕組みを作る場合も同じです．候補として3Delight，v-ray，mentalray，それとPRManを考えた場合，開発と言う観点から見れば
一番自由度が高くて間口が広いのはmentalrayです．ただしその分難易度は高め．
次が3DelightとPRManが同じくらい，と言いたいところですが，実際にはPRManの方が少し上，
それにRSL2.0に対応しているのは今のところPRManだけなので，3Delightはその点で劣ります．
v-rayはパイプラインに組み込むような開発環境はまだ揃ってないです．組み込みが基本というイメージ．お手軽と言う意味ではv-rayが一番，次が3DelightとPRManですかね．mentalrayは使いこなせれば
とても強力ですが，そうでなければいい結果を出すのは結構大変です．開発と使い勝手のバランスが一番取れてると思うのはPRManです．
PRManはやはり映画を作る，という目的を持って生まれてきたレンダラだと思います．
やりたい事が楽にできる場合が多い．その分制限がありますけどね．でも，シェーダを含め，
開発無しで使い物になるレンダラじゃないです．
上でも書きましたが，3DelightはRSL2.0非対応なのが決定的に劣る．あと，どのレンダラを使う場合もそうですが，レンダリングはstandaloneで使えるものがいいと思います．
シーンファイルはレンダラネイティブなasciiフォーマット，つまりPRManなら.rib，mentalrayなら.miを
使うのがいいです．全てメモリ上でやってしまうのはお勧めしません．
一番の理由は，シーンのデバッグがしやすい事．あとは効率と安定性と拡張性を損なわないためです．こういう部分はホントに「やってみないとわからない」所だし，それぞれのプロダクションの環境にも
深く依存するんで，こっちのスタジオでもそれぞれやり方が違って一長一短ありますから，
決定的に正しい答えってないんですよね．- tai 2009/05/11
＞ますおさん
おおおおおおおおお
早速貴重なご意見ありがとうございます。んー、、、なるほど、思った以上にやらなきゃいけないことは多そうだし、大変そうですね。。
3Delightはついこの間アップデートがあって、RSL2.0に対応したようですよ。
http://www.3delight.com/en/ますおさんの仰ることはほぼ納得できるんですが、やはりPRManは予算面で現実的ではないだろなという感じがあります。
同様に、miやRIBを全出しするのも、ストレージの容量の問題からなかなか厳しいんじゃないかと思っています。
片っ端から消すとかすればいいかもしれませんが、それじゃオンメモリと大差ないような、という気も。
もしかしたらこれは効率的に運用する方法があるんじゃないかとも思うので、それが出来るなら非常に嬉しいところです:)V-rayは手頃で使い易い分だけ、パイプラインの軸に据えて何かを行う、というのは厳しいんじゃないかと思っています。
ただこれはライセンスが現実的な価格設定なんです。
V-rayを選ぶとすれば、ライセンスの価格が1番の決め手になるんだと思います。
専門的なスタッフ（＝TD）の少なさ、というのもV-rayを選ぶには十分な理由ではあるんですが。おそらくこれを突き詰めていって、ますおさんの考えられているようなレベルのものに到達するには、人もお金も時間も全く足りないです。
そもそもウチでも今は僕しか考えてないし、やれないし、やらないｗｗｗ
ただ、今僕が直面している環境はおそらく想像以上に悪くて(笑)、開発なしじゃ全く使えないというようなものですらずいぶん使えてしまうんじゃないかとすら思います。だからまずは第1歩を考えたいのです。
最初はもしかしたら3ライセンス、いやいや、1ライセンス買ってもらえたら良いほうかもしれません。
それでもやっぱり実際に使って、でも全然使えなくて苦労して、その中で使い方を覚えて行って、もしくは新たに見つけていって、結果出してもっとそこを深くやれる時間とライセンスを貰って、と少しずつ進むしか道は無いと思うのです。
もちろん常に見据えるのは先の先なんですが、進めるのは足下の道だけなので、、今だと結局いつもMayaSWとmental rayを使って、マスクあわないところはコンポでなんとか、みたいなことが多いですし、まぁそれはそれでなんとかなってるのかも知れませんが、デジタルデータを扱ってるのにデータロスしたけどどうにもならないみたいな話に納得し続けるのも嫌で、なんとかしたいなと思うんだけど自分の実力不足も手伝ってどうにも出来なくて、、というスパイラルからそろそろ抜け出したい気持ちがすごく強いです:P
ハリウッドは金が、時間が、という前に自分達でも努力はすべきだと思うのです。
日本だってこの業界出来てから何十年か経ってるわけで、その時間があればやれることだって多かっただろうと思うんです。
やらなかっただけ、という事実から顔を背けてたらそろそろ日本のCG業界終わりです。とにかく今の自由度の少なさから脱却したいし、良い絵を作りたいわけです。
良い絵が出来ないのは僕自身の実力不足が原因だろ、って話もあるんですがとりあえず棚に上げておきます:Pってもうますおさんにはこんなネット上のスペースじゃなくて直接お会いしていろいろお話聞きたいです！ｗｗｗ
いつも貴重なご意見ありがとうございます。- ますお 2009/05/11
あ，ホントですね．3DelightはRSL2.0対応か．んー，でもやっぱり諸々考えてPRManかなあ．．．（予算度外視で）
先のコメントでも書きましたが，こういう話は環境に依存するんで，それぞれの状況とリソースにあわせる事しかできませんよね．10人が開発に参加できる場合と一人しかいない場合では，レンダラの決定を含め，デザインすべきパイプラインの全体像は全く違ってくると思います．パイプラインと言うのは，作るだけではなくて作った後のサポートまでがパイプラインですから，作ってもサポートができないと全く意味が無いわけで．
レンダリングを3Dアプリ経由でキックするのは百害あって一利なし，だと思っています．
.ribや.miをキープするのは確かにストレージ的に問題あると思うんで，レンダをキックする時は，スクリプトからmayaファイルをバッチモードで起動，レンダラのシーンファイルをtempに出力，それをstandaloneなレンダラでレンダリングするようにするのはどうでしょうか．で，スクリプトのオプションでシーンファイルをキープできるようにしておけば，何かあった時にデバッグしやすいと思います．前に書いたような，publishしたジオメトリをレンダラ側でロードするような仕組みが作れればレンダラのシーンファイルは相当軽くなりますけど，これは付随する開発量がかなり多くなるんで，開発リソースが少ない環境では難しいだろうと思います．
近々帰国の予定はありませんけど，siggraphには行くと思います．そこで会えたら嬉しいですね．
- tai 2009/05/11
＞ますおさん
む、PRManを選ぶ理由はやはりいろいろあるわけですね。
高すぎてそもそも選択肢にいれられない現状、悲しすぎますorz> 先のコメントでも書きましたが，こういう話は環境に依存するんで～
仰るとおりです。
なんとなく今のスタジオの環境を思い浮かべて考えてました。15～25人前後のMayaメインのスタジオ、って感じです。
となると開発に参加できるスタッフの人数というのもある程度自ずと見えてくるのかなと・・・> レンダリングを3Dアプリ経由で～
ですね、、やはり出来ればやりたくないことは間違いないです。> レンダをキックする時は，スクリプトからmayaファイルを～
おっ、それは良さそうですね！
この程度ならPythonとかで、RIB出し→Renderまでやってくれるスクリプトとか手軽にかけそうです。
あとはtmp以下もオプションによって残したり消したり出来る、と。
良い感じです:)> publishしたジオメトリをレンダラ側でロードするような～
そうですね、まさにこういうことが出来るとかなり運用もしやすくなるのかなと思いました。
正直ジオメトリの情報まで全てASCIIにしておく必要がどれだけあるのか疑問だったというのもありますし、シーンの情報とジオメトリの情報がきれいに分けられるのも嬉しい限り。
でも仰るとおり、開発リソース云々、という話になってしまうわけですよね:(
難しい・・・> Siggraph
Siggraph、CG業界5年もいながらまだ1回も行ったことないんですよねー。
うううう行ってみたい。
多分僕の場合気が狂うほど楽しめるんじゃないかと思ってますｗｗｗ- syoyo 2009/05/11
んー、レンダラ周りであればいろいろ求めているソリューションは提供できそうですねー. 某レンダラ周りでいまいろいろ動いていますので.
対価はそうですね、tai さんの若い貴重な時間をいただくという方向で検討したいと思います :-)5/20 日の RenderSan に来るのであれば詳しく話します :-)
- tai 2009/05/11
＞syoyoさん
おおおおっ！なにやら興味深い！！
某レンダラｗｗｗ即バレますｗｗｗｗｗ
> 対価
若い貴重な時間ｗｗｗ
内容わからないとどう使われるのかが分からなすぎて怖いですよｗｗ> RenderSan
是非是非行きたいところなんですが、タイミング的にかなり微妙かも、です。。
平日ですしねぇ。。
あああああなんとかならんものか！もし無理でも近々、夏ぐらいには是非お話を :D
- @h 2009/05/12
別のレンダラーに変更できる、ワークフロー作りましょー♪
モデル→リグ→アニメーション→ライティング→シミュレーション→レンダリング。まで全部考えないといけんですが、
なんとなく僕の頭の中では実現可能な気がしてます。
紙に落とすのと、
小規模に実験ができたらよいなぁとは思ってるのですが。
まぁそれにはもう少し時間が必要ですかねぇ- tai 2009/05/12
＞@hさん
や、出来ますよ。
ただ使わせる相手のことを考えないと意味はないので、
もうちょっと状況考えて柔軟に、と思います。
いろんな方向考えられるんですけどねー、どれが一番いいのやら:(- rva 2009/05/13
今年のSiggraph Asia行こうぜ！
- tai 2009/05/13
＞rvaくん
突然何なんだｗｗｗｗｗｗｗｗｗｗｗｗ
もちろん行くし、出来れば会社に金だして欲しいわｗｗ