Autodesk maya; Stretchy Ik on/off switch


Hey i’m new to the site and am rigging a character using the three joint chain system. I’m semi experienced with rigging but wanted to rig something of my own. I did a tutorial on how to create a stretchy ik chain using expressions but realized there was no way to turn it on and off but with trial and error i figured i could do it or “fake it” using constraints. similar to weighting orient constraints in a ik/fk switch 3 joint chain system. I wrote down what i did so i don’t forget and just wanted to “double check” my thinking.

create joint chain


create ik

Go to create/measuring tools/distane

then (holding v key) select the “arm” joint and “wrist” joint

parent locator to “wrist” joint

select ik handle and move until joint chain is completely

write down distance given

then go to window/animation editors/expression editor

name your expression (Example Stretchy joint chain)

enter expression: (This expression was provided from the book
“The Art of rigging”
which is an amazing book that is
uber helpful!! Numbers given are for example purposes)

if (distanceDimensionShape1.distance >= 12.9 )

arm.scaleX = (distanceDimensionShape1.distance / 12.9) ;
elbow.scaleX = (distanceDimensionShape1.distance / 12.9) ;

} else
//Do not Stretch
arm.scaleX = 1 ;
elbow.scaleX = 1 ;

**to add other joints you would just add, underneath elbow.scalex
ex// forearm.scalex = (distanceDimensionShape1.distance / 12.9);

If there are no errors then move joint chain and joints should stretch
the wrist won’t stretch unless you specify otherwise.
reason why the scale is set to X is because that is the axis that
,by default, follows the joint chain.

I realized theres no real way to turn the stretch on and off
without knowing some kind of expression or something so i
figured constraints could work. This is what I came up with

bring ik handle to original location

create a control curve/object, give it a name ex//Ik Wrist cntrl

In the channel box, add a float attribute named ex//IK Stretch
minimum 0 max 1 default 0
and point constrain the distance end locator to the curve/object.

create another locator and v snap it to the distance start
locator, give it a name ex// distance helper

Freeze transformations

Point constrain the “distance helper” to the " IK Wrist cntrl"

in outliner or hypergraph, select the distance end’s point
constraint. This should have two values just below the offset.
Distance Helper1W0 = 1
Wrist CNTRL1W1 = 1

go to window/animation editors/set driven key/set

select the “wrist cntrl” as the driver and the point constraint
as the driven. change the value of the “wrist cntrl” ikstretch
to 0

select the point constraint then theand the distance helper to 0 leaving the wrist cntrls value
at 1.

select the point constraint then the Distance Helper1W0 = 1
Wrist CNTRL1W1 = 1

change the distance helper to weight to 0 leave the wrist cntrl’s
weight at 1

in the driver window select the controller, then the attribute
in the driven window select the point constraint and the values

press key, select the controller in the
driver window, change the attribute to 1

select the point constraint in the driven window and change the
Distance Helper1W0 =1 Wrist CNTRL1W1 = 0 and then press key.

this should have created the setup for an on and off switch for
the stretching of the joint chain.

like i said, i figured this out through trying to think of the
best way to do this kind of a setup through simple weighting of
constraints. Kind of like how you would do a ik/fk setup using
3 joint chains. I just wanted to make sure that this process would
be ok if i were to add this to a rig and then animate with said rig
any criticism or additional input is greatly appreciated.


It’s an interesting solution. I admit, I’m curious to see how it performs. Generally I’ve always found that expressions take much longer to evaluate only behind the dreaded wrap deformer and Cloth simulation in resources demanded.

From my research stretch oftentimes seems to be implemented via:

SDK via mel to make the translate X of the elbow and wrist keep uniform distance. Just have the SDK in the graph editor set to linear on post infinity. The advantage to this method is that using a blendAttr node you can greate a really awesome elbow locking system for pinning a elbow or knee in place.

To turn the stretchy system on or off since we’re having the final chain follow the stretchy using translation I just key the weight of the point constraint to determine whether the final chain follows the Ik or not. Technically the Ik arm is always stretchy but since it’s using utility nodes or a sdk and not expressions the evaluation doesn’t affect the mesh verts.

Or: via utility nodes: 2 multiply /divide and a condition node. and another for normalizing scale OR using zeth willie’s awesome measure joint chain that allows for proper scaling without plugging the master’s scale directly into a multiply divide node’s input 1x.

again to turn it on or off you key the scale constraint you use to make the final arm follow the stretch. I also want my FK arm to have stretching ability so this requires a bit more of a work around using a stretch grp that’s controlled via FK stretch activated by the IK 2 FK switch option.

I hope that might help you in your studies. If anyone more knowledgeable seems something off with my method please let me know.


+1 to the utility nodes suggestion.
That rarely (if ever) fails me and keeps things fairly quick.


Wow great feedback, @gagex2z, I completely didn’t even think about using the graph editor. Both methods make sense, its just I’m not to keen on utility nodes although I’m told there easier to manage but that’s something I probably need to get over.I will definitely try that out.

@ldunham1, Thanks for the comment, I just wanted to let you know I used one of your scripts to fix the deformation order on my rig since there seems to be a bug with trying to do it in maya. Scripting is one thing that scares me and you make it look easy

Very useful and appreciated feedback guys, Thanks!


Whoa man, stop thinking right now. Let me enlighten you ")

First, utility nodes to handle the stretch is the only viable solution. But there are easier ways of toggling the stretch on and off.

Add an attribute on your ik controller called “allow stretch” and also “force stretch”

Allow stretch [0-1, default 1]
Force stretch [0-10, default 1]

Translate this into utility nodes

D = distance from root to controller (the stretch to distance)
B = original total chain distance (both bones unstretched)
J = original joint length (lets say this is the upArm joint for this example)

Condition: If D is > B

True: D - B / 2 * allow stretch + J / J * force stretch

False: 1 * force stretch

Keep in mind the order in which these need to be evaluated. I typed them left to right, in the order they should be evaluated. Running theoretical numbers through this will show why the eval order is crucial.

Adjust for global scaling. By dividing this by whatever node your scaling

And also, just a small little hint. You can reverse the effect of a toggle/switch by: *-1+1
Keep it simple


Sorry for the long response time. Thats also a really good idea, but like I said prior I’m kinda fresh to utility nodes. So trying in trying to understand what you said, essentially I’d have a multiple/divide node a condition node and the joints I want to stretch hook up the joint scale x to these nodes and walaa? Putting it simply


This is the best utility node setup I have seen. The only drawback is that this method does not allow for a knee/elbow lock.


That’s a neat little technique for fixing the scaling issue. Seems most solid, and easily adapted into my previous utility node graph. It’s basically just using dynamic lengths for the joints, instead of setting them manually, or parenting measures nodes into the existing setup and getting the cycle. OK easy.

duplicate the chain, and use two more distance between nodes to calculate the distance from the root to the knee/elbow, and from the knee/elbow to the ankle/wrist. use these distances to set the “Joint Lengths” - “J” is the variable used for this in my pseudo code.

Elbow locking could be achieved by simply not binding to your blend joints, but setting up another structure (Bendy Limbs/Knee controls…?) that are constrained to the blend joints, but allow you to blend the constraints on and off and achieve the locking for the knee/elbow.

You wouldn’t use an extra joint in the arm to calculate roll, but instead pipe those rotations into the bendy null setup (we’re getting way ahead of ourselves now, oh well) so the knee/elbow controls locks the knee/elbow, and the IK cntrl locks the hand, and forearm roll. the root follows the shoulder/hip as it should, and you’ve got a manageable setup, and animators are stoked.

I created a quick demo scene, if you’d like it? It does not have the bendy setup, as It will just convolute the idea. PM me your email


you really dont want to use Expresions for this. The reason is that you can get different results and can lead to some really bad inconsistancies.

Setting up stretch with the IK arm using utility nodes is really easy and will save you a lot of trouble and heartache in the long run.

Why are Expression not optimal for Stretch Rigs?
Expressions evulatate on a per frame basis and have to run caculations based on where they were previously, this can lead to a different result depending on the direction you scrub in the timeline. A really good example of this in action is to run the makeBall script. This is a perfect example of when to use an expresion.

Why use Nodes?
Nodes run at the software core level of Maya they will evulate the same way regardless of the direction you scrub the timeline.

Attached is a stretch FK/IK blend ArmRig that I did about 6 years ago. It’s more than likely also attached in other places in the forums.



Darksuit. Again, I can’t agree with your solution here. I played around with your arm rig and unfortunately broke it quite fast from moving around the ik controller while blending FK to IK and visa versa while also playing around with the stretch blend in different combinations to everything else.

The way you have the stretch blend setup is really not useful for anything other than moving it around in the viewport. (aside from it breaking) it requires the animator to animate the blend on as the elbow locks.

For example - Animate going from an unstretched arm with the IK control close to the root, and now animate that control stretching way out, see what I mean? You’d have to perfectly animate the stretch blend against the elbow.

am I missing something?


Thats a nice rig setup. Again a good tool for the tool box, it would however not work for a number of instances in games and such due to bones counts. Which is one of the things a simpler stretch rig solves. Again tools for the toolbox.

The Rig in question was originally done in Maya 8 then ported to Maya 8.5 so its been a while since I have had time to update and account for some new tech.

Maybe I missed something I watch through the video but it appears that the only way to get the rig back to having a straight line again after its been set to a curve was to reset back to the origin points.


I watched everyframe’s video and started playing around with different ways to achieve the stretchy behavior with elbow locking and correct scaling. This is a setup I stumbled upon that seems to work pretty well. It’s not exact and doesn’t really measure anything but I have not run tino any problems with it during my animation tests.

I took everyframe’s advice on setting up the elbow lock using a different arm chain and since I was confused how to achieve it using the blendAttr node I used a simple point constraint setup that seems to work just as well.

I’d love to hear what everyone thinks of this method and what it could be used for.


It’s an interesting solution. If anything it just shows how many different ways there are to do a number of things. I question how well it would hold up in production, when lots of animators get their hands on it. they can break anything.

Also, it’s portability and how script-able it is, is somewhat of a concern. The SDK seems very dependent on the length of the “bones”. I forget exactly what object your were placing, but you made me cry, when you said “…get it as close as you can.” I know you know this, but there’s no such thing in rigging. It either lines up exactly, or doesn’t and will cause problems.

There’s really nothing wrong with the default condition node setup, and as i’ve stated. by not binding directly to the blend chain, but using another setup that rides along the blend chain, allows you to put the extra layer of functionality in, without ridiculous node graphs, expressions, or SDK.

Also, I’m not quite sure why your elbow locking is to the pole vector control…? I’ll assume it’s because it’s just a test. But in reality, what will it be locked to? an elbow control, and if so, how will that be setup? How will the elbow control follow the elbow, except when elbow locking is on. Will it seamlessly blend between the two states? These I think are valid questions, and issues that would surely arise in production. All these systems have to co-exist symbiotically. They should enhance eachother, and ultimately be a catalyst for the next layer of functionality. preach preach preach ")

Keep at it though, I suggest ditching the SDK, and figuring it out with utility nodes.


Thanks for the awesome feedback. I know it’s better to have things match up exactly, but I’m not really sure how to snap the bone’s translate x to the effector exactly without causing cycles. I suppose I could use Zeth’s method and then layer on the elbow locking chain.

As for the elbow locking tot he pole vector. that’s how jason schliefer made his in his animator friendly rigging demo. That’s also the only tutorial of elbow locking that I’ve seen available. Using a simple point constraint was a completely random idea I found while playing with different options, but it’s always been the pole vector that the elbow snaps to.

The idea is that the pole vector can be snapped to whatever position the elbow is in or placed at the area you want the elbow to rest at on the table and then the elbow locks to that point. What about this do you not like?

Usually the FK mode is not based on the Pole vector, but the FK Elbow control fro the FK chain. I wanted to keep it simpler for the tutorial though.


hmmm, Maybe my workflow is different or maybe I just need to play around with an elbow lock like that. But It seems as if your elbow, when the locking is turned on, slides to meet the polevector, and when turned back off, slides back to meet the IK elbow. I don’t see that as being animator friendly. How could you ever really seamlessly blend between the two states? let me explain…

In my setup. The elbow control that ultimately locks off the elbow, follows the IK solution (with an override of course so you can still animate the elbow off the IK solve. until the locking is turned on, releasing it’s relationship, and leaving the elbow control right where it is, with no other influences. there’s no shift when you turn it on, it only shifts back to follow the IK solution again when it’s turned back off. makes sense right?

I guess it’s hard to grasp in concept, but I think during some animation tests it would be clearer. Like I said, maybe I just need to play around with the rig, but it would seam really difficult to seamlessly set and lock down the arm to a table. not impossible, just more difficult than it needs to be.


Hi, ppl
gagex’s method is pretty interesting, especially for one who do not know scripting or do not have some script to get the complex task done. I just wanna add that in your method you can have things exactly setup with a little simple math.

You just have to get the difference between the distance of the ik and the length along the joint chain.

  • the distance: create a distance between, snap them to place, wohla! there it is, write it down, delete the node.
  • the length: create a 1 degree curve with 3 cvs, snap each cv to the joint. Type in
    ‘arclen -ch false <<name of the curve>>;’ Maya will give you the length of the curve.
    So, minus them: length - distance = offset
    Now, we know how far to translate the ik ctrl to get the ik to fully stretch, also, how much value to put in the translateX of the joint.


Nice, thanks for the input. I’ll try it out and see if I can plug that into my setup.

TBH the only thing I never really liked about Jason Schiefers arm setup was that it relied on the multiply divide node to normalize the scale with the master control. I really liked zeth’s ability to group the master several times and still get correct scaling, but I have also become really spoiled. I hate animating arms resting on a table without elbow locking. I’d say elbow locking is an essential character acting asset in a rig.

If I can figure out a way to get the best of all systems it’ll be ideal. Then I just need to figure out how to script it into an automated arm setup.


All the feedback has been a bit overwhelming but really awesome. Is there any books that would further my understanding on rigging? Cause I know there’s a few.


This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.