Cropped d4cd7ac1381dc72b731d1c4cdf542dd3.png

Mr.Blender.Tch

お問合せ |

[login_status]

タグ: リギング

  • Blender : リギングに必要なBone > IK > Limit x/y/zとBone Constraints > Limit Rotation Limit x/y/zは，なぜ一致しないのか

    Blender : リギングに必要なBone > IK > Limit x/y/zとBone Constraints > Limit Rotation Limit x/y/zは，なぜ一致しないのか

    Post Views: 7

    はじめに

    blenderで人体リグを作成していると、手首・肘・肩のような関節を、できるだけ少数のTarget BoneやPole Boneで自然に動かしたい場面，すなわちポージングがあります。特に、IKを使って腕全体を制御しながら、関節ごとの可動域を人間らしく制限したい場合、Boneの回転制限をどの機能で管理すべきかが問題になります。

    その中で分かりにくいのが、Bone > Inverse Kinematics > Limit X/Y/Z と、Bone Constraints > Limit Rotation > Limit X/Y/Z の違いです。どちらも一見すると「Boneの回転範囲を制限する機能」に見えるため、IK側で目視調整した関節可動域を、そのままLimit Rotation Constraintへ反映できるのではないか、と考えたくなります。しかし，設定可能範囲は，Bone > Inverse Kinematics > Limit X/Y/Z では，min値は－180～0度，max値は0～180度と、Bone Constraints > Limit Rotation > Limit X/Y/Z では，min/maxともに，－360度～360度と，少しトリッキーです．

    従って、IK Limitの値をLimit Rotationへ単純にコピーしても、同じ可動域にはなりません。これは個別の設定ミスというより、Blender内部でIK Solver用の制限と通常Constraint用の回転制限が別系統として扱われているためです。

    この問題は新しいものではなく、Blenderユーザーコミュニティでも以前から繰り返し質問されてきました。本記事では、人体リグにおける自然な腕の制御を念頭に置きながら、IK LimitとLimit Rotation Constraintの違い、なぜ単純変換が難しいのか、そして実務上どのように使い分けるべきかを整理します。

    ― 回転制限が2つある理由と、リギング実務での使い分け ―

    Blenderでキャラクターリグや機械リグを作っていると、Boneの回転制限に関して混乱しやすい場面があります。

    特に紛らわしいのが、次の2つです。

    Bone > Inverse Kinematics > Limit X/Y/Z

    Bone Constraints > Limit Rotation

    どちらも「Boneの回転を制限する機能」に見えます。
    そのため、次のように考えたくなります。

    Bone > IK > Limit X/Y/Z で設定した関節可動域を、
    Bone Constraints > Limit Rotation の min/max に自動変換できるのではないか？

    しかし、実際に試してみると、単純には一致しません。
    IK側のLimit値をLimit Rotationへコピーしても、同じ可動域にならないことがあります。

    これは単なる操作ミスではなく、Blender内部でこの2つが別の制御システムとして扱われているためです。

    1. 結論：IK LimitとLimit Rotationは別用途の機能

    まず結論から言うと、両者の役割は次のように違います。

    機能主な用途評価される場所
    Bone > IK > Limit X/Y/ZIK Solver内部での関節制限IK Solver内
    Bone Constraints > Limit RotationFK操作・通常Constraint後の回転制限Constraint Stack上

    つまり、どちらも「回転制限」ですが、同じものではありません。

    IK Limitは、IK SolverがTarget Boneへ向かってチェーン全体を解くときに使う制限です。
    一方、Limit Rotation Constraintは、Pose BoneやObjectのEuler回転値をmin/maxでクランプする通常Constraintです。

    Blender公式マニュアルでも、Limit Rotation Constraintについて、IKの影響を受けるBoneでは期待どおり動かないため、BoneのIKパネル側のLimit設定を使うように説明されています。

    2. IK Solverとは何をしているのか

    IK、つまりInverse Kinematicsは、Targetに向かってBoneチェーン全体を自動的に曲げる仕組みです。

    たとえば腕のリグで、手首のIK Targetを動かすと、前腕・上腕が自動的に回転して手先がTargetへ届くようになります。

    Blender公式マニュアルでも、IK Constraintは「1本のBoneだけでなく、Boneチェーン全体をTargetに追従させる」機能として説明されています。

    このときIK Solverは、単純に1本のBoneのEuler角だけを見ているわけではありません。

    Targetに届くか
    Pole Target方向を維持するか
    チェーン長はどうか
    各BoneのIK制限はどうか
    親Boneの姿勢はどうか

    といった条件を見ながら、チェーン全体の姿勢を解きます。

    そのため、IK Limitは「このBoneのEuler Xを何度から何度までにする」というより、IK Solverの解探索の中で使われる関節制限と考える方が自然です。

    3. Limit Rotation Constraintとは何をしているのか

    Limit Rotation Constraintは、指定した回転軸のEuler角をmin/max範囲に制限するConstraintです。

    たとえば、

    X: -30° ～ +60°
    Y: -10° ～ +10°
    Z: 0° ～ 0°

    のように設定すれば、そのConstraint評価の中でBoneやObjectの回転を制限できます。

    これはFK操作や機械的な回転制限には非常に便利です。

    たとえば、

    ドアの開閉角度を制限する
    レバーの回転範囲を制限する
    補助Boneの回しすぎを防ぐ
    FK操作時に関節が不自然に曲がらないようにする

    といった用途に向いています。

    しかし、IK Solver内部でチェーンを解く処理とは別の段階で評価されるため、IK中のBone制限としては期待どおり動かない場合があります。

    第4章　この問題は昔から繰り返し質問されている

    IK Limit と Limit Rotation Constraint の関係は、最近になって急に出てきた問題ではありません。Blenderユーザーコミュニティでは、少なくとも2010年代半ばから、同じような疑問が繰り返し投稿されています。

    たとえば、次のような質問です。

    IKを使うと、Limit Rotation Constraintが期待どおり効かない

    IKチェーン内のBoneに回転制限を付けたい

    通常のBone ConstraintでIK中のBoneを制限できない

    Bone Properties側のIK Limitと、Bone Constraints側のLimit Rotationはどう使い分けるべきか

    Pole Targetを使うと、IK Limitや回転制限の挙動が分かりにくくなる

    Blender Artistsでは、2015年時点で「IK constrained bone の回転をどう制限するか」という質問がありました。この議論では、IKで制御されるBoneの回転制限には、通常のLimit Rotation Constraintではなく、Bone Data側の built-in IK limits を使う必要がある、という趣旨の説明がされています。

    また、Blender StackExchangeにも、IKチェーン内のBoneにEuler角で回転制限をかけたいが、IKが通常のConstraintを期待どおりには尊重しない、という趣旨の質問があります。

    さらに、GameDev.tvのフォーラムにも、「IK ignores limit rotation constraint」という、今回の問題をそのまま表したような質問があります。これは、IK制御中のBoneに対してLimit Rotation Constraintを設定しても、期待どおりに効かないことが、実務上の疑問として繰り返し出ていることを示しています。

    つまり、この問題は、単なる個別リグの設定ミスとは言い切れません。

    むしろ、Blenderにおいて、

    IK Solver
    Bone > IK > Limit X/Y/Z
    Bone Constraints > Limit Rotation
    Pole Target
    Constraint Stack
    Euler回転

    が、それぞれ別の仕組みとして存在しているため、ユーザーから見ると非常に分かりにくい構造になっている、と考えた方が自然です。

    この背景を知っておくと、IK Limit の値を Limit Rotation Constraint に単純コピーしてもうまくいかない理由が理解しやすくなります。

    つまり、問題の本質は、

    IK Limitの数値をLimit Rotationへどう換算するか

    だけではありません。

    より本質的には、

    IK Solver内部で使われる関節制限と、
    通常Constraintとして評価されるEuler角制限が、
    Blender内部で同じ制御体系として統合されていない

    という点にあります。

    そのため、IKチェーンの関節可動域を制御したい場合は、基本的には Bone > IK > Limit X/Y/Z を使い、FK操作や補助Boneの回転制限には Limit Rotation Constraint を使う、というように用途を分けて考える必要があります。

    5. なぜIK LimitをLimit Rotationへ単純コピーできないのか

    最初に考えやすい方法は、IK Limitの値をLimit Rotationへそのままコピーすることです。

    たとえば、

    IK Min X = -30°
    IK Max X = +40°

    なら、

    Limit Rotation min_x = -30°
    Limit Rotation max_x = +40°

    としたくなります。

    しかし、この方法ではうまくいきません。

    理由は、前述したようにIK LimitとLimit Rotationが同じ角度空間ではないためです。

    IK Limitは、IK Solverが現在のTarget / Pole条件のもとでチェーン全体を解くときの制限です。
    Limit Rotationは、最終的なEuler角をmin/maxで制限するConstraintです。

    つまり、

    IK Limitの -30°
    =
    Limit Rotationの -30°

    とはなりません。

    特に、次のような要素が入るとズレやすくなります。

    Bone Roll
    Owner Space
    Euler Order
    親Boneの回転
    Pole Target
    Constraint Stack
    IKチェーン内でのBone位置

    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の回転制限を分けていると考えられます。

    9. ユーザー視点では不完全に見える

    ただし、ユーザー視点では、この分離はかなり分かりにくいです。

    なぜなら、UI上はどちらも「回転制限」に見えるからです。統合されるか連携されるともっとよいblenderになるのにね．

    Bone > IK > Limit X/Y/Z
    Bone Constraints > Limit Rotation

    この2つが似た名前・似た数値入力を持っているにもかかわらず、相互変換も連携もありません。

    さらに、IK中のBoneではLimit Rotationが期待どおり効かないこともあります。

    Blenderの公式マニュアルやユーザーコミュニティでも、IK制御下のBoneには通常のLimit Rotationではなく、Bone側のIK Limitを使うべきという説明が見られます。

    この点から見ると、BlenderのIK制限まわりは、ユーザーにとって直感的に統合された設計とは言いにくいです。

    10. Pole Targetが入るとさらに難しくなる

    IK Limitまわりの問題は、Pole Targetが入るとさらに複雑になります。

    DevTalkには、Pole Targetを追加するとBone PropertiesのInverse Kinematicsパネルで設定したBone limitsが実質的に無視される、という報告があります。

    また、StackExchangeやBlender Artistsでも、Pole TargetとIK Limitの相互作用により、回転制限が期待どおり効かないケースが議論されています。

    つまり、IK Limit自体も、Pole Targetやチェーン構成によって必ずしも単純な関節制限として扱えるわけではありません。

    このことも、IK LimitをLimit Rotationへ一般式で変換しにくい理由の1つです。

    11. 実務上の使い分け

    現時点での実務的な使い分けは、次のように考えるのがよいです。

    作業目的推奨される設定
    腕・脚などのIKチェーン制御Bone > IK > Limit X/Y/Z
    FK操作時の回しすぎ防止Limit Rotation Constraint
    コントローラBoneの操作範囲制限Limit Location / Limit Rotation
    機械部品の単軸可動Limit Rotation Constraint
    IKの曲がる方向制御Pole Target
    IK中間Boneの厳密な関節制限IK Limit中心。ただし検証必須

    特に人体リグでは、腕や脚のIK制御にはBone側のIK Limitを使い、FK操作時の保護や補助Boneの制御にはLimit Rotationを使う、という分け方が現実的です。

    12. Add-onで完全変換できるのか

    今回検討しましたが，ものにはできませんでした．
    現状で達したadd-onでは，次のような処理を行うことは可能です。

    Limit Rotationを一時muteする
    IKだけで姿勢を再評価する
    現在角度Cを取得する
    IK Limit値からLimit Rotation候補値を計算する

    しかし、これはあくまで候補値の生成です。

    汎用的に、

    IK Limitの範囲
    =
    Limit Rotationの範囲

    を完全再現するのは難しくベンディングしました。

    難しい理由は、Limit RotationがX/Y/Zの独立min/max制限であるのに対し、IK Solverの可動域はチェーン全体・Target・Pole・親Bone・Bone Rollなどに依存するためです。

    したがって、Add-onとして現実的なのは次の方向です。

    完全変換ツール
    ではなく、

    IK LimitからFK用Limit Rotationの初期候補を作る補助ツール

    くらいは可能です．その内，改良できるかものです．

    13. Blenderにあると便利な改善点

    個人的には、Blender本体に次のような機能があると、かなり分かりやすくなると思います。

    IK Limit と Limit Rotation の違いをUIで明示する

    IK中のBoneではLimit Rotationが効きにくいことを警告する

    IK用LimitをViewportで可視化する

    IK LimitからLimit Rotation候補を生成する補助機能を用意する

    Pole Target使用時にIK Limitが無視・競合する可能性を警告する

    IKチェーン末端がTargetに到達しているか診断する

    選択Bone自身がTarget方向を向いているか診断する

    特に、リギング初心者にとっては、IK LimitとLimit Rotationが別系統であることがUI上で分かりにくい点が大きな問題です。

    14. まとめ

    BlenderのBone回転制限には、似ているが別物の2つの仕組みがあることを理解できました。

    Bone > IK > Limit X/Y/Z
    = IK Solver内部で使う関節制限

    Bone Constraints > Limit Rotation
    = 通常ConstraintとしてEuler角を制限する機能

    両者は見た目は似ていますが、評価される場所、対象、用途が違います。

    そのため、IK Limitの値をLimit Rotationへ単純コピーしても、同じ可動域にはなりません。
    また、現在角度Cやfactorを使った変換式も、Bone Roll、Euler境界、Pole Target、Owner Spaceなどの影響を受けるため、汎用的な完全変換にはなりにくいです。

    実務上は、次のように使い分けるのが現実的です。

    IKチェーンの関節可動域
    → Bone > IK > Limit X/Y/Z

    FK操作や補助Boneの回転制限
    → Bone Constraints > Limit Rotation

    Blenderの実装としては、IK制限系と通常Constraint系は，統合されていません。
    ただし、それは単純な不具合というより、IK Solverと通常Constraintが別目的・別評価系として実装されているためです。

    リギング作業では、この違いを理解したうえで、IK用制限とFK用制限を分けて設計することが重要です。

    【注意点・例外】

    この記事では、Blender 5.1 Manualおよび関連コミュニティ情報をもとに整理しています。BlenderのIK SolverやConstraint評価はバージョンやリグ構成によって挙動が変わる可能性があります。実際の商用・配布用リグでは、必ず対象バージョンのBlenderで動作検証してください。

    また、記事中の「Blenderの実装が完全ではない」という表現は、Blender全体の品質を否定するものではありません。ここでの意味は、IK LimitとLimit Rotationがユーザー視点で統合された制限システムにはなっていないという限定的な評価です。

    【出典】

    Blender Manual: Limit Rotation Constraint
    https://docs.blender.org/manual/en/latest/animation/constraints/transform/limit_rotation.html

    Blender Manual: Inverse Kinematics Constraint
    https://docs.blender.org/manual/en/latest/animation/constraints/tracking/ik_solver.html

    Blender Manual: Inverse Kinematics
    https://docs.blender.org/manual/en/latest/animation/armatures/posing/bone_constraints/inverse_kinematics/introduction.html

    Blender DevTalk: Pole target and Inverse Kinematics limits
    https://devtalk.blender.org/t/pole-target-and-inverse-kinematics-limits/5604

    Blender Artists: How do i limit the rotation of an IK Constrained bone?
    https://blenderartists.org/t/how-do-i-limit-the-rotation-of-an-ik-constrained-bone/631003

    Blender StackExchange: How to limit movement of a IK-chain armature to one plane?
    https://blender.stackexchange.com/questions/115818/how-to-limit-movement-of-a-ik-chain-armature-to-one-plane

    Blender StackExchange: Issues with IK rigging a robotic arm
    https://blender.stackexchange.com/questions/324908/issues-with-ik-rigging-a-robotic-arm-inverse-kinematics-with-rotation-limits-an

    【確実性: 高】

    公式マニュアルと複数のコミュニティ議論から、IK LimitとLimit Rotation Constraintが別用途・別評価系であることは高い確度で言えます。一方で、Blender開発側の内部設計意図すべてを確認したわけではないため、「なぜ分けたのか」の詳細理由には推測が含まれます。