【Csharp】XNAでIKの実装、その2

前回のIK計算をIKの影響を受ける全関節に適用してみた。

動画がこちら。

左のアームが自力でIK計算したもので、右のアームがBlenderによるIK適用後のモーションとなる。

うーん、惜しい。

惜しいって何だよ!

たいていこういう計算は、かなり惜しい状態にあるとき、めちゃくちゃになるものである。

何かのパラメータの解釈が間違っていて、それさえ正せば、めちゃくちゃだったのがウソのようにぴったりはまったりする。

なので、こういう近似的に惜しい状態って、俺の勘からすると根本が間違ってる可能性があるんだよなあ。

IKターゲットがアーム全体の長さより遠い場所にある場合は、おおむねあっているような気はする。

けれども、IKターゲットの距離がアーム全体の長さより近い場所にある場合、動きの違いが著しく感じる。

というか、実は自力計算の方は、これでもまだBlenderの動きに合わせて計算を調整しているのである。

たとえば、1回のIK計算でまげられる角度に上限をつけて、うまくしなるようにしてある。

おそらく、Blender側のIK計算は前回述べた計算とは違う方法で算出しているような気がする。

アームの根元の部分を見てみると明らかなのは、Blender側のIKの動作では根元の動きがかなり柔軟になっている。

時にはIKターゲットから遠ざかるようにまげて、アーム全体のしなりを自然なものにしている(ような気がする)

これも予測に過ぎないのだけれども、前回のIK計算では、ターゲット方向のベクトルとエフェクタ方向のベクトルを重ねるだけの計算方法だった。

これは、IKターゲットがアーム全体の長さより遠い場所にある場合はたぶんうまく行く。

そうじゃない場合、ベクトルの方向を重ねるだけじゃなくて、エフェクタの位置とターゲットの位置を一致させるような計算をしなければならないんじゃないかと思う。

ううむ、BlenderのIK計算ってどうやってんだろう。ロジックが知りたいなあ。

4年前

コメントを残す

メールアドレスが公開されることはありません。