もきもき3D

アクセスカウンタ

zoom RSS MotionHandler関係。

<<   作成日時 : 2010/01/13 20:03   >>

ブログ気持玉 0 / トラックバック 0 / コメント 0

 MotionHandler->evalate()において。

 WorldPositionはiteminfo->param(LWIP_W_POSITION)を信用しても概ね大丈夫っぽい(9.6除く?)。

 WorldRotationはLWIP_RIGHT/UP/FOR〜を信用しては駄目っぽい。
 UseItems()で与えるLWItemID配列にLWITEM_ALLを含めていても適切に更新されないもよう。
 極限定的な状況によっては信用してもいいのかもしれないけど、妥当な値を得られる確率は限りなく低いと考えるのがよさげ。
 親を辿ってLWIP_ROTATIONとLWIP_PIVOT_ROTで算出すれば妥当な値を得られる確率は高い。
 (計算は、自身を基点にiteminfo->parentで親を辿るwhileループ。 単位行列に各item→Rot(BPH)→PivRot(BPH)の順に掛けて行く方法で。 PivotRotationを忘れないように。)

 アイテムA(plugin:Follow Pos/beforeIK &Target Rot/afterIK)、B(IK)、C(plugin:Follow Pos&Rot/afterIK)、D(キー)があるとして(IDはA<B<D<C)、
 AのFollow PosでBの結果位置を取り、其処からDをTarget Rotする(BのPosからDをTarget)。
 CからAの結果をFollow Pos&Rot。
 というケースでは自前で計算しないとCでAのWorldRotationに倣う事は出来なかった(WorldPositionはLWIP_W_POSITIONで問題無し)。

 ただ、このケースにおいては、二つの疑問点がある。
 Follow PosがbeforeIKでIK結果を取得出来る事(LWIP_W_POSITIONで妥当な値を得られている)。
 AのFollow PosをafterIKにすると、続くTarget RotがFollow前の位置で評価される事(LWIP_W_POSITIONがFollow Posの結果でなく、自身のキー値を取っている)。
 UseItems()に渡す配列に自身のIDを含めたり、LWITEM_ALLを含めても変化はなし(配列の変わりにLWITEM_ALLを直接渡すと落ちるから注意)。


大雑把なドキュメントだけで理想的な実動作を得るのは厳しいっすね('A`)
他者製MotionHandlerが混ざった時の動作も読めないし('з`)
評価順を示すドキュメントが皆無かつ、Ver毎で異なり、順が保証されてないのも痛い('A`)

----
 あ、疑問の解はLWIP_W_RIGHT〜(逆行列取得)にあるかも。
 要確認か('A`)マンドクセ

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
MotionHandler関係。 もきもき3D/BIGLOBEウェブリブログ
文字サイズ:       閉じる