もしかすると近い未来、リグツールキットみたいなものを作らないといけなくなるかもしれないので、ちょっと考えておきます。
個人的には今後未来永劫あまり触りたくない分野ではあった、、、
いやいや考えるだけなら楽しいから全然OKなんですが、実際に手を動かしたくはなかった。
何故ならタスク的に超劇重だから。
ほかのことが出来なくなっちゃうもの！
まぁでも食うためにはなんでもやるぜおいら。
ということでざっくりアイディアまとめてみたんだぜ！
とりあえず、この辺とかで触れているように、以前参加したMasterClassのメタノードネットワークの仕組みは間違いなく取り入れたいです。
これ相当のものがないと、頭の悪い僕としてはデータがまとめらんないんです。
ざっくり俯瞰的にデータの把握がしたい。
となったらメタノードネットワークに勝る方法を今は思いつきません。
良いものはパクる！！
これです。
また、僕は自分でスクリプト書いたりするのが大して苦痛だと思わない人間なこともあって、スクリプトで全部構築出来るようになっていてほしいとも思います。
というか僕が育ったリグツールキットは、完全にコマンドライン専用だったんですね。つまり関数群というか。
前の会社ではセットアップ＝スクリプト書く、という感じでした。
かなりゴリゴリ書いていたものです。
なのでコマンドラインというかスクリプトベースという性質自体は外したくないのです。
GUIでサクサク、ではないので比較的大規模向けなのかもしれませんが、ベースを用意するとか、コピーしてくるとか、まぁ対処方法はいくらでも思い浮かぶのでなんとでもなります。
今となっては選択肢はPython以外ありえないと考えています。
まずインスタンスを作成、モデルを読んで、ウェイトデータを読む。
さらにベースの骨を読んで、それに対してあれこれ行う、みたいな感じでセットアップスクリプトを書きたい。
もちろん手作業を排除するということではなくて、ベース骨の作成だとかウェイト塗りだとかは最初に通常通り手作業でやってしまいましょう、ということです。
そういうところのヘルパーは後回しでOK。
リグ構築に必要なのはルールであり、そのルールに乗ればザクザク作れてしまう、というのが良いなと思うのです。
なのでリグを作成する際にAPIとして公開するものは、出来る限り簡潔に書けることが重要だと思っています。
ここで言う簡潔さは読んでわかるという方向に重きを置いた簡潔さです。
たぶんフルにOOPで行った方が綺麗にまとまると思うので、pymelなどの使用も視野にいれておきたいです。
話がちょっと前後しますが、メタノードネットワークはPythonとすごく相性が良いと思っています。
メタノードは作り方にもよりますが、大体は各ユニットごとに存在するものです。
例えば腕、足、背骨、etc…
これらのユニットは、一つのクラスとして表してしまえば良いと思うのです。
といってはみたものの百聞は一見にしかず。
本当にざっくりですが、例えばこういう記述になるのでは？というPythonコードを以下に書いてみます。
便宜的に、リグツールキットはrtkという名前にしておきます。Rig Tool Kitってことで、、、
import rtk
ch = rtk.Character()
# import data
ch.importModel('Z:/path_to/model.mb')
ch.importSkel('Z:/path_to/skel.ma')
weights = ['weight1.txt', 'weight2.txt', 'weight3.txt']
ch.importWetights('Z:/path_to_weight_dir', weights)
# create rig
ch.createArm('jointArmL1', 'jointArmL2', rtk:STD_HUMAN_ARM)
ch.createArm('jointArmR1', 'jointArmR2', rtk:STD_HUMAN_ARM)
ch.createSpine('jointC1, 'jointC2', rtk:STREACH_HUMAN_SPINE)
ch.createLeg('jointLegL1', 'jointLegL2', rtk:CARTOON_HUMAN_LEG)
ch.createLeg('jointLegR1', 'jointLegR2', rtk:CARTOON_HUMAN_LEG)
ch.construct()
こんな感じ？
あくまでも例えばですけど、どうでしょうか。
個人的にはなんかまだイマイチな感じだと思いました。
余分な記述が多いというか。
まだまだ詰める必要はありそうです。
まぁアイディアのアイディアということで、、
あとリグツールキットといえば、ロケータなど、自前のノードを多用するようなものもありますが、僕は出来ればそれはしたくないと考えています。
何故なら著しく可搬性を低下させるからです。
バージョンが同じMayaさえあればどこでも動く、そういうものが良いなと思っています。
セットアップされたキャラとツールは、出来るだけ分けて考えたい。
とはいえ、いずれロケータ作りたい病にかかったら、プラグイン突っ込むと思います。
でもそれによってインストールが面倒になるのも嫌なので、ツールをモジュール化するなどで対処するかもしれません。
が、なるべく要らんノードは入れたくないと思っています。
あとは比較的自由なセレクター用GUI、ってのも欲しいです。
これは前に作ったPuppetManみたいなものをイメージしています。
どれほど便利かはわかりませんけども、個人的なモチベーションとして:P
と、大体このぐらいでとりあえずこれでリグツールとしてのベースのアイディアは固まった気もしますが、それだけでは使う人を選びすぎてしまうので、GUIをのっけたりして、比較的簡単に使えるようにしたい、とは思っています。
が、多分最初はAPIをメインにおいて考えると思うので、GUIはまぁ後で、って感じでしょうか。どうやって実現するかも多々ありそうですし。
個人的にあまりリグの経験値が高くないこともあり、細かいノウハウはそんなに持ってないのですが、やるならちゃんとやりたいです。
でもとりあえずは限界まで逃げたいと思っていますｗｗｗ
ただAPIというかツール自体の設計は面白そうなので通勤時間のネタとして考えてみようと思います。
GUI絡まないと思えばずいぶん楽。
ちなみにツールキット作ることになったら、名前はDOLLsにしようと思っています。
名称自体シンプルだし、カッコつけすぎてないですしね！！！
本当は裏の意味があるんだけど:P
そんな感じで。考察的駄文でした。
- Newer: Maya2010
- Older: Sony Pictures Imageworks、オープンソース開発プログラムを発足
Comments:16
- hohehohe2 2009/08/03
面白そう、この辺一番好きですねー♪
- tai 2009/08/03
＞hohehohe2さん
気をつけないとすぐにリグ専門スタッフになってしまいそうです・・・！！これの他にフェイシャルだの何だのというものもあるので、まだまだやることは多そうです。
とりあえず概要だけ、重要なポイントだけでもまとめたいです。
- ガリ 2009/08/03
面白そうですね！大変興味があります。
紹介頂いたMetaRiggingToolkitはもうDLできないのか、確認できませんでした。残念。
という事でメタノードネットワークというものがイマイチ内容がわかっていないのですが・・ｗこれは手足などの端末のコントロールを一括管理するノードを作成するということですか？？ちがうか。。
PRSやScriptなど複雑な数々のアトリビュートなどを簡潔にすると？？スイマセン。。よかったら詳しく聞かせてください。
しかしレンダリング周り好きな方がこれに手を出すと本当に専任になりそうですねｗ
メンテナンス的な部分も含め- @h 2009/08/03
g○○○○xｗｗｗｗｗ
最近、リグについて考えてるのは、
ワークフローベースのUI設計とか
ノードベースリグとかですね←（Mayaだと大変そうだけど。。。）今、コマンドラインベース使っているんですが。。。
リグ専門にやってない人にとっては
敷居が高いと感じています。
今後はリガーが増えてって欲しいと思ってるので
リグの敷居を下げる必要があるかと考え中ですコマンドベースでリグを作り直せるところは非常によいと思ってるので
コマンドをGUIから呼び出すみたいなUI設計を考えて、間取る設計がベストかと- あきを 2009/08/03
個人的にはリグは色々なセクションと絡むモノなので
設計思想優先でいって、周りの人間とのコンセンサスが取れていないと問題が多くなると思います会社によってベストな方法は違うので
他社での成功事例、前会社での経験がそのまま適用出来ないのが難しいところですねプロダクション単位でのトライ&エラーで育てていく
ことが大事だと思います- ガリ 2009/08/03
あきをさん＜全く同感です。
が、問題意識も感じます。
ある程度共通認識があれば外部アニメータを契約した際にもすぐに作業できていいなーっとかよく思います。
海外は人員が流動的なのできっと自然とどのスタジオのRigも似てる常識があるんだろうと想像しています。時々聞く問題で、アニメータが悪いのか、Rigが悪いのかと言う話があります。
でしゃばり過ぎないRigも大事ですし、テクニックを頼りにし過ぎないアニメータの自覚も大事だと思うので一般的に作業境界線があるといいのかなっとか思います。でも仕事内容が違うわけなので、やはりトライ＆エラーで育てていくんですね。きっと。
- tai 2009/08/03
おおお
反響がすごいみんなリグ好きですね！このっ！ニクいよ！（？）
＞ガリさん
メタノードネットワークはですね、僕は情報の整理のしやすさが一番のウリだと思っています。たとえばArmLに対して1個のメタノード。メタノードはメタノードで階層（というかただの接続関係ですが）を持ち、メタノードを見るだけでそのリグの概要が理解できる、というイメージです。
もちろんそれだけでもないのだとは思いますが、個人的にはDGが毛玉みたいにこんがらがることのない素敵な仕組み、と理解しています。詳しくはどこかからMasterclassのデータをGETして読んでみて下さい（・・）ﾉｼ
＞@hさん
まぁわかります。
ただやはりAPIも直接触るという思想で作らないとイカンと思っています。
GUIでガワかぶせるのはまぁ時間かければできますし、比較的楽ではあると思います。ベースさえあれば。
というかこのエントリー書いた後、GUIとCUIの双方向から行けるアイディア思いつきました。
要はコマンド手書きしてもGUIで操作しても、APIに食わせるための中間データなんですね。
妥協することなくシンプルにして敷居が下げれたら最高ですねー。＞あきをさん
> 個人的にはリグは色々なセクションと絡むモノなので
> 設計思想優先でいって、周りの人間とのコンセンサスが取れていないと問題が多くなると思います
仰る通りだと思います。
ただ今回書いたものはまだパイプラインに至る前の段階のものだと思いますし、既に存在する実働部隊を想定したものでもありません。
なので！仰るような各セクションとのコンセンサスとかはこの後で良いのかなと。
まだアイディア段階なのでいろいろ角が立ってるぐらいでいいかな、なんて:Pやはりこれもあきをさんの仰るとおりで、プロダクション、及びプロジェクトレベルのトライ＆エラーが必要だと思っています。
＞引き続いてガリさん
> 海外は人員が流動的なのできっと自然とどのスタジオのRigも似てる常識があるんだろうと想像しています。
そういうものなんでしょうか？
僕が今まで見て来たリグは大体開発者の思想丸出しなものばかり、な印象です・・・！！
海外が特別違うというようには思えないのですが、どうなんでしょうね実際。リグも現場のアニメータの意見やプロジェクトの内容によって流動的に変わるものだと思うので、やはりトライ＆エラー！ですね！！
- J 2009/08/03
グラディウス的なリグを頼みます。
ﾉｼ- ガリ 2009/08/03
＞僕は情報の整理のしやすさが一番のウリだと思っています。
なるほど。。ありがとうございます。
以前Processingのビジュアライジングデータという本を買ったんですが、情報の視覚化、角度を変えた視覚化というのは凄く興味があります。
Rigの中に埋もれたデータをメタデータを使って簡潔にアクセスという意味でもとても良さそうですね＞海外が特別違うというようには思えないのですが、どうなんでしょうね実際。
スイマセン。よくわからないまま発言していますｗ
そうですね。。内容は様々なので実際は違うんでしょうか。。
ただ、プロジェクト契約で移動するアニメータは多い気がするので、そうなるとRigも必然的に常識的な作りが似てるのかなーっと思った次第です。
海外Rig知りたいです！！！以前ILMのアニメータの方のお話を伺った時は、シーンファイルをみんなが見れる環境なので、テクニカルアニメータの人が作った仕組みを勉強したい人は、広げてみてみて勉強できるっと言っていた気がします。
たしか・・
うろ覚えですが・・
羨ましい環境です。。- tai 2009/08/04
＞Jくん
そこだけ書いたら全然わからんでしょｗｗｗｗｗ＞ガリさん
ビジュアライジングデータ、そういう意味で見れば確かにそうですね！
ただこれはあくまでも僕の意見というか、感想というか、です。
メタノードになってたらモジュールとしてみなしやすいので、オブジェクト指向的にあれこれできるカナという気がしています。＞海外リグ
どうなんでしょうね、実際。
個人的にはみんな好き勝手に作ってるとは思いますが、一般的なコントロールはみんな同じようにつけてたりするのかなと思ってます。僕が今まで一緒に仕事をしたアニメータは大体どんなリグでもさくさく仕事してました。
ただ彼らが優秀だっただけなのかもしれませんけども:Pシーンファイルぐらいは日本でも見れる環境にあるんじゃないでしょうか？
というかシーンファイルを読んでアニメーションつける訳なので。。- ガチャペン 2009/08/05
あれ、リグだけは絶対興味ないと思ってたのに（笑
できるだけプラグイン使わずに完成度高いのができるとうれしいんですけどねぇ・・・
俺は逆にウエイト塗ったりブレンドシェイプ作ったり、ツール郡を使って実際にセットアップする方に興味があるんで、ツール作るのは誰かに任せちゃいたいです。基本は押さえつつ、後からいくら増設しても汚くならないのが理想かもです。
- tai 2009/08/05
＞ガチャペンくん
そうそう、興味ない。全然触りたくない。
未来永劫関わりたくない。それが僕とリグの関係です（えー
まぁ1厘ほどは冗談として、、（えーーーーー
> プラグイン使わず
そうですね。そう思いますよ。出来る限り標準機能が素敵、と思ってます。> 後からいくら増設しても
まぁ、増設するもののタイプによるのかなと思いますけどね。
この辺はルールの決め方と実際の使い方、使われ方じゃないですかねー。- inagaki 2009/08/09
うちの会社では２足歩行も４足歩行もまったく同じリグを
使っていて、特殊なキャラ以外は基本的に再利用してます。
バインディングとかデフォーメーションに時間をかけられる
ようにしてるみたいです。自分の修士論文がオートリグだったので、参考までに
自分の作ったものを紹介します。体のパーツごとにリグをパーツ化して好きなパーツを
選択自由に可能にしました。それぞれのパーツが親となれる
トランスフォームノード、親を求めているノード、子のFK
フォローのスペースになるノードを最終的にディクショナリに
保存するようにして、GUIの方でユーザはディクショナリの
キーのリストからどのパーツのどの部分をどのパーツにのどの
部分につなぐというのを自由に選択できるようにしました。
よく使う組み合わせとか毎回パーツをつなぐのも面倒なので
組み合わせたものをpickleを使ってファイルに保存できる
ようにもしてます。ファイル読んでジョイント位置を調節して
１クリックでモーションシステムは完成します。詳しくは、自分のウェブサイトのデモリールの４番目に
入ってるので見てもらえれば参考になると思います。
意見等もいただけるとうれしいです。- tai 2009/08/17
＞inagakiさん
> ２足歩行も４足歩行もまったく同じリグ
あれ、なにやらどこかで似た話を聞いたことがある気がします。
inagakiさんのところもそうだったんですね。
実際どうなんでしょうか、何も問題ないんですかね。
例えば背骨の数とかルートの位置とか、、って書いててなんとでもなる気がしてきました。
コントローラでどうにかしたりとか出来そうですね。
なるほどー、そこは一緒でいいのか、、、> バインディングとかデフォーメーションに時間をかけられるように
なるほど。確かに見栄えってそこが重要ですもんね。
必要な手間暇というか。
僕が一番苦手な作業、、、
苦手というか嫌いというか、、、> 自分の修士論文がオートリグだったので
お、あのリグシステムは修士論文のものだったんですね。
ここで書いているリグシステムは、inagakiさんのものを意識しているではないんですが、結果としてかなり似たものなのかなと思っていました。
というか以前見た時点でかなり影響を受けていたのかもしれません、自然と似てしまいました:P
結局は雛形を再利用可能にしたい場合に一番良い方法って何かなと考えたら、こういうことなんじゃないかなと。こちらは実際に稼働しているのでしょうか。
もしほったらかしになっているのなら、是非オープンソースとかにして頂いてですね、みんなでこれを強力にしていく、とかも素敵じゃまいかと思います:)
もちろんオープンソースにするのには決心いるので無理にとは言いませんよ！これにさらにセレクタのGUIつけるとか、パーツのバリエーションを増やすとか出来るようになると素敵ですねー:)
- inagaki 2009/08/21
オープンソースですか？全然OKなんですけど、
今ソースを書き直し中で、新しいコードは
公開できる状態じゃないんですよね・・・
ある程度まともに動く状態になったら公開しますよ。
今ちょっと忙しいのでしばらくかかってしまうと
思いますけど・・・
パーツを増やすのは割と簡単にできると思います。
一応パーツを増やしてもメインのGUIをまったく
いじらなくてもいいようになっているので。
パーツのクラスにジョイントの位置調整用の
仮ジョイントを生成するコードとかを書かないといけない
んですけど、Maya上でジョイント作って、それを選択して
ボタン押したら、そういう面倒くさい部分のソースコードを
吐き出してくれる、ツールとかも用意したいんですよね。
やりたいことはたくさんあるんですけどね。- tai 2009/08/22
＞inagakiさん
おおお！オープンソース化期待してます:)しかも何やらいい感じです。。
さすが本職CharacterTD！すばらしいです。
リグツールはルール決めるのが一番大変なんじゃないかと思ってますが、そこまで整備されてるんであれば今後の拡張や修正はそこまで手間じゃないかもしれませんね！期待期待！