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 様への移行が進みません。　神の思し召しでしょうか。　もう少しの間、こうして村で野良仕事をやることにします。

.

これ。 このModel。

this と this_model ですよ。
エクスプレッションの話です。


PPG 上でドラッグ＆ドロップしてエクスプレッションを作成すると、this や this_model で記述できる部分でもそのオブジェクトのフルネームが入ってしまいますね。　

それを this や this_model にイッキに置換してくれるツールが欲しかったのですが、たぶん無いだろうから急に書きました。


JScript
---------------------------------------------------------

//	これ。このModel。　this. this Model.
//	エクスプレッションのあるオブジェクトを選んで実行。　
//	this や this_model に置換できる部分を置換

OpenUndo( "これ。このModel。" );
var oObjects = Selection;
for ( var i=0; i<oObjects.count; i++ )
{
	var oObj = oObjects(i);
	var oAnimParams = oObj.NodeAnimatedParameters(siExpressionSource);//Expression駆動のパラメータ取得
	for ( var j=0; j<oAnimParams.count; j++)
	{
		var oParam = oAnimParams(j);
		Hage( oParam );
	}
}
CloseUndo();

function Hage( oParam )
{
	var oObject = oParam.Parent3DObject;	//そのパラメータの所有者であるオブジェクト取得
	
	var oExpr = oParam.Source;	//Expression駆動で既にフィルタ済みなのでSourceで必ず Expression オブジェクトが取得される
	var oDefinitionParam = oExpr.Parameters( "Definition" );//なんか知らんがこれと次の１行でExpressionの中身を取得
	ExprDif = oDefinitionParam.Value;

	//	this
	var RE1 = new RegExp( oObject.FullName, "gi" );
	NewExprDif1 = ExprDif.replace( RE1, "this" );

	//	this_model
	var oModel = oObject.Model;
	var RE2 = new RegExp( oModel.Name, "gi" );
	NewExprDif2 = NewExprDif1.replace( RE2, "this_model" );

	if ( ExprDif.toLowerCase() != NewExprDif2.toLowerCase() )
	{
		oDefinitionParam.Value = NewExprDif2;
		Result = oDefinitionParam.Value;
		if ( ExprDif.toLowerCase() == Result.toLowerCase() ) Logmessage( "なぜか変わってねえっス : " + oParam.Fullname, siWarning );
		else
		{
			Logmessage( "置換しますた。 : " + oParam.Fullname );
			Logmessage( "	" + ExprDif  + " --> " + NewExprDif2 );
		}
	}
}

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

このスクリプトをダウンロード（右クリックで保存とか）





ほんと、それだけのものです。



これ、EKC に組み込めばいいかなあ。

っていうか EKC も長年メンテしてないな。色々不具合あったはず。もっとシンプルなものに書き直したい。昔書いたツールはどれも無駄に複雑で、現在の俺のワークフローに合わなくなってきたりしてますね。　2008年だって。すげえ昔だなあ。




ところでこういう小さいツールは、めんどくさがらずにチマチマ書き溜めていくと、俺様的ワークフローの中にだんだん溶け込んで、効率が上がるんですよねえ。　そのツールを使うために都合が良いようなフローに変わっていくこともよくあって、場合によっては本末転倒のこともあるけどね。　

まあアレだ、俺の場合、最初に細かいことを気にせず作り散らして、後で綺麗に整理するというフローが好きなんだなきっと。そのためのツールをよく書いている気がする。　このツールも、ひとまず何も考えずエクスプレッションを書き散らして、あとで this とかに置換できる部分は自動でやってもらおうという発想だな。





毎日暑いですね。
明日は XSI な人と少人数で会って、パワーをもらってきますよ。

甘太郎でビールを吞もう。






.