« 友愛その8。 | トップページ | えびちゃん。 »

2010年7月16日 (金)

マスターコース。

空調屋さんの ICE Kinematics のセミナーに行ってきたんですがね。
講演者は ICE の開発者のひとりでもあり、CAT の生みの親でもあるフィリップ・テイラーさんでした。



結論から言うと、思ったより内容が浅くてがっかり Orz
とは言え、とったメモから無理やり何かを拾い出してみようと思います。




イントロダクションの話は、

・ICE とは、ビジュアルプログラミング環境である。コードを書く代わりにノードをつなげていく。

・Unreal や Shake や Mental Mill など、これまでにもビジュアルプログラミングというものは存在しており、その意味において ICE のコンセプトはは特段新しいものではない。

・ICE では変数を使用しないというのがコードを書くのと大きく違う


とかなんとか。うーむ、軽いメモしかない。っていうかこれ、ICE の話だ。ICE-K の話じゃないよゴルァ





その後、前半はドラゴンのキャラクタを ICE-K を使ってリギングしていく実演でした。ゼロから作る。黙々と作る。くねくねと胴体を波打たせながら羽根も羽ばたく、というループモーションを ICE-K だけを使って作っていくという内容でした。

基準になるのは

  結果の値 = sin ( t + offset ) * amplitude

この式のみ。 これを間接のポジションに突っ込んでいたんだっけ? ローテーションだっけ?

t ってのは時間軸ですね。これで sin波の繰り返しの周期が決まり、offset で時間軸方向にオフセットするってことですかね。 amplitude は sin波を上下方向にどれだけ拡大縮小するのかを決めているってことですよね。

この式だけを元に、全てのパーツを動かしてました。自分でやろうと思ったら全然スラスラとはできないけど、説明聞きながら見ていれば、何をやっているのかは簡単にわかるくらいの内容でしたね。ここでつまづいたらどうしよう、とドキドキしていたので、助かりました。

なにやら、こんな感じの ICETree だったような記憶が・・・。
Kine
Tree が思い出せなくて焦った・・・・
もらった CD-ROM にはドラゴンのデータ入ってないんですよね。
あれ? 後からくれるって最後に言ってたっけ? どうだっけ。 



過去に、タコ・イカの足、クリーチャーの尻尾、イモムシ系クネクネクリーチャーの胴体など、何度かクネクネ系ループモーションなリグを組んだことがありますが、もちろん Expression と Constraint でやってました。今回のドラゴンは、まさに同じ内容を ICE に置き換えたというものでした。つまり基本的な概念はすでに分かっているつもりでして、あとは ICE に置き換えるのがスラスラできればいいわけで、ハードルはさほど高くないと思えましたね。 ま、この程度の内容ならば、という話ですけどね。

また、旧来の方法ではすんごく多くのオブジェクトに Expression を仕込まねばならなかったんですが、ICE の場合は割と少ない仕込みで同じことが実現できそうな予感がしましたが、どうでしょうかね。 実際フィリップさんも 「各オブジェクトに operator があるのではなく、1つの operator(ICE op)からたくさんのオブジェクトを制御できるのがパワフルだぜ」 という意味のことを言ってましたよね。ただし仕込む数が少なくてラクだという話ではなく、op の数が少ないので実行が速い=パワフルだ、という文脈の話だったかもしれません。


sin カーブを元にしているのはその方が扱いがラクだからだとは思いますが、ループモーションでもやはりツメタメが欲しくなる場合が多いわけでして、そういう時って sin に何かを掛けたり割ったりすればいいんでしょうかね? 算数ができない俺はこの辺がダメであります。要は Fカーブの形で考えた時に、ハンドルがブレイクした状態とか、頂点付近が平らな時間がより長くなっている状態とかにするにはどうしたらいいのだろう?
っていうか最初から sin とか使わずに、そこだけFカーブにしちまえばいいのかな。今度やってみよう。


それと今回のドラゴンの例では、ドラゴンのジオメトリがあった上でその骨を構築していくようなものではなく、骨しかないという状態でした。まあ、ICE-K の説明なんだからそれでいいと言えばいいのですが、実務で考えると骨ありきでリグを組むなんてことはあり得ず、必ずモデリングされたジオメトリありきで骨を仕込むことになりますよね。 これまでのように見た目合わせでスケルトンを描いていく方法は、直感的でラクです。それに対し、ICE でやる時は同じようにラクで直感的にできるもんだろうか?という疑問はあります。 特に ICE-K でリギングするには ICETree の中で骨の長さを与えてやらねばならないわけであって、これを ICE のノードの数値スライダ(もしくは手打ち)でやるのがどのくらい直感的なのか。たぶん直感的ではない。それに初期ポーズで骨がナナメに入るべき所はその角度も同じように ICETree の中から調整してやらねばならず、それも直感的ではなさそう。
そうなると、例えば、まずはこれまでのようにスケルトンを描き、その length や rot を自動で拾ってきて ICE のノードにブチ込む、みたいな自作ツールが必須になるのではないか、と思いましたがどうでしょうかね。 あるいはすでにそういう機能なりワークフローなりが用意されているのかな?


あとは実行速度の話として、1つの ICETree から複数のオブジェクトの Kinematics を直接操作すると重い、という話がありましたよね。なのでいきなり Kinematics に Set Data せず、カスタムアトリビュートを作って全ての計算結果を一度格納しておき、それを取り出してから Kinematics に Set Data すると良い、という話だったと思います。 単純に考えると、一度格納してそれを取り出すのだから、工程が増えてかえって重くなりそうな気がするんですがねえ。。。 まあ ICE を作った本人が言うんだから間違いはないでしょう。 「 ICE はその設計上、こういう順番でデータを計算しちゃう。だから遅くなる。その順番で計算させないためには、こうつなげばいい」 みたいな、仕様上の弱点を回避できる tips だと解釈したんですが、合ってますかねこの解釈?



にしても、前日に予習しておいて良かった! まるでテスト前の中学生のように一夜漬けなんですけどね、Users Notes を見て ICE-K をざっとやっておいたおかげで、フィリップさんの話していることは大筋ですんなり理解できました。もし予習してなかったら根本的な所で思考がつまづいてしまって、すんなり入ってこなかっただろうと思います。やっぱり予習必要ですね。



後半は、パイプラインがどうしたとか言ってましたが・・・・概念的な話をごく浅くしただけで、あまり実例を出してもらえず、正直つまんなかったですね。


サムライだか剣士だかみたいなキャラクタを見せてくれたんですが、1週間で作ったリグだそうです。 通常の人間のセットアップはもちろん、腕が伸びてくると自動で鎖骨が動くだとか、足が伸びてくると自動でカカトが上がるだとか、髪の毛が体とコリジョンしながらひらひら動くだとか、その他の揺れ物もやはり体とコリジョンして食い込まないようになっており、かつ移動量に制限を設けて暴れ過ぎないようにしてあるなど、とても良く出来てそうなリグでした。1週間でこれを作るって、かなりすごいんじゃないかな。

このリグは、CAT のリグにとてもよく似ていると言ってましたね。しかも、CAT リグの不具合を修正して仕込んでいるため、実際は CAT より良いリグになっているとか言ってました。ふーん。

でもねえ、まあ、あのリグの細かい解説をされても理解できなかったかも知れないけど、このプレゼンテーションはリグのデモンストレーションを見せてもらったというだけで、アレを見て特に ICE-K の理解が進んだとかアイデアが出てきたというわけではないんですよね。そこが残念でしたね。もうちょっとこう、「お、これなら俺にもできる!」 とか 「アレに使えそうだ!」 みたいな予感を味わわせてもらいたかったんだが、まあこれは俺のレベルがまだそこまで達してないからということになりますかね。


「ビヘイビア」というコトバをキーワードに何度も使っていましたが、これも今ひとつピンと来ていません。 ICE は再利用がラクだ、だが本当に再利用したいものはボーンとかではなく、ボーンがどう動くかという挙動のアルゴリズム=ビヘイビアだ、ビヘイビアは実際のボーン構造とは独立したものであるから、ボーンはキャラごとに再構築し、ただしビヘイビアは再利用する、それが ICE でリギングする利点だ、という主旨の話だと思ったんですが、違いますかね? この辺、あまりに概念的過ぎて、なんだかよくわかりませんでした。眠かった。


また、1つのリグから他のリグへアニメーションを転送するような ICETree を構築できる、つまり ICE-K はアニメーションのリターゲッティングに使える、という話がありましたね。でも実例は見せてもらえなかったような気が。


それと、ICE-K はモーションキャプチャデータのプロセッシング(キャプチャデータをリグの動きとして流し込む)にも使えるから、もはや Motion Builder は要らない! すでにそういうパイプラインを作った、みたいな話をしてましたね。 でも最後の質疑応答でどなたかから鋭い突っ込みを受けて、実はまだ実験・開発中レベルであり、XSI 7 の SDK のバグだかなんだかのために開発はストップしており、実務では実用化されていないということをゲロしてましたねw  ま、そのアイデア自体はとても有効なんでしょうね。なんとか実用化して売り出したらいいんじゃないでしょうかね。


などなど、あまり実例は出てこなくて、ICE-K の活用法の可能性を概念的にお話しました、という印象でありました。




その後は tips 集のような感じ。それほどびっくりするような tips があったわけでもなく、むしろ疑問に思える箇所もあったんですが、とても面白かったですよ。


ICETree を後から自分で見たとき、あるいは他人が見たときに内容がわかるように、ICETree を徹底的に整理しよう! という話をしてましたね。ある規則に従ってノードに色を付けるとか、コメントをちゃんと付けるとか、ウィキペディアなどアルゴリズムの参考にした WEB サイトの URL をコメントに書いておくとか、接続線のスパゲッティにならないようノードの配置を工夫するとか、どのポートに何が接続されているのかひと目で分かるようにノードは畳まない方がいいとか、etc。  美しくノードを並べるために、時には2分や3分かけて執拗に配置を調整する俺は間違ってなかった!と安心しますた。ただしノードは畳んでしまう派です。今のところ。


あとはパフォーマンスタイマーって言うんですか、ICETree 上のストップウォッチみたいなやつですね、あれを使ってボトルネックになっているノードを探し出しましょう、という話もありました。たった1つのノードのためにやたら処理を重くなっているという場合が非常に多いそうで、犯人捜しに活用しましょうということでした。なるほど、これは便利そうだ。使ったことなかったよ。


repeat ノードは重いから使うな! って話でしたが、これは設計上何か不具合があって不当に重くなっているから避けましょう、という話だったですかね? っていうかそもそも repeat ノードって使ったことないです。何をするためのもの?


あと、フィリップさんの場合、1つの ICETree でちゃんと自分の支配下に置いておけるノードの数は約30個だそうで、それ以上の数になる時はコンパウンド化してツリーをシンプルに保つそうです。まったく正しいとは思いますが、俺なんかは全部表に出ていないと不安になるタイプでして、また、コンパウンドにした瞬間にそこがブラックボックス化してしまって、コンパウンドの中に不具合が潜んでいてもそれに気づきにくくなったり、いじるのを躊躇したり、億劫になったりします。なのでまあ、この辺は好みだと思いますがねー。


コンパウンドはバージョンを重ねることができて、内容を修正したら新しいバージョンとして保存しておき、ICETree のノードから右クリックで使用するバージョンを選ぶことができる、という話もありましたね。なるほど。そんなことすら知らなかったよ俺は。 バージョンを変更するべきコンパウンドがシーンの中に多数散らばっている場合は、コンパウンドバージョンマネージャというものがあるそうで、イッキに変更できるのかなこれは。 調べてみよう。




以上、軽いメモと記憶をたどって無理やりまとめてみた感じですね。
正直、フルの値段を払った人や遠方から来た人にとっては、対価に釣り合わない内容だったんじゃないですかね? もうちょっと濃くして欲しいと思いました。

講演者と主催者側との間で、もっと綿密な打ち合わせをすればいいんでないの? ターゲットを絞った方がいいんでないの? などと思いました。 どのレベルのユーザを対象にしているのかがとても曖昧に感じたので。

まずこれは ICE-K の有償セミナーなんだから、ICE そのものの説明は要らん。ICE-K のことに集中してくれ、と思います。 Execute ノードの説明など要らん。黄色の線は Vector なんだよ、とか要らん。Show Value の説明など要らん。 ひたすら ICE-K の話だけをして欲しかったと思います。 まあ、そういう周辺の説明でそれほど時間を食ったというほどでもないと思いますが、要らんものは無い方が話がわかりやすくなって良い。

そして、高額な参加費を払う以上、「ICE-K のさわりを紹介して欲しい」 というレベルではなく、もう一段階上の具体的な成果を求めて参加している人が多いはずだと思うから、思い切ってハードルを上げることも必要だと思うんですよね。 主催者側が参加者にあらかじめ宿題を出して、「ここいら辺までは理解した上で参加してくれよ。それを前提に進めるからな」 という感じでもいいと思うんですよね。 

あるいはあらかじめどういう内容をやって欲しいかユーザにアンケートを採るなど、事前にマーケティングがあってもいいのではないかと思う。 なんだか、内容もレベルも講演者に丸投げしちゃってる印象があるんだよなあ。 そんなことないですか。そうですか。

まあ、先に大まかな内容を知らされてるわけだし、金払うか払わないかを決めるのは俺たちなので、物足りないとかアヤシイと思ったら参加しなければいいだけのことではありますがね。  それにしても後半は物足りなかったなー。 前半で基礎をやって期待させといて、後半ですんげえ具体的な活用法をビシバシ見せてくれてクライマックスか! と思いきや、なんだか尻すぼみに思えました。 ま、私見です。いち参加者の私見ということで許してください。






以下完全にどうでもいい話。



フィリップさん、すんげーたくさんの XSI を同時起動していた。でも 32bit だった。メモリ足りんのか

XSI は 2011 だったが SP1 ではなかった

プレゼンには MacBook を使っていたので、XSI はブートキャンプでやってんのか?と思いきや足元に PC らしきマシンが置いてあった。たぶん XSI は普通に PC 上で動いてます

やはり MacBook なのね。 SIGGRAPH とかこういうイベントの時、プレゼンターはほぼ Mac を使っている印象がある

Windows は英語版で、現在時刻は PM 2:00 頃のはずなのに Windows の右下の時計は AM 1:00 とかになっていた。どうやらフィリップさん、自前のマシンを自国から持ち込んだと思われる。 PC ごと持って来るなんて大変ね

Softimage というコトバも使っていたが、XSI というコトバも何回も使っていた。印象では XSI と言った回数の方が多いような気が

Euler をオイラーではなく、ユーラーと発音していた。 どっちが正しいんですかね? 日本語ではオイラーと言う場合が多いと思うんですが、つづりを見るとユーラーと発音したくなります。 ユーラーで統一しませんかみなさん

会場の椅子は、ヒジ置きが非常に邪魔でした。俺は椅子の上であぐらをかきたいんだゴルァ

会場寒すぎ。 でも先日の六本木での嘔吐デスクのイベントよりはマシだったかな

フィリップさん、シャイなのか、とても優し~い喋り方で、眠くなっちまうのですよ

デコのソリ込みが素敵でした。 不惑のソリ込みと見受けましたが、ほんとは若いんだよねきっと


おみやげは、ぴちょん君扇子ですた。
Img_0101
これが最大の収穫。







.

|

« 友愛その8。 | トップページ | えびちゃん。 »

コメント

Eulerに関してちょっと気になったので失礼します。
Eulerは人名ですのでドイツ語発音でオイラーですよ。
有名な数学者ですので普通に英語でもオイラーと発音すると思ったのですが...

投稿: | 2010年7月16日 (金) 05時38分

名無しさん、そうですか、独逸語だったんですか。エラい数学者だというのはなんとなく知ってましたが、どこぞの人かは知りませんでした。

英語でも大抵はオイラーと発音されていると思います。AREA の SIGGRAPH2009 のマスターコースのビデオを見ると、われらの Bradly Gabe さんもオイラーと発音しています。それ以外にもオイラーと発音するのを何度も聞いています。

今回のフィリップさんはたまたま俺と同じく、独逸語あるいは人名だとは知らなかったのかな。例えば Europe みたいなもんで、英語で普通に見ればユーと発音したくなるのでしょう。俺もその感覚です。euphoria, Eurasia... 俺の知ってる eu で始まる単語はみんな発音ユーだしなあ。金大中を、キムデジュンという人名だと知らなければ、我々日本人はパッと見は「きんだいちゅう」って読んじゃうのと似ている。 Eu がなんでオイなのかわかりませんでした。人名なら仕方ないですよね。その母国の発音が優先されるべきですよね。

とは言え、英語も日本語も Euler の母国語じゃないから、英語や日本語で Euler を発音する時は、英語や日本語として自然に聞こえる発音に変わっちゃってもいいじゃないかという思いはあるな。これがダメなら、俺たち日本語の中で ニューヨーク とか発音しちゃいけなくなる。 ぬぅよぉっク みたいに発音しなければいけなくなるな。 それは嫌だw

投稿: junki | 2010年7月16日 (金) 11時33分

ぴちょん君扇子から匂い立つこれは何の香りなんでしょうか。。。?

投稿: getoo | 2010年7月16日 (金) 16時10分

http://download.autodesk.com/largefiles/jp/seminar/20100610_maya_softimage2011/soft_6.html
オートデスクでのセミナーもう見られたかもしれませんが、ここのICEキネマティクス実演では通常のエフェクタやルートがあるボーンを組んでから
それを階層無しのボーンに変換していますね。
スクリプトでやってるけど、このスクリプトどうやって作るんだ?とか思いましたが・・・・
まあとりあえず一度通常の従来ボーンで身体に位置合わせしてから、ICEボーンに変換するのが効率的みたいなことを言ってます。

投稿: | 2010年7月16日 (金) 19時01分

自分もマスターコース行きました!
やはりjunkiさんもいらっしゃったのですね!
名刺交換したかった (>△<;)

実行速度の話ですが、自分は以下のように理解しました。
マスターコースでの15関節のドラゴンの例では、
ICETreeはオブジェクトのKinematicsに直接値を入れる場合、
1つのボーンに値を入れる場合でもとりあえず15ボーン分計算されるが、
計算結果はそのうちの1つ分しか使用されない。
ということは15ボーン分×15回(ボーン数)の計算で1フレーム225回計算していることになります。
しかし、一度格納して取り出す方式だと
15ボーン分の計算×1回+15回の取り出し作業で1フレーム30回の計算となりますから
(もちろん1ボーン分の計算と1回値を取り出すのが同じ速度ではないと思いますが)
単純計算225回分の処理vs30回分の処理なので、
一度格納後取り出す形式の方が早いのだと思います。

そういえば発音繋がりですが、同時翻訳の方は(も?)『ヌル』を『ナル』って言ってたんですが、
英語では『ナル』なんでしょうか…???

投稿: モチオ | 2010年7月17日 (土) 02時48分

おおー げとーさん、久しぶりです。
ぴちょん君扇子、袋から出した時、ぱぁぁぁっと酸っぱい匂いがしましたね。
夏なのでしかたないと思います。早めに食わないとダメです。
もしくはさすが空調のプロであるD社、エアコンの臭い消し剤のようなものを付着させていたのかもしれません。この扇子で扇ぐとデオドラントな感じ。

っていうかげとーさんもいらっしゃっていたんですか。
声かけて下さいよ。
って未だに顔知らねえ。
御社のプログラマのKさんとは色んなイベントで顔会わせてるんですがねえ。SIGGRAPH も一緒でした。

投稿: junki | 2010年7月17日 (土) 11時49分

名無しさん、自分は新バージョン発表セミナーに行けなかったので、ビデオへのリンク助かります。

今見てみましたが、確かに従来のボーンを描いてからインプリシットボーンに変換してますね。しかもスクリプト使って。 そしてそのスクリプトの提供は無し。 いけませんね。 そのスクリプトちょうだいよ嘔吐デスクさん。 デモで見せたことをユーザが自分で再現できないなら、詐欺デモってことになっちまいますよ。

しかも、インプリシットボーンに変換する理由として、「従来のボーンには、直接 ICE-K で Set Data ができないから」という意味のことを言っていますね。 でも今ちょっとやってみたら、普通に Bone の SRT を ICE-K からいじれましたよ? ううむ、どうなんだろう。 ICE-K で用意している IK のコンパウンドとかを使おうと思ったら従来ボーンはダメ、という意味なんでしょうかね?

いつものことながら、わかりにくいデモだなあ。マークさんのような胸のすくデモを国内でも見てみたいですね。

ともかく、まずは null をボーンとして使って手作業で死ぬほど ICE-K なリグを作ってみるしかないでしょう。するとしくみがだんだんわかり、そして null から作る不便さが身にしみてわかり、そうなると従来ボーンを描いてから変換するスクリプトを書き出すことになるのでしょう。もしくは嘔吐デスクを突き上げてそのスクリプト提供させるか。 AREA なりどこかの WEB フォーラムなり、こういうスクリプトがリリースされてないか要チェックですね。設計上想定されたワークフローを実現するための周辺機能を付けないままリリースし、スクリプトの開発、もしくはその情報を探すなどの負担をユーザに強いるあたりが、実に XSI らしくて良いです。

そういうしているうちに、2012 では null やインプリシットボーンを、まるで従来スケルトンのようにビューポート上で描くことができる機能が付くのかもしれません。

1年後かよ Orz

投稿: junki | 2010年7月17日 (土) 12時33分

モチオさんもセミナー来てたんですか。言ってくださいよ。

>ICETreeはオブジェクトのKinematicsに直接値を入れる場合、
>1つのボーンに値を入れる場合でもとりあえず15ボーン分計算されるが、
>計算結果はそのうちの1つ分しか使用されない。
>ということは15ボーン分×15回(ボーン数)の計算で1フ>レーム225回計算していることになります。

なるほど、そういう意味か。
今回俺、同時通訳無しにチャレンジしてまして、通訳聞かずにフィリップさんの喋りをそのまま聞いていたんですよね。 こういう数字が多く絡む話、1回の計算で○○回分のデータがどうのこうの、みたいな話になると、とたんに理解のスピードが遅くなります。こういう話の部分だけ通訳聞いておけばよかったなあ。

にしてもやはり、「1つのボーンに値を入れる場合でも15ボーン分計算してしまう」ってのは設計上の弱点とでも言うか、決してバグではないですが、十分に賢くない、本来あるべき賢さを備えていない、ということになりませんかね? この部分が賢くなって、必要な分しか計算をしなくなれば、いちいち Array を用意してブチ込むなんてことしなくていいと思うんですよね。 どういうもんでしょう。




null は、ヌルとナルなら、ナルの方が正しい発音に近いと思います。でも日本語のカタカナのナルのような発音ではなく、ナルとヌルの中間くらいのニュアンスだと思います。口の形はウではなく、かと言って大きく開くアでもなく、軽く開くというか、丸い形で半端に開いた状態くらいがちょうど良いでしょう。たぶん。 そして最後はエルの発音なので、舌を、上の前歯の内側にくっつけるとよろしいかと思います。



ちなみに通訳無しに挑戦したため、どうしてもフィリップさんの顔、特に口元を凝視することになってしまいます。俺は最前列にいたんですが、俺があまりにもジロジロと見るのでフィリップさんは不信に感じたかもしれません。俺をゲイだと思ったかもしれません。

投稿: junki | 2010年7月17日 (土) 12時50分

ICE Kinematics用の従来ボーンをインプリシットボーンに変換するスクリプトですが完成しました。
バグなく動いてるようです、一応テストとデバッギング等のために数日おいてから公開しようと思うのですが
XSI道場さんのところってアップロード権限は管理人さんだけでしょうか、投稿できない感じなので
もしよろしければXSIユーザーに広く知られてるJunki様の所で配布して頂ければと思ったのですがいかがでしょうか?
なるべく多くの方に使っていただければと思いまして・・・

投稿: hayase | 2010年7月18日 (日) 14時12分

なにーーー

junkithejunkieアットgmailどっとcom までメール下さい

hayase さんありがとうございますです

投稿: junki | 2010年7月18日 (日) 18時07分

完成次第送らせていただきます。
こちらこそお願いを聞いていただきありがとうございました。
どうかよろしくお願いします。

投稿: hayase | 2010年7月19日 (月) 00時45分

hayaseさん、お待ちしておりまっせ
クレジットは hayase さんのみでいいのかな。
ま、詳しくはメールで。

ありがとうございますです。

投稿: junki | 2010年7月19日 (月) 12時17分

メール送信しました。
よろしくお願いいたします。

投稿: hayase | 2010年7月19日 (月) 19時15分

先ほどのは送信エラーになってたのに気がつきました・・・。
今度こそ送れてると思います、よろしくお願いします。

投稿: hayase | 2010年7月19日 (月) 21時53分

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: マスターコース。:

« 友愛その8。 | トップページ | えびちゃん。 »