6. 「現在角度C」を使った変換式も完全ではない
IK Limitの値をLimit Rotationへ変換しようとすると、現在のIK姿勢におけるBone角度、つまり現在角度Cを基準にする考え方が出てきます。
考え方としては、次のようになります。
Limit Rotation候補値
= 現在角度C + IK Limit値たとえば、現在角度Cから見て、IK Min側・IK Max側へどれだけ動けるかを考え、その結果をLimit Rotationのmin/maxに置き換える、という発想です。
この考え方自体は不自然ではありません。
特に、Bone > Inverse Kinematics > Limit X/Y/Z の設定範囲が、Min側は -180°〜0°、Max側は 0°〜180°であり、Limit Rotation Constraint側では min/max ともに -360°〜360°まで設定できることを考えると、現在角度Cを基準にしてLimit Rotation側の絶対角度へ展開する必要がある、という見方は理解しやすいです。
しかし、この方法も完全な変換式にはなりません。
理由は、現在角度Cそのものが、既存のLimit Rotation Constraint、Constraint Stack、Owner Space、Bone Roll、親Boneの姿勢などの影響を受けるためです。さらに、IK SolverはTargetやPole Boneを使ってチェーン全体を解くため、選択Bone単体のEuler角だけを見ても、IK Limitの可動域を完全に再現できるとは限りません。
そのため、C基準の式は、Limit Rotation値を推定するための参考にはなりますが、IK LimitとLimit Rotationを一対一で変換する汎用式としては不十分です。
7. factor = 1.0 でも factor = 2.0 でも完全ではない
角度に加えてFactorを導入すればどうかも検討しました．
IK Limitの入力範囲は概ね、
Min: 0 ～ -180°
Max: 0 ～ +180°です。
一方、Limit Rotation Constraintのmin/maxは、
-360° ～ +360°まで扱えます。
このため、単純に考えると、
factor = 2.0として、IK側の±180°をLimit Rotation側の±360°へ対応させたくなります。
しかし、これも常に正しいとは限りません。
たとえば、小さな角度範囲では、
IK Min = -30°
IK Max = +40°を2倍してしまうと、
-60° ～ +80°になり、目視調整したIK可動域より広くなってしまう可能性があります。
一方で、極端な例として、
IK Min = -180°
IK Max = +180°を考えると、factor = 1.0 ではLimit Rotation側は、
-180° ～ +180°になります。
しかしEuler角では、-180°と+180°は同じ向きを表す境界でもあるため、この値をそのまま「正しい」と評価するのは危険です。
つまり、
factor = 1.0 が常に正しいわけではない
factor = 2.0 が常に正しいわけでもないということです。この考えもあまり良くないようです．
なんとか自動計算で，Bone > Inverse Kinematics > Limit X/Y/Z の値(可動範囲)を制御範囲となるLimit Rotation Constraint>limit X/Y/zに変換する方法を模索しましたが，いまのところ実現はできませんでした．
当面は，各関節に対して最初にBone > Inverse Kinematics > Limit X/Y/Z の値(可動範囲)を設定し，その範囲はsolid画面で可視化されるので，それを頼りにして，Limit Rotation Constraint>limit X/Y/zの制御範囲をマニュアルで決めていくしかなさそうです．
8. なぜBlenderは2つの制限を分けているのか
なぜBlenderは、IK LimitとLimit Rotationを統合していないのでしょうか。
推測ですが、理由は用途が違うからです。
IK Solverは、Targetに到達するためにチェーン全体を解くシステムです。
Limit Rotationは、個別BoneやObjectのEuler角を制限するConstraintです。
両者を完全に統合しようとすると、IK Solverは次のような条件を同時に解く必要があります。
Targetに届くこと
Pole方向を維持すること
各BoneのIK Limitを守ること
各BoneのLimit Rotationも守ること
親Bone変換を考慮すること
Owner Spaceを考慮すること
Euler回転順序を考慮すること
既存リグとの互換性を壊さないことこれはかなり複雑です。
そのため、Blenderでは実装上、IK内部の関節制限と通常Constraintの回転制限を分けていると考えられます。
コメントを残す