I’m working on and fk/ik blend with snap per this thread
And I want to avoid the tedium of the parameter wiring dialog by scripting the parameter wiring.
the example of scripting parameter wiring is pretty straight forward
paramWire.connect $foo.baseObject[#radius] $baz.bend[#angle] "radius / 2"
I am confused because, while this code in the listener returns the values I wish to connect:
switchHoldingObject.modifiers[1].ikfk_attribs.ikfk_blend
def_upper.transform.controller.rotation.controller.orientation_constraint.weight[1]
the same code used with parameterWire.connect code produces an error:
paramWire.connect switchHoldingObject.modifiers[1].ikfk_attribs.ikfk_blend def_bone.transform.controller.rotation.controller.orientation_constraint.weight[1] "100-ikfk_blend "
-- Runtime error: connect requires subAnims
how do I point paramWire.connect to these attribute values correctly?
(the #CODE tags seem to be inserting unwanted spaces in my code fyi)
the system says you true. it should be something like:
paramWire.connect switchHoldingObject.modifiers[1].ikfk_attribs[#ikfk_blend] def_bone.rotation.controller.orientation_constraint.weights[1] "100-ikfk_blend "
(constraint.weight is together). it’s a known this forum glitch.
that’s correct version with setup:
(
attr = attributes ikfk_attribs
(
parameters main
(
ikfk_blend type:#float
)
)
delete objects
switchHoldingObject = box()
modi = EmptyModifier()
custattributes.add modi attr
addmodifier switchHoldingObject modi
def_bone = box()
target = box()
c = def_bone.rotation.controller = Rotation_List()
r = c.available.controller = Orientation_Constraint()
r.appendtarget target 100
paramWire.connect switchHoldingObject.modifiers[1].ikfk_attribs[#ikfk_blend] def_bone.rotation.controller.orientation_constraint[1] "100-ikfk_blend"
)
it’s 2006. nobody wears this any more.
Yep, it’s old, but the only explanation of 3ds max IK/FK blending -with snapping I could find on the web. Oh so many Maya examples, however.
denisT, I know you know your stuff and you’ve helped me before.
If you can point me to a modern 2013 solution for IK/FK switching with snapping
(that all the cool riggers are wearing this spring) I’d be much obliged.
that said, I still don’t know how to wire a custom attribute to an orient constraint using a script…
here is a simple question… why is the IK/FK blending? does anyone really need to blend IK and FK poses? my animation experience says that all animators in 99.9% cases just only want smoothly toggle IK/FK.
I still get the request for IKFK blending, and it is still what I provide. No one ever complains. I prefer a snap as well.
So how are you doing it Denis?
math… matrix algebra…
there is no problem to switch from IK to FK, isn’t there? the problem is to switch it back, because not any bone chain transforms might be resolved by IK. what do i do?
#1 try to limit FK transforms to be set in unresolved by IK state
#2 at the time of switching ‘suggest’ a pose that fits the best FK to IK snap.
in most cases #1 works well. in other cases the animator decides how many frames use to come to the ‘right’ snapping pose.
snap toggle is indeed the goal for me, the ik-fk blending is incidental, a result of the fact that the thread i linked to was the only explanation of rigging ik-fk snapping I could find (for max).
I get snapping to IK, it’s simply setting fk_bone.transform = ik_bone.transform
the thread I linked to seems to have an effective snap to FK, using the extra fk_swivel helper.
Is it flawed somehow?
I am absolutely open to a better approach.
I apologize for my ignorance, but “math…matrix algebra…” is a bit vague for my skill level.
that’s why the ‘blending’ method is so popular. most riggers came from animators who liked art in school/college more than math. and there is an opposite problem. most of animation tools were design and developed by people who never did an animation. so… the best rigs that saw were made by technical artists with animation background.
I use Math, Matrix and Algebra as well. I assume that you meant FK can always match IK but not the other way around. So if IK can’t match the FK what do you do?
How does your IK FK work differently then what was suggested in the link? You don’t use a three bone setup? You don’t use orientation constraints? You don’t have a spinner just buttons?
i say to the user: “Sorry bro. I really can’t solve every possible pose. Be smart to not set the pose in an unresolved state.”
You don’t use orientation constraints?
probably all types on controllers i use. except reactor controllers which i just hate.
You don’t have a spinner just buttons?
no spinners for the FK/IK switching. master IK control has complete UI:
- IK/FK snap button, stretch enable checkbox, stretch factor spinner, etc.
extra macros provide a multi-control service.
and also, per the thread topic:
how do I wire a custom attribute to an orient constraint using a script?
ok I see where I was going wrong with the wiring path.
my code was erroring with
-- Runtime error: connect requires subAnims
because myObject.controller.orientation_constraint.weight[1] returns a value, not a SubAnim Object.
myObject.controller.orientation_constraint is a SubAnim-but not the one I want.
myObject.controller.orientation_constraint holds an array of yet more subAnim Objects
each of these sub-subAnims holds an orientation weight value I wish to connect.
so i need to access the weight as an element of the .orientation_constraint array:
by index:
myObject.controller.orientation_constraint[1]
or by name:
myObject.controller.orientation_constraint[#Orientation_Weight_0]
thanks to both of you for your replies, It’s instructive to observe you two interact.
I’ve learned a lot form both of you -here and elsewhere.
If anyone has some links or examples of the specific math/matrix algebra that applies to ik-fk snapping I’d be much obliged. For now, the method in the linked explanation will have to do.