0-1 スライダでブレンド。

すいません、ただのメモです。　いつかまたジタバタしそうなのでメモです。




任意の２つの値を 0-1 のスライダを使ってブレンドするというアレです。



今回の場合は、骨の長さでした。

最終ボーンは　Ｃ　です。　

このボーンＣの長さ (length) は、ボーンＡ　と　ボーンＢ　に影響されます。　0 - 1 のスライダで影響度（ウェイト）を決めます。

ボーンＡＢの length は、固定値とは限りません。つまりアニメーションされるかも知れないということです。





というような時に、上記のようなエクスプレッションを書けば上手く行きました。　上手く行ってるように見えます。　合ってる？　　これでいいですよね？



スライダの値が 0 の時は　Ａ　の影響が１００％（Ｂは０％）、スライダが 1 の時はその逆で　Ｂ　の影響が１００％（Ａは０％）　という仕様です。


１の時にＢの値になるわけだから、Ｂの部分は、そのまんまスライダの値を掛け算してます。

０の時はＢの影響はゼロになってＡの値になるのだから、Ａの部分は　（　1 - スライダ値　）　を掛け算しています。

その結果を合算したものが最終結果として　Ｃ　の length にセットされます。

上の画像の例だと、Ａの length が 2 です。　B の length は 4 です。　そしてスライダは 0.75 になってます。 B に偏ったウェイトです。

式は


　　A * ( 1 - スライダ )    +    B * スライダ　＝　最終値

ですので、

　　2 * ( 1 - 0.75 )    +    4 * 0.75    =    3.5


という結果になりました。 　2 と 4 の間で、4 へ向かって 75% のところにある値が 3.5、ということになりますでしょうかね。　合ってる？

これ、今回はボーンの長さに使ったけど、何にでも使えますよね。 他のソフトウェアでも使えるはずですよね。　必死にメモですよ。



こんなの、おそらくは基本的過ぎて、テクニカルな人は普通に体に浸みついている、あるいは必要なときにこの計算式なりしくみのイメージが瞬時に湧いてきてすぐに作れるのでしょうけどね、　俺なんかは紙に計算式書きながら１０分なり１５分なり考え込んで、やっと作るわけですよ。




だから将来のカンニングのためにメモですよ。






.

骨同士のコンストレイン。

最近うっかり間違えてヘンなセットアップにしちゃって苦労したので、一応確認したいのですがね。



ボーンをボーンにコンストレインするとき、Pose コンストレインにするか Orientation コンストレインにするか、という話です。　主に、同じ構造のチェインが複数あって、ボーンが常にコンストレインでぴったり重なっていて欲しいという場合を想定しています。

先に結論から言うと、２ボーン以上のチェインでは、Ori コンストレインにした方が良い。　ということになると思うのですが、どうでしょうか。

この図では、２ボーンのチェイン（ルート、ボーン、エフェクタから構成されるスケルトンセット）が、３つあります。　１つ作って複製したものなので、３つとも完全に一致したチェインです。

スケマティックを見ると分かりますが、どれがどれだか見分けが付くように、色を付けてあります。　緑色のチェインはコンストレインの親になる、マスタチェインです。　赤と青はコンストレインされる側、つまりスレイブチェインです。

で、このようにコンストレインしました。

赤い方のチェインは Pose コンストレインです。　青い方は Ori コンストレインです。

この状態でマスタのボーンを動かせば、スレイブ側の赤も青も、ぴったりついてくるって思っちゃうじゃないですか。　Ori の方は角度でコンストレインしているし、Pose の方は角度も含む全てでコンストレインしてるわけですから、どちらでも問題ないような気になっちゃうわけです。

でもそうじゃないんですね。

ほら。

これはマスタ側のエフェクタを動かした場合、つまり IK で動かした場合ですが、赤い方がズレているのが分かります。　rotx がおかしい。　つまりアップベクタ的な、ねじり方向の回転がズレますね。

FK でも動かしてみましょう。

FK で動かす、つまりマスタ側のボーンをローテーションで動かしているわけですが、やはり rotx　つまりねじり方向の回転がついて来ないですね。

上手く説明できないのですが、Pose にしちまうとポジションでも拘束するため、２つ目のボーンのポジション拘束が優先されて、１つ目のボーンの角度の解決に問題が出るとか、そういうことなのでしょうかね？

Ori の方は何ら問題ありません。　角度の値をそのままマスタからコピーしているだけ、という感じですよね。　角度以外のことを考慮してないので、矛盾が起きようにないという感じでしょうか。

なんか説明としては上手く行ってない気がしますが、結果的には、このような場合は Pose コンストレインは避けて Ori コンストレインにすればいいという結論で、よろしいでしょうか？　　ダメ？　　どなたか説明して下さい。

今回ね、ここを Pose のままやっちまってたんですよ。　で、アニメーション作業の途中でどうしても腕の挙動がおかしくなってしまうので、　あれ～？？？　おかしいな～～？？？　と色々解析しているうちに、どうやらこれで解決するらしいと分かったのです。　合ってるかなあ？

俺の場合何に使ってるのかというと、キャラクタの手足の FK / IK ブレンドです。　IK / FK をブレンドあるいは切り替えするときって、皆さんはどういうセットアップにするのかなあ？　教えて下さいよ。

俺のセットアップは、一応ブレンドが可能（つまり IK から FK へのスムーズなトランジションが可能）であり、パーツ数が多くなるという意味で無駄が多い気もするけど昔から問題は起きないというか、一応堅牢に動いてくれている気がするセットアップですね。　今のところこの仕組みが好きだな。１０年くらいこれでやってるような気が。

例えばキャラの腕を駆動する普通の２ボーンチェインがあって、その２ボーンチェインを２個複製し、合計３個にします。　今回の例と同じです。　１つめはエンベロープの駆動用、つまり最終ボーンです。　最終ボーンは、残り２つのチェイン両方に Ori コンストレインされています。　２つのうちひとつは、IK で動かすチェインです。もう片方は FK で動かすチェインです。　最終ボーンはこの２つどちらにもコンストレインされ、その２つのコンストレインのウェイトをスライダで動かせば、スムーズなトランジションができるという仕組みです。　２つの IK/FK チェインは、それぞれコントローラに接続されて動かされます。　IK / FK のブレンド値スライダは、カスタムパラメータなどにしてしまいます。




とかなんとかです。
なんか間違ったこと言ってたら指摘して下さい。
っていうかあなたのやり方教えて下さい。





なぜかここ最近 XSI 仕事が途切れず、Maya 様への移行が進みません。　神の思し召しでしょうか。　もう少しの間、こうして村で野良仕事をやることにします。

.

カーブデフォームはX。

これも長年不満だったんですが、あっさり解決してしまったので・・・・。



カーブデフォームの不審なロールのことですよ。


こういうやつ。



XSI 男がカーブに沿って気持ち良さそうにスウィングしてますが、変なロールが入ってるの分かりますか。綺麗にエビ反りになるのではなく、ひねりが入ってるというか、回転してしまっている。不審なロールです。



他の分かりやすい例で言うと、例えばキャタピラみたいなものを作る時にカーブデフォームを使ったとしますよね。　まあキャタピラじゃなくとも何でも同じなんですけどね。　で、オブジェクトはちゃんとカーブに沿ってくれるのはいいんですが、カーブの接線方向を中心とした軸で変な回転が入ってしまうわけですよ。　ロールですね。　　カーブがＸＹＺ全方向にぐねぐね曲がっていたらしようがないにしても、キャタピラの履板オブジェクトを沿わせるのに使う目的だと、キャタピラは左右に波打ったりしませんから、カーブは平面になりますよね。　ＹＺ平面に沿った平面カーブ。　それでも、ロールが入っちゃうんです。

このように。




しかも、きっちり９０度とかのロールであれば、カーブデフォームの PPG の中でロール値を補正してやることもできるので問題ないんですが、半端なロールなので、正確には補正できない。　今までは、ロールがほぼゼロに見えるよう、Roll の値に微妙な数値を入れながら見た目で修正してました。非常に不満でした。

長年これに耐え忍んできて、先日とうとうブチ切れて、っていうか聞いてみりゃいいじゃんって思いついて、空調屋さんに　「どーなってんのこれ。アフォですか」　って言ってみたんですよ。　そしたら、まあ謎仕様ではあるんですが、綺麗に解決できちゃったんですね。




方法は簡単なんですが、


　　カーブデフォームのカーブは、ＸＹ平面に描け。


以上。



上のキャタピラの例で言うと、例えば戦車やブルドーザなどキャタピラがあるものを作るとき、普通は車体を　Ｚ　方向を向かせて作りますよね。　車体の前後方向がＺ軸です。　そうなると、キャタピラは　ＹＺ平面のカーブ　に沿うことになりますよね。　なので、横のビューからキャタピラの形にカーブを描きます。


　ＹＺ平面。
　これがいけなかった。


カーブデフォームの内部仕様が公開されているわけではないので理由は分からないけれど、ＸＹ平面でカーブを描けば、変なロールが入らないのです。　ええっ　マジっすか空調屋さん。　




ほんとだ・・・・。

長年使ってきて、全然気づかなかったよ orz


ってことで、XY平面で描いたカーブでデフォームすれば、変なロールは入りません。　フロントビューで描けばいいわけですね。　間違ってサイドビューから描いてしまっても、９０度回転させてローテーションをフリーズすればいいだけのこと。

最終的な形はもちろんＹＺ平面のカーブに沿ったものにしたいわけですが、ＸＹ平面のカーブを描いた後にカーブをＹ軸に９０度回転させてやれば望みの方向になるので問題ないです。　Ｙ９０度というローテーションの値が入るのが気に入らないなら、ヌルなどで親でも作ってそこから回転させるか、ニュートラルポーズを使えばよろしい。　ちなみにカーブデフォームの PPG で Constrain to Deformer のチェックはもちろんオンである必要があります。　それがないとカーブをＹ軸９０度回転させたときに着いて来なくなるから。


変形させられる方のオブジェクトの向きは、まあどうでもいいと思います。デフォーム後に意図した方向になってなくても、９０度単位で補正すればいいだけなので、カーブデフォームの PPG の中で Roll の値をいじってもいいし、元のオブジェクトのセンターを９０度回転させてあげてもいい。ＸＹ平面のカーブであれば半端な数値のロールにはならないんだから、９０度単位できっちり正確に補正できます。　以上。　解決。





いやあ、まだ知らないことだらけです XSI。
知ってました？　
知らないのは俺だけですか。

空調屋さんいつもお世話になります。
マニュアルにも書いてないのになんで知ってんですかこんなこと。





いえ～～い

チェインアップベクタさんの殺し方。

またやっちまった。今日もこれで４０分くらいは失ったね。　このクソ急ぎの時に限ってこれだ。

メモりますよ。チェインアップベクタのぶっ殺し方です。


よくある腕や足などの２ボーンのチェインなんかで、最初のボーンにチェインアップベクタを設定するじゃないですか。　で、なんらかの都合でアップベクタをやめたときに、一箇所いじり忘れると挙動がおかしくなったまま、そしてそれに気づかずどうしてこんなヘンな動きをするのだろう俺はどこかいじって壊しちゃったかななどと大騒ぎすることになるのです。俺何回もやってます。



まず、チェインアップベクタを設定すると何がどうなるかと言うと・・・・

ボーン以下の Kinematic Joint プロパティの下に、SkeletonUpVectorOp が出来ますね。　歯車アイコンです。つまりオペレータ。　毎フレ計算してその都度結果をアップデートするようなものがオペレータですね。

そしてもうひとつ。Kinematic Joint プロパティの PPG を開いて、Resolution Plane タブを見るとわかりますが、Res,Plane というパラメータが、デフォルトでは Default という値だったのが、チェインアップベクタを実行すると自動で Up Vector という値に変わっています。

このように、オペレータの降臨と、Res.Plane の値を Up Vector に更新するという２つが、チェインアップベクタを実行したときに得られる結果です。　この２つというのが重要。

ちなみに、Res.Plane が Up Vector になっているということは、「ボーン自身・エフェクタ・ボーンから見たあるベクトルで示される１点」　という３点を結んだ三角形を仮想的に設定し、ボーンをその三角形の平面上でしか動けなくする、とういことをやってるのだと思います。　そして　「あるベクトル」　というのが、ユーザがピックしたアップベクタオブジェクトのポジションです。　そしてこのオブジェクトと、この Res.Plane への接続を担当してくれているのが、つまり接続先を保持しておいてくれるのが、上記 SkeletonUpVectorOp だと思えばいいんじゃないでしょうかね。　　違ってたら指摘して下さい。




んでね、これからアップベクタを削除するわけですが、アップベクタの削除って、皆さんどうやってますかね？　　「チェインアップベクタの解除」　なんて機能は、ないですよね？　ね？

なので、アップベクタオブジェクトを削除してしまうか、アップベクタオペレータを削除する以外に無いと思うんですが、どうですか？　　何か知っていたら教えて下さい。

んで、そのどっちでもいいからやります。　アップベクタ先のオブジェクトを消すか、SkeletonUpVectorOp を消すのです。　アップベクタ先のオブジェクトを消したら自動的に SkeletonUpVectorOp は消えてくれます。　SkeletonUpVectorOp を消したときは、当然アップベクタオブジェクトは残ります。　物は消さずにアップベクタの効果だけなくしたいときはこちらがいいですね。

ってことで、こうやって消したら、めでたくアップベクタ抹殺完了・・・・・ではないのですね。　　２つありましたよね。　オペレータの降臨と、プロパティの中の Res.Plane の値です。　この２つのうち、オペレータの降臨の方は、オペレータを削除あるいはアップベクタオブジェクトを削除したことによるオペレータの消失で、クリアできています。　でもプロパティの中の方は、自動では更新されないわけですよ。　先ほどの Up Vector という値がそのまま残っているわけですよ。

これに気づかずにボーンのエフェクタをつかんで IK で動かしたりすると、挙動が不審になります。いや、不審ではないんだけど、動かしづらくなります。思ったように動いてくれない。　それは、Res.Plane が Up Vector になったままだからです。　ボーンはあくまでもここで指定されたベクタを使ってレゾリューションプレーン（上記の三角形）を生成してしまうのだと思います。　もはやアップベクタオブジェクトは無くなっていても、値を Up Vector のままにしている以上、このプロパティ内で指定された数値でプレーンを作れと言っているわけですからね。

ってことで、ここを Default に戻します。

これでめでたく、通常の挙動になりました。 おしまい。

まとめると、

チェインアップベクタをぶっ殺すには、

・アップベクタオペレータの削除（アップベクタオブジェクトの削除でも同じ）

・Kinematics Joint プロパティの中の Resolution Plane タブの Res.Plane というパラメータの値を Default に戻す

この２つをやらないと元に戻ったことにはなりません。
という話でした。

いっつも忘れるんだよこれ。

.

Reassign Locally は Group ピックも桶。

いや、別にどうというアレではありません。

XSI でエンベロープの作業していて、Reassign Locally を実行しようとしたんだけど、デフォーマの数が多くてしかもあちこちに散ってしまっているため、ピックする時に Group に対してピックが効いてくれるといいなあ。　と思ったんですよ。　あらかじめ目標にするデフォーマを Group に集めておいてピックできれば楽じゃないですか。　そして最初にエンベロープを設定するときは Group でＯＫじゃないですか。　だから Reassign の時でもそうだといいなあ。　と妄想してやってみたらできました (゜∀゜)。　

なかなかやるじゃない～ XSI さま。　そういう細かいところで使い易くできているいい子ちゃんのソフトウェアだと勘違いしそうになります。　もちろん勘違いです。

そう言えば Reassign Locally に関しては、ミケルくんがこんなビデオで語っていてくれたりしますね。

Workflow Tips - Speedy Enveloping from TD Survival on Vimeo.

なにやら俺の XSI 男への偏執も語られていて非常にびっくりしたのですがそんなことはどうでもよく、ええとすいません、ちゃんと中身は見たけど俺、実はこのビデオのポイントをよく理解できていません。

最初にエンベロープを設定した時、XSI 様が自動でどのポイントがどのデフォーマにどれだけ追随するかを割り振って下さるわけですが、その割り振り先の選び方が超すっとこどっこいだから全部シカトして手で Reassing し直そうぜ！　という話をがポイントなのでしょうかね？　そして、それをやるのにショートカットとか使ってこんな風にクイックにガンガン進めようぜ的な？　　違ってたらどうか指摘して下さい。

仮にそうだとしたら、はいそれは全てを自分のコントロール下に置こうとする態度なわけであって非常にスヴァらしいのですが、しかし場合によっては全部を Reassign するのは非常に勇気が必要な時もあります。　デフォーマがやたら多くて複雑で、かつメッシュもそれなりにハイポリの時など、できれば割り振り先の配分などは考えたくない、デフォルトの割り振りやそれに Smooth をかけた程度で済ませたい、どうせこいつモブキャラだし。　みたいなヘタレな気持ちでいることも多いですからね。



ヘタレでも上手く行くエンベロープ講座みたいなのを熱望します。もうほんと、俺はヘタレでどうしようもないです。　ウェイト調整なんて、ほんと、できれば自動でババっと終わってくれないかしらという作業ですよ。　XSI ではエンベロープってしばらく大きな進化がない分野の気がしますね。デュアルクォータニオンはどうなんだろう。　最近全然未チェックです。　

なんというかこう、インタラクティブで直感的で楽ちんに綺麗にウェイトを割り振れるインターフェースが欲しいですよね。　デュアルクォータニオンのような別のアルゴリズムでのスキニングもいいけれど、別に今のままリニア補完なスキニングでもいいから、ウェイト調整を劇的に楽にできる操作体系、選択方法、表示オンオフシステム、みたいな、スキニングのための専用環境みたいなのが欲しい気分です。　（使ったことはないけど）Face Robot みたいな感じでもいいのかな、XSI の内部にあるスキニングのための専用モードみたいな。



ところで、ちょっと使い過ぎるとフニャフニャで節度のないヘタレエンベロープになるので自制しながら使わねばならないエンベロープの Smooth 機能ですが、手作業ウェイトで荒れた配分をなんとなく滑らかにしてくれるのでついつい手が伸びてしまいます。　ウェイトにガウスブラーかけてるようなもんだよねこれ？


で、Smooth をかけるときに、「このデフォーマは考慮に入れてくれるな！」　っていう指定、できましたっけ？　

Smooth って、周囲のデフォーマとの間でウェイトをぼかすことによって突出した配分を減らし、より多くのデフォーマから少しずつ曖昧に影響を受けるようにする、みたいな感じだと思うんですが、この時に、「このデフォーマだけは Smooth の対象に入れずに無視してくれ、このデフォーマだけは Smooth 後も影響はゼロにしたいんだ」　みたいなこと、できたらいいなあと思うんですよ。　できましたっけ？　　知っているお方がいらっしゃいましたらどうか御教示下さいませ。　　







久しぶりにスキニングしたのでなんだか色々忘れてるですよ。　そしてこの作業が終わると、また１年とかスキニングなんてしないんだろうなあ。　スキニングなんて、一切発生しない仕事の方が多いですからね。　　こんなのばっかしですよ俺。　ICE も同じ。　ちょっといじって、次に仕事で使うのは半年後とか。　身に付かないですわ～ orz





.

シンメトリマッピングテンプレート作成が少し楽にまりますた。

いや、だいぶ楽になりますた。

エンベロープになるメッシュが複数あって、それぞれ違うデフォーマを持っているという状態が前提です。　ゲームモデルとかだと違うかも知れないけど、映像系は、ということになるのかな、俺なんかが扱うデータはこういうパターンの方が圧倒的に多い。　


で、エンベロープウェイトのミラーコピーのために Symmetry Mapping Template を作ろうとすると、複数オブジェクトの選択を受け付けてくれず、しかたなく１つだけ選択して実行すると出来上がったテンプレートにはそのオブジェクトにとってのデフォーマしか登録されてくれず、他のオブジェクトのデフォーマは手動で Insert Rule していかないといけない。


これどうにかならんのですかｵﾙｧ。　

と言ったらアサクラさんがいいアイデアをくれて、実験してみたらすんなり上手く行ったので、忘れないうちにメモというアレですよ。





でもごちゃごちゃ書くの面倒だから例によってビデオです。

アサクラさん、すげえ感謝します。
どのくらい感謝しているかは、ビデオを最後まで観て頂けると伝わるのではなかろうか。




んー、　いつものことですが説明が冗長ですいません。　なんでこんだけのこと説明すんのにこんなに時間を費やしてしまうのだろう orz　　　まあいいや、どのみち撮り直すつもりなどサラサラ無し。


歌はもちろん一発撮りですよｗ　　上手いとか下手とかの問題ではないですから。などとちょっとだけ照れ隠しの開き直りをするフリをして、実は最近色んなことがどうでもよくなっちゃって恥ずかしいとか思わないのが問題ですな俺は。







っていうかね、シンメトリマッピングテンプレートの操作が面倒すぎるんですよね。あの Insert Rule ってほんとに使いづらい。　現在選択中のものからポンポンと登録していくような機能があってしかるべきだと思うんですよ。　ある程度自動で L と R を予測して対応させることすらできる、なかなかよくできた機能なんだから、ユーザビリティの方にもうちょっと気を遣ってくれればスヴァらしいツールになるのにねえ。　まあ、そんなの XSI らしくないので無理ですが。










さあさあ、マトモな曲行きましょう。

歌もギターもいいですねえ。
こんな風に演れたら、気持ちいいだろうなあ。

俺も少年時代から、舞台の上で演るような妄想だけはずっと持っていましたよ。　この二人は、その時が来るのを長いこと待っていたそうですが、待っていたよ言うよりはたぐり寄せたんでしょうかね。どうなんでしょうかね。夢を叶えるってスヴァらしいですね。　この歌は、夢を叶えて行く途中のドキドキワクワク感、まじっすか本当なんですか夢じゃないっすよねコレという感覚、　すごく良く出ていて、なんつうか微笑まざるを得ないとでも言うか、そういう魅力的な歌だと思います。

俺も１６歳に戻れるなら、ロックスターを目指しますよ。 JNK48 とかビッグバンドなんてどうですかね。　いや、今からでも遅くないかな。　たとえ売れなくてもＣＧよりは楽しそうだ。






ともかくアサクラさん感謝します。





.

アップベクちゃんご主人様捜索。

こいつのアップベクタ先はどのオブジェクトだっけ？　という話ですよ。

シーンが複雑になってきて、ボーンの Chain Up Vector 先のオブジェクトが行方不明ということはよくあります。　人から渡されたシーンならなおさらですね。　もちろんスケマティックビューで接続線の先を探すこともできますが、もしも接続先のスケマティックノードが畳まれている状態だったらその線は表示されませんし、畳まれていなかったとしても横に長～いスケマティックになっていたりすると線の接続先までたどり着くのは大変だし、そもそもスケマティックビューを使わないなどというふざけた若僧が多いわけです最近は。



そういうふざけた若僧を甘やかすつもりはまったくありませんが、ともかくもアップベクタ先を見つけるのがめんどくせえ。　そう思ってました。




もしもチェインアップベクタがいわゆるコンストレインの種類であれば、Constrain > Select Constraining Objects で一発で選択できるし、スクリプティング的にも Constraint オブジェクトの Constraining プロパティからたどり着けます。　でもチェインアップベクタって、コンストレインじゃないんですよね。オペレータです。



↓Explorer で見ても、歯車アイコンですよね。歯車アイコンはオペレータです。　ICEオペレータとかと同じ。



Kinematic Joint プロパティの下に存在するオペレータです。



俺、このオペレータというやつをよく分かってなくて、今までスクリプト書くときもなんとなく踏み込まないでいた領域だったかも知れません。　でも今日、作業していたシーンが複雑になってきて、アップベクタ先がわかんなくなって大いに混乱し、最後にはモニタ２個を室伏のようにぶんぶん振り回して窓から放って世界新を出してしまったので、しかたなくスクリプトで出来ないか調べてみました。　なんか、以前にもこんなスクリプトを書いたような気がしないでもないんだが、その記憶も曖昧で。




で、やってみたら、そんなに難しくなかったように思えました。　できました。

いや、ほんとはちゃんと分かってないので、そんなこと言えないんですけど。　どうやらちゃんと動いているっぽいから、たぶん大丈夫だろう、くらいの状態です。






------------------------------------------------------------

//    アップベクちゃんご主人様捜索

//    先に Chain Up Vector Operaror を選択中のオブジェクトから全部かき集める
var oUpVectorOps = XSIFactory.CreateObject( "XSI.Collection" );
for ( var i=0; i<Selection.count; i++ )
{
    //    安直に GetObject で取得。　たぶん "XXX.joint.SkeletonUpVectorOp" しかあり得ないと思うから。たぶんね。
    //    false 付けておかないと、目的のものが見つからなかった場合にエラー吐いて止まるので、false 必須です
    var oSkeltonUpVectorOp = Dictionary.GetObject( Selection(i).fullname + ".joint.SkeletonUpVectorOp", false );
    if ( oSkeltonUpVectorOp )
    {
        oUpVectorOps.Add( oSkeltonUpVectorOp );
    }
}

//    かき集めたオペレータをループして、拘束先を取得
var oUpVectorMasterObjects = XSIFactory.CreateObject( "XSI.Collection" );
for ( var i=0; i<oUpVectorOps.count; i++ )
{
    var oOp = oUpVectorOps(i);

    //    UpVector の場合、InputPort は常に１つしかないと思う。たぶん。　なので InputPorts(0)で大丈夫だと思う。たぶん。
    //    InputPorts(0)で Port オブジェクトを取得し、Target2 メソッドで拘束先である Kinematics.Global が取得され、
    //    Parent3DObject プロパティでその３Ｄオブジェクトを取得できる。　たぶんですよたぶん。
    var oTargetObject = oOp.InputPorts(0).Target2.Parent3DObject;
    oUpVectorMasterObjects.Add( oTargetObject );

    //    情報表示
    Str = oOp.Parent3DObject.fullname + " ( " + oOp.Parent3DObject.type + " ) -- UPV --> ";
    Str += oTargetObject.fullname + " ( " + oTargetObject.type + " )";
    Logmessage( Str );
}

//    かき集めた拘束先３Ｄオブジェクトを選択しておしまい。
SelectObj( oUpVectorMasterObjects );

------------------------------------------------------------





オブジェクト（ボーン）を選択して実行します。　すると、アップベクタ先のオブジェクトが選択された状態になります。存在していれば。

チェインアップベクタ専用です。　それ以外のアップベクタって何種類かあるのかな、普通のコンストレインの中のタブにもアップベクタがあるしよくわからんけど、ともかく、ボーンに対して行う Chain Up Vector しか考慮に入れてません。

一応、よくわかってないなりに、スクリプトの説明をしておきますね。




まず、チェインアップベクタというものの正体は、SkeletonUpVectorOp という名前のオペレータであるという所から始まります。　チェインアップベクタを実行すると、ボーンの Kinematic Joint の下にこのオペレータが発生しますね。　はい、まずはオペレータであり、 Kinematic Joint 以下以外には存在しないという存在パターンがつかめました。　存在パターンが限定できるってのは良いことです。取得が楽だからです。

そして、リネームしようとしても出来ない。　これまた実に好都合です。　リネームできるかどうか試してみるクセを付けるといいですね。　この場合は、出来ませんでした。　つまり、Kinematic Joint 以下に SkeletonUpVectorOp という名前で存在すればそれはもうチェインアップベクタのオペレータを指しているということですから、取得するのは簡単です。　


ってことで安直に、


　var oSkeltonUpVectorOp = Dictionary.GetObject( Selection(i).fullname + ".joint.SkeletonUpVectorOp", false );


このように書けばいいことになります。たぶん。たぶんですよ。　取得したいブツの名前が分かっている時は Dictionary.GetObject の呪文が楽です。

ただし、false を入れるのを忘れてはいけません。　もしアップベクタが無いボーンを選んでいた場合や、ボーン以外の、つまりチェインアップベクタがそもそも存在できないオブジェクトを選んでいた場合は、もちろん何も取得できません。　そしてこの false を忘れると、何も取得できなかった時にエラーで止まってしまいます。　これはよろしくありません。　

false さえ付けていれば、何も取得できなくてもエラーが出ません。　代わりに null が入ります。　なので次の行で null かどうかを調べれば取得できたかどうかが分かります。


ってことで、

　　if ( oSkeltonUpVectorOp )

こう書いていますが、

　　if ( oSkeltonUpVectorOp != null )

こう書いているのと同じ意味です。 null じゃなければ、つまりアップベクタオペレータを（スクリプティング的な意味での）オブジェクトとして取得できていれば、次が実行されるわけです。

次にオペレータの接続先を探すわけですが、ここでやはり大きなヒントになったのは、SDK Explorer でした。　スクリプトで未知の領域に踏み込むときは、まずはなんでもいいから SDK Explorer を開いて端緒をつかみます。　意味わかんなくても端緒さえつかめれば、芋づる式に出来ちゃったりしますから。


ってことで、SkeltonUpVectorOp を SDK Explorer で調べてみると・・・・

あっ

Hage 発見！　(ﾟ∀ﾟ)

自分でアップベクタ先に指定したオブジェクト　Hage が、ちゃんと出ているではありませんか。　まさにこいつを取得したいわけですよ。　アップベクタを仕込んだボーンから始めて、この Hage にたどり着きたいのです。


そして見てみると、InputPorts の Target という所に載っていますよね。　これこそが端緒です。　俺は InputPorts も Target も意味を知りませんでしたが、この InputPorts だか Tartget だかというキーワードさえ見つかれば、あとは SDK ガイドで該当ページやそこからリンクが張られている周辺のページをごちゃごちゃ見てみれば、だいたいなんとかなったり、ならなかったりします。　今回はなんとかなりました。　いつもこうやって調べています。



で、まだちゃんと理解はしてないですが、どうやらオペレータというものには InputPort というものがあるらしい。　オペレータにとってのインプット、つまり何らかの情報を受け取るポート＝窓口なんでしょうね。　この場合はアップベクタですから、アップベクタとして指定したオブジェクトのポジション情報がオペレータの窓口 ＝ InputPort から入って来ると考えることができると思います。たぶんね。

InputPort はオペレータによっては複数あるようです。　そりゃそうですよね。パッと思いつくのは、例えば Extrude Along Curve などはカーブ２つから作るわけですし、Merge なんかも２つ以上のオブジェクトから成り立つわけですよね。　

ってことで InputPorts というプロパティがあり、結果は Collection です。　コレクション、つまり複数です。　たとえインプットが１つしかないオペレータでも、取得できるのは Collection です。　なのでそのうちから、目的のポートを１個特定しないといけない。


しかし上の SDK Explorer の画像を見るとわかりますが、SkeltonUpVectorOp の場合は InputPort が１つしかないんですね。　ほうほう。　こりゃ楽でいいわ。　


ってことで、


　　Operator.InputPorts(0)


と書けば、コレクションの中から、目的のポート１つをもう取得できたことになります。コレクションとして返って来てはいるものの、１つしかないともう分かっているんだから、最初の１個（０番目）を指定すればいいということです。



で、ポートオブジェクトが取得できればポートオブジェクトに対して効くメソッドが全部使えるようになってますから俺はもう自由です。大空に羽ばたきます。


ってことで、Target2 というメソッドを使ってポートの接続先を取得します。


　　Operator.InputPorts(0).Target2


この Target2 というメソッドもよく知りませんでしたが、SDK Explorer で Target と書いてある部分に目的のオブジェクトの名前（Hage)が載っていたもんですから、　ははー　どうやら Target という何かがあるらしいぞ　　と想像がつくわけで、そこまで想像できればあとは SDKガイドでうろうろしてるうちにどうにかなりますから、大したことはありません。


ただし、こうしてたどり着いた Target は XXX.Kinematics.global というものでした。プロパティですね。　ヌルなどの３Ｄオブジェクトそのものではなく、３Ｄオブジェクトが持つプロパティです。　アップベクタオペレータにとってはそのブツの 「ポジション」 がターゲットになるわけであって、ポジション情報というのはこの Kinematics.Global に格納されているから、Target2 で取得できるのは Kinematics.Global オブジェクトである、という風に考えていいんじゃないかと思います。

ここでは Kinematics.Global オブジェクトが取得できているので、こいつに対して使えるメソッドやプロパティは全部使えるようになっているわけです。もう俺は自由です。大宇宙に飛び出します。　


ってことで、Parent3DObject プロパティを使います。


　　Operator.InputPorts(0).Target2.Parent3DObject


こう書いて、ようやく３Ｄオブジェクトにたどり着きました。　




あとは、情報を表示したり、たどり着いた３Ｄオブジェクトをコレクションにブチ込んでおいてあとでまとめて選択する、という処理を書いているだけです。

ってことで、ほんとにこれでいいのかな。　アップベクタ先の取得の仕方として正しいかどうか、実は自信がないんですが、一応今のところ想定通りに動いているように見えますよ。




いろいろ不正確かも知れませんなあ。
オペレータ弱いです俺。　スクリプトオペレータもよくわかりません。


ツッコミお待ちしています。

ごきげんよう。

.

ctr_dist と this_model の和解。

先日の ctr_dist と this_model の軋轢についてなんですが、何人ものお方が実験に協力して下さいましてですね、ひとつ方向性が見えた気がしますので、いったんベイクしておきます。　

まず、現象として、


　　ctr_dist の中で this_model が使えなかった


というのは、実験してくれた人のおそらく全員で再現しました。　少なくとも、勘違いやオペレーションミスではないということになると思います。

ただし。

ctr_dist の中の pos の部分の書き方を変えると、 ctr_dist の中でも this_model が使えるということがわかりました。

つまり、pos の部分が前回の書き方の場合だとＮＧだということです。そこさえ書き直せば使えます。

順を追って説明します。

前回の書き方は、

　ctr_dist( this_model.Man_A, this_model.Man_B )

こうでした。　Man_A, Man_B という風に、オブジェクトの名前で終わっていました。この書き方だと、this_model を使わなければ問題ないが、this_model を使い始めた瞬間にエクスプレッションがセットされないということがわかりました。

次に、

ctr_dist( this_model.Man_A., this_model.Man_B. )
ctr_dist( this_model.Man_A.kine.global.pos, this_model.Man_B.kine.global.pos )


この２つの書き方を試してみましたが、やはり同じく、エクスプレッションはセットされませんでした。

前者は、オブジェクトの名前の後ろにピリオドを置いたものです。 こう書けとマニュアルにも明記されています。　でも this_model があるとガン無視されました。

後者は、global.pos です。　タテとかヨコだけじゃなく、２点間の３Ｄ空間的な距離を求めるので、X や Y などの特定の軸を記述せずに pos で終わっています。　これも this_model が無い時には問題ないのですが、this_model が入るとガン無視です。

しかし。



ctr_dist( this_model.Man_A.kine.global.posx, this_model.Man_B.kine.global.posx )



このように、posx まで書くと、this_model があってもちゃんと効くようになりますた！！ (ﾟ∀ﾟ)


pos でやめてはいけなかった。

posx まで書かなければいけなかった。

なぜ？

なぜかはわかりません。

観察から挙動がわかったというだけで、理由まではわりません。ともかくそうなんです。





しかしこれだと、posx と軸を限定して記述しちゃってるんだから、２点間の距離と言っても、X 軸方向の距離しか取得できてないんじゃないの、Y 方向とかに動かしたらタテの距離は考慮されないんじゃないの、という気がしますよね。


でも、やってみたら、posx と書いていても、X軸に限らず Y も Z も考慮した正しい２点間の距離を取得できていることがわかりました。

どうやって実験したかと言うと、カスタムパラメータを作り（別に必ずしもカスタムパラメータである必要はないのですが）、そちらには this_model を使わず、しかも posx ではなく pos で終わっているか、あるいは pos すら書かずに Man_A で終わっている書き方で ctr_dist を記述しました。　つまり、this_model を使ってないため何も問題なく動作することがあらかじめ分かっている書き方で２点間の距離を取得したのです。　そしてその結果は、posx まで記述した場合と完全に一致しました。







ということで、結論は、



ctr_dist の中でthis_model を使いたければ、

オブジェクト名　や
オブジェクト名＋ピリオド　や
オブジェクト名 .kine.global/local.pos で終わっていてはいけない。

オブジェクト名 .kine.global.local.posx まで記述しなければいけない

Ｘ とか書いてるけど、ちゃんと距離は XYZ を考慮して正しく取れるからね。




ということになると思います。

また、他の組み合わせでも実験してみたんですが、行けるものと行けないものがありました。

ctr_dist( this_model.Man_A.kine.global.posz, this_model.Man_B.kine.global.posy )

この例は Z と Y と書いていますが、問題ないです。 XYZ がどう混ざっても問題なさそうです。

ctr_dist( this_model.Man_A.kine.global.posz, Model.Man_B.kine.global.posy )

今度は、左側のみ this_model を使い、右は Model名で書いていますが、問題ないです。





ctr_dist( this_model.Man_A.kine.global.posz, Model.Man_B.kine.global.pos )

さらに右側のみ posy の Y を削除して pos で終わっている形にしましたが、これも問題ないです。 pos で終わっているとダメなのは this_model を使った場合だけであり、この例の場合、右側はthis_model を使わずに Model名を書いているので、ＯＫだということでしょう。

ctr_dist( this_model.Man_A.kine.global.posz, Model.Man_B )

これも大丈夫でした。　Model名を使っている右側のみオブジェクト名で終わらせています。やはり、this_model さえ入ってこなければどの書き方でもかまわないように見えますね。 this_model が登場したときのみ、posx などと最後まで書かなければいけないということのように見えますね。

ただしですね、

ctr_dist( this_model.Man_A.kine.global.posz, Model.Man_B. )

このようにピリオドを入力すると、別にエラーは出ないものの、ピリオドが勝手に消えて Model.Man_B で終わる記述が保存されます。　これも納得行かない挙動ですが、まあ、ピリオド無しでちゃんと動くのだからまあいいとしましょう。

しかし一方で、

ctr_dist( this_model.Man_A.kine.global.posz, this_model.Man_B )
ctr_dist( this_model.Man_A.kine.global.posz, this_model.Man_B. )
ctr_dist( this_model.Man_A.kine.global.posz, this_model.Man_B.kine.global.pos )



これはダメでした。　左側だけ this_model + posx まで書くやり方にして、右側は this_model を使っているにも関わらず posx まで書いていないという状態です。　これだと、エクスプレッションはセットされませんでした。

つまり、たとえ片側（この場合左側）で posz まで書き切っていても、その側だけが成立しているに過ぎず、もう片側も成立しなければ全体としてエクスプレッションが完成しないのでセットされない、と解釈できると思います。









以上。

一応、ここまで分かってれば、仕事で困ることはなさそうな気がしますね。

それにしても、謎の挙動ですね。

普段は　「マニュアルの記述に反しているとまでは言えないので不具合ではない」　などとお役所のような言い方をし出すこともある俺が尊敬する某空調屋さんに勤務の某Ｓさんでも、きっとこれは不具合だと言うと思います。　でも不具合かどうか、正式にバグとして登録されるのかどうかは、もちろん将来的には重要ですが、今この瞬間はどうでもいいです。　Let's get this fuckin' job done.　現場はこれだけを考えていますからね。

ということで、剛田さん、193さん、りゅーぞーさん、m4g さん、ええと他にもいたっけ、実験に協力してくれた皆様、本当に有難う御座いました。俺一人ではここまでたどり着けませんでした。　是非また次もお願いします。　みんなでこの馬鹿野郎ソフトウェアをねじ伏せましょう。

そして、実験していないお方も、是非一度、上の実験を真似てやってみることをオススメします。　というのは、俺もいつもそうなんですけど、「ふーん、これは役立つ情報だな。ブックマークしておこう」　などと言ってブックマークしても、自分で実験していないと、あっという間に忘れちゃうんですよね。　ブックマークしたという事実も忘れるし、それどころか、そういう問題があると誰かが言っていたという事実までも忘れてしまいます。　でも一度実験すると、体が覚えます。





まだこういう実験ネタ、なんぼでもあります。

ブログに書くのもそれなりに大変なので、しばらく寝かせているうちに腐ってしまうネタの方が多いですね。　ほんとは鮮度が重要なんだよなあ。


１５分くらいでブログ記事１本書ける能力が欲しい。
昔と比べてだいぶ速くなったけど、それでもやっぱり３０分や１時間はかかることの方が多いです。
少しくらいはまとまりを持たせようなどと色気を出さずにただ書きなぐればいいのかな・・・



ともかく鮮度を失わないうちに書く。
そのためには、速く書ける能力が必要。
速く書ける能力＝問題の本質部分だけを一瞬で抽出して無駄のない簡潔な文章と構成が自動的にスラスラ出てくる能力。


そんな能力磨いているヒマは俺にはねえよｳﾞｫｹ
このクソったれソフトウェアと戦うだけで精一杯なんだよﾊｹﾞ







.

ctr_dist と this_model の軋轢。

なぜか、ctr_dist の中で this_model が使えないんですよ。
誰か実験してくれませんんか。

エクスプレッションの ctr_dist です。２つのオブジェクトの間の距離を返してくれるという、すごく便利なエクスプレッションです。　今回はこんなエクスプレッションを書きました。

ctr_dist( Model.Man_A, Model.Man_B )

Mac_C のスケールＸにエクスプレッションを仕込みました。　　Man_A と Man_B の距離をスケールＸにブチ込むので、A や B を適当に横に動かして両者の距離を広げたり縮めたりすると、それに合わせて Man_C のスケールＸが変化するというものです。　なんてことありません。

Man_A, Man_B, Man_C は、いずれも Model という名前の Model に所属しています。なのでオブジェクト名のところは、"Model.Man_A" のように、Model名を含めたフルネームになってます。　これで何も問題ないです。　ちゃんと動いています。　

でも今回は、例えば Action 化して汎用的に使おうなどという場合のことも考えて、this_model を使いたいんです。"Model" などという、汎用性の無い特定の名前を記述してしまうのではなく、「名前はどうでもいいから、そのオブジェクトが所属している Model 」　という記述にしたいのです。　だからこそ、this_model です。　そのためにある this_model です。まあ、そのためだけではなく、例えば Model名を覚えていなくても this_model で通っちゃえばラクだから、という意義もあると思いますが、いずれにせよ this_model は便利で有用なものです。

ってことで

ctr_dist( this_model.Man_A, this_model.Man_B )

と書いたのですが、



効かないんですよ。

「効かない」　というのは、エクスプレッションがセットされないという意味です。 Apply 押してもガン無視されます。　まだエクスプレッションが何もない状態でこのように書くと、ガン無視され、既に何かエクスプレッションがセットされていた場合は、元のエクスプレッションのまま更新されていません。つまり、やはりガン無視されているということです。

いろいろいじってみて、今のところ、

　ctr_dist のカッコの中では this_model は効かない
　それ以外では、ちゃんと this_model が効く

という風に、俺には見えるんです。

誰か実験してくれませんか。

とりあえず、this_model を使わない状態でちゃんとエクスプレッションが効いている状態のシーンをアップロードしておきました。 XSI のバージョンは 2012 です。

ダウンロード CtrDistAndThisModel.zip (114.9K)

これを this_model に書き換えられるかどうか、試してもらえませんかね？






それと、このシーンで試しただけだと、俺がこのシーンを作る時に何か変なことをやらかしている可能性を否定できなくなるので、できれば、まっさらな新規シーンの状態から、ご自分でこの問題を再現させられるか、試してもらえませんか？　なにとぞご協力を。

まあ、this_model 使わなくてもなんとかなりますけどね。　でも Action 化して他の Model で Apply した時とかに困るんだよな。　リギングしてると、後半になって全体の整理のために新しい Model に移したりとか、よくやるから。　その時エクスプレッションが、古い Model の方を参照しようとしていたら困るから、確実に新Model 以下のオブジェクトを参照している状態にしたい。新Model に親子をつなぎ直すだけなら、エクスプレッション内の参照先の記述は自動でアップデートされるから問題ないと思うんだけど、Action 経由にすると、当然 Action 内は自動でアップデートされないから、困るんですよねえ。





ともかくだ、ctr_dist は、本当に this_model と相容れないのかどうか。

これがバグだろうが仕様だろうが今はどうでも良くて、どんな環境下でも現象として常に再現するのかどうかを、まずは調べたいのです。





俺ひとりでは、なかなか結論を出せないというか。　どうしてもワークフローの手グセもあるし、もろもろの初期設定など条件が固定されたもとでは、客観的な結論を出しにくいです。　なので、色んな人が、それぞれの環境下で実験して、それでも再現するということが確認できたら、


　　嘔吐デスクどうしかしろやｺﾞﾙｧとか、

　　今はこういうもんだといったん受け入れて、代替ワークフロー考えようぜｵﾙｧとか、

　　次にこれに出くわしても焦らないぜもう分かってるぜさっさと this_model あきらめて実Model名使うことにするから無駄な実験の時間はかかんないぜﾉﾙｧとか、


こんな感じで建設的に次のアクションに進めます。　まずは現象として再現するかどうかの確認が、第一歩です。

どうかご協力をお願いします。










こんな感じで、俺の代わりに誰かに実験をやらせる今さら聞けない素朴な疑問を誰かに質問したり、お互いに協力して実験したりする空気ができるといいなあ、などと妄想しております。　




俺の場合、SI|3D が XSI になった頃から、ひとりで実験したり開発したり、必死で英語の情報を漁ったりしながら、誰にも聞けず悶々としながら何年も過ごした時期がありました。　ひとりで調べて、ひとりで実験して、ひとりでワークフローを決めて指示を出したり。　まわりにダメ出しをしてくれる人はいなく、俺様流で文句も言われないのである意味ではラクではありましたが、すごく孤独感があり、つらい感じがしてました。　　「これ、オレ流過ぎるよな？」　「普通どうやるんだろう？」　「俺、自己流を通してばかりで、時代に置いていかれてる気がする」　「誰か俺に教えてくれよ。毎日調べ物と実験だけじゃ、仕事進まねえよ」　などとストレスを溜めていました。　　

インターネットでの交流がさかんになってきたので、それを利用して、グダグダにならずにＣＧの情報共有ができる場所を作ろうなどと妄想して実験したこともありました。



しかしここ１～２年で大きく状況が変わった感じがしています。ツイッタとかで質問もできるようになったし、個人的にだいぶ知り合いも増えたおかげで直接質問したり意見を聞いたりすることもできるようになりました。　一時期に比べれば夢のようです。 XSI Base のスレッドに深く潜ってってどうにかするのが唯一の方法だった 2003年とか 2004年頃を懐かしく思い出します。


ただし、ツイッタは気軽でいいのですが、常に見ていないとすぐに情報が流れ去ってしまう感じがしていて、ＣＧの話の情報交換場所としては俺はまだ上手く活用できていません。欲しい情報だけフィルタする方法がわからんと言うか。　　ツイッタの利用目的も皆バラバラなので、そこが良い所ではあるのですが、欲しい情報は埋もれてしまう傾向にありますよね。原発やセシウムや東電のことばかり喋りたい人もいるし、格言や名言みたいなのが好きな人もいるし、食い物の話とかも出るし、性器の名称を連呼するような馬鹿野郎もいるし、すげえカオスです。　このカオスの中で自分の目的に合致するよう情報をフィルタするのは至難の技です。

また、あまりにも気軽過ぎるゆえに、何か言うにしてもついついテキトーなことを言ってしまいそうになりますよね。　誰かに質問された時などに、自分で改めて実験もしてないのに、テキトーな記憶を頼りに　「こうじゃなかったっけ」　みたいなことをついつい言ってしまいます俺。　すいませんすいません。　でも、その気軽さゆえに情報を引き出すのが簡単なのがツイッターのいいところなので、気軽で無責任な発言だったとしても否定はしないしむしろ歓迎したい気分です。　でもそれだけではいけない。こうしてブログなどにベイクしておくことも重要だと思っております。

気軽で活発なやりとりから関心や興味が芽生え、複数の人がもう一段階踏み込んで実験し、結果を教え合い、最後にブログにベイクというのが理想ですかね。　いや、そんな上手くいくわけないな・・・。　　ともかくですね、ひとりでやっていてもダメなんです。そんなんじゃあの暗黒時代に逆戻りです。　皆さんとやりたいんです俺は。







あれ？　なんか話が硬くなってるよ。
この記事書き始めた時点ではそんなつもりは全くなかったはずなのに。
ctr_dist ｺﾞﾙｧしか考えてなかったのに。

おかしいな。


まあいいや。

早く俺の代わりに実験して下さい。







.

関節のお勉強。

おおっ　すごく勉強になりそうな論文がっ
http://www.xsibase.com/forum/index.php?board=6;action=display;threadid=45052

juanさんというリガーなお方が、論文を作ったようです。



上のスレッドからリンクされている PDF
http://www.sod4602.com/misc/jc_kinesiology4riggers.pdf




関節に関する論文ですね。



juan さん曰く、

今までリガーとして体の動きについて研究してきたが、必ずしも運動学・生理学的な観点から研究してきたわけではなく、解剖学的な見地から観察していたに過ぎない（結果どう見えるかを観察していただけに過ぎない）

だから動きが不自然になりがちだった

なら生理学的に考えてみよう

筋肉の研究でも骨の研究でもない。その２つの組み合わせである関節の研究である

どの動きは、どこで起動され、どこへどう伝えられるのか

そういうことを研究して、より自然でリアルな関節の動きを描写できる図解を作ることを目標としよう


・・・・・ XSI Base 上での発言と、論文の冒頭のあたりをなんとなくまとめると、こういう主旨だと言っているように思えます。　英語原文の日本語訳としてはかなりアヤシイですが、大まかな主旨はこういうことなんだろうと俺は解釈しています。




ちょっとだけ読んでみましたが、例えば、　腕を上げようとしたら　○度から○度の角度までは○○関節が動き、それ以上は○○関節も起動され、最終的に○と○は一直線にならなくなり・・・・・うんぬんかんぬん　というような、関節の挙動・性質を描写しているように見えます。

ただやみくもにロトスコープしたり写真を見たりして目標とする絵に近づけたりするのではなく、関節の仕組みを理解して、関節の挙動として何か可能で何が不可能か、どう並ぶか、どこが引っ張られるのか、などを知った上でやれば、より自然なポーズ、自然なデフォーメーション、自然なモーションができるという、そういう考え方なんだと思います。

関節だけの理解じゃダメなんでしょうが、関節という観点も大事、ってゆうか一番大事、というくらいのつもりで書かれた論文なんじゃないかな？




医学的なコトバがいっぱい出てくるので、英語を読むのが非常につらいです。　しかもおそらくは現段階での無断転載を防ぐために画像をスキャンしたような PDF になっているので、文字がコピペできません。つまり辞書ソフトウェアや Web検索などにそのまま食わせられません。修行のようなつらさがありますねｗ　　でもすげえ参考になる、というか新しい意識を持つことができそうな気がするので、宿題リストに入れておきましょうね。　こういうのは文章じゃなくて、授業形式がいいですよね。　どっかで関節セミナーやってくれないかなｗ　　金払ってでも参加したいですね。


文中の joint というのは、単関節のことだと思います。　２つの骨から成る関節。
complex というのが、複関節のことだと思います。３つ以上の骨から成る関節。
http://ja.wikipedia.org/wiki/人間の関節一覧





３ＤＣＧのアニメーションを見ると、なんとなく、鎖骨の動きが少ないものが多い気がするのは俺だけですか。　鎖骨の動きと言うと、結果的に肩の上下左右前後の動きになると思うんですが（左右は少ないか？）、　肩が動かないとポーズとしてすんげえ不自然ですよね。　試しに片方の肩を反対側の手で抑えて動けなくした状態で腕を動かしてみると、肩が動かずに腕を動かせる範囲ってすんげえ狭いことがわかりますよね。　っていうか自然に腕を動かしたら、ほぼ全ての動きで肩がセットになって動く気がします。　だから肩のポジションを動かすための基点になる鎖骨のローテーションがすごく重要だと思うんです。

例えば、拳銃を両手で構えたポーズなんかで不自然なものを多く見る気がするなあ。っていうか自分がやってもいつも不自然になりがちな気がする。　おそらく、肩の前後位置や上下位置が最適でないのだと思います。　　最近話題になっていた、逆再生なゾンビものムービーでも、肩周りの動き・ポーズ・デフォーメーションがあまりにもひどくて、なぜみんなそこを気にせず絶賛するんだろうなあ、なんて思ってましたエラソーですいません。

あと、例えばケータイでメールを打っているポーズとかかな。そういう感じのポーズでも不自然なものを多く見る気がするんですがどうですかね。　ケータイを胸の前に持っていく時にどの程度肩が動くかとか、意識するとだいぶ良くなると思うし意識しないとひでえデキになると思います。

なのでセットアップ段階では鎖骨のピボットの位置など気を遣うわけですが、今まであまり上手く行ったと思えたことはありません orz 　難しいですよね肩まわりのセットアップって。　まだ超本気でやったことはありません。　　　アニメーションの時点では鎖骨が動くタイミングと量がもちろん大事になると思ってます。　ヒジなどの関節と比較して、どの動きの時はどこが最初に動くか、とか。


なんか juan さんの関節研究な話からはそれてしまったような気もするがまあいいや。






さらに話はそれますが、なぜか俺、いつも人間のスケルタルな動きって不思議だなあと思ってしまうのです。　どこが起源なんだ？　という感覚というか。　

関節を曲げますよね。例えばヒジを曲げるわけですが、３ＤＣＧのＦＫ的に考えると、前腕（下腕）のボーンをローテーションさせるじゃないですか。　つまり骨が主体的に動く。　骨が起源です。　でも実際の人間の動きの仕組みでいうと、前腕の骨が自律的に動くわけじゃないですよね？　　前腕に接続された腱が、前腕の骨を引っ張るんですよね？　違う？　　

仮にそうだとすると、ヒジを曲げる動きってのは腱の動き、つまり腱が伸縮する動きが起源になっていることになりますよね。　

でも、じゃあ、腱の伸縮する動きの起源になっているものは何？　究極的には脳からの信号ということになるんでしょうが、そのリンクがなんか曖昧な感じがしてしまうのです。　腱が骨を引っ張ったりするのは物理的でわかりやすい。　でも腱が伸び縮みする動きを駆動している物体って、なんだ？　と思ってしまうのです。

　脳　→　腱の伸び縮み　→　骨が動く　→　結果骨に接続された筋肉が硬くなったり膨れたり伸びたり

これ合ってる？　違うか？　そもそも腱と筋肉の違いもわからんぞ俺は？　すいません、大して勉強していないので、その辺の仕組みがよくわかってないのです。


で、そんなことを考えながら、ヒジを曲げたり伸ばしたり自分の体を動かしてじっと見ているうちに、脳から腱に伝えられる伸縮コマンドは WiFi で飛ばされているんじゃなかろうか、いや神経だかなんだかという有線LANのはずだよな、でもコマンドはどうやって受け取るんだ？　神経側にインタプリタのような機能があるということになるのか？　信号は本当に何かがそこを動いているのか？　例えばカンセツマゲルミンなどという名前の物質が脳から首や肩を通って腕まで一瞬で流れるのかな？　それって液体？　電気信号？　電気ってビリビリってくるあの電気の微弱なやつってこと？　とかなんとか思いが駆け巡って、しまいにはこの腕が自分の腕ではないような、ヒジを曲げるというごく自然なはずの行為がものすごく神秘的で科学では解明不可能なしくみだと思えてくるような、とても不思議な感覚に陥ります。 これってゲシュタルト崩壊っていうんだろうか。　子供の頃、寝る時に布団の中で、宇宙に浮かぶ地球がありその上で暮らしている自分たちの存在そのものや今そのことについて思考しているという事実が不思議で不思議でたまらなく、なんだか怖くて眠れなくなったあの感覚に似ています。




まあ、そんなことはどうでもいいですね。
大事なのは関節の挙動ですよ。
深く考えてるとゲシュタルト崩壊どころかスケジュール崩壊になるのでもうやめましょう。





.