« 2014年7月 | トップページ | 2014年9月 »

2014年8月

2014年8月12日 (火)

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

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




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



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

最終ボーンは  です。 

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

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


Bonelengthblend


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



スライダの値が 0 の時は A の影響が100%(Bは0%)、スライダが 1 の時はその逆で B の影響が100%(Aは0%) という仕様です。


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

0の時はBの影響はゼロになってAの値になるのだから、Aの部分は ( 1 - スライダ値 ) を掛け算しています。

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

上の画像の例だと、Aの 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、ということになりますでしょうかね。 合ってる?




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



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




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






.

| | コメント (1) | トラックバック (0)

2014年8月 7日 (木)

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

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



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


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



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

S1

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


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

S2

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

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




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

S3

ほら。


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




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

S4

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



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

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


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


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




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

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

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




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





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



.

| | コメント (0) | トラックバック (0)

2014年8月 6日 (水)

これ。 この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" );//なんか知らんがこれと次の1行で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 );
		}
	}
}

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

このスクリプトをダウンロード(右クリックで保存とか) Korekonomodel ほんと、それだけのものです。 これ、EKC に組み込めばいいかなあ。 っていうか EKC も長年メンテしてないな。色々不具合あったはず。もっとシンプルなものに書き直したい。昔書いたツールはどれも無駄に複雑で、現在の俺のワークフローに合わなくなってきたりしてますね。 2008年だって。すげえ昔だなあ。 ところでこういう小さいツールは、めんどくさがらずにチマチマ書き溜めていくと、俺様的ワークフローの中にだんだん溶け込んで、効率が上がるんですよねえ。 そのツールを使うために都合が良いようなフローに変わっていくこともよくあって、場合によっては本末転倒のこともあるけどね。  まあアレだ、俺の場合、最初に細かいことを気にせず作り散らして、後で綺麗に整理するというフローが好きなんだなきっと。そのためのツールをよく書いている気がする。 このツールも、ひとまず何も考えずエクスプレッションを書き散らして、あとで this とかに置換できる部分は自動でやってもらおうという発想だな。 毎日暑いですね。 明日は XSI な人と少人数で会って、パワーをもらってきますよ。 甘太郎でビールを吞もう。 .

| | コメント (0) | トラックバック (0)

« 2014年7月 | トップページ | 2014年9月 »