as i told… it’s not a good practice to use some controller with not its real purpose. in your case it’s a scale controller… unfortunately this technique was shown in the mxs help and some script developers copied it in their tutorials. but as i said – this is wrong!
and probably i wouldn’t use extra object just for ‘radius’ control. i would add a custom attribute with ‘radius’ parameter to the constrainted object. this way will give you full control by only using this object’s parameters(and controllers).
another good thing about my setup is that you can easily disable this constraint… if you set expression controller weight to 0, but real position controller’s weight to 100…
Denis’ solution is nice and it gives you the circular arcs that you seem to be looking for and doesn’t cause any “lagging” like the method I posted on Tech-Artist (I wasn’t really sure what you were going for).
-Harry
i haven’t read your post on tech-art yet…
but my solution of course has to be improved. try to animate my solution and check the trajectory you will get.
you will see that the gotten path is not smooth. and, which is much more worth, it’s not predictable.
the question is – what do we have to add to be able control ‘smoothness’ of on surface sliding?
now i’ve read your post…
“this hack open a lot of doors and can be used to get round any dependency loop“
it’s the big mistake. really it shuts doors by hiding or camouflaging the real dependency loop. i think this ‘trick’ has to be wiped from the mxs help.
i don’t really know why and how it came to the max. probably it was born by someone ‘maya driven’. in the maya everything is based on a ‘node’. that’s why ‘maya’ basic human skeleton is about 300 nodes, where the max’s one is ~100.
BTW does any one know or guess why the scale controller is usually picked as an ‘accomplice’ of this hack?
Because it’s the last one evaluated when calculating the node transform and thus can modify the previous rotation or position controller values???
correct!
…and also because people think that the scale is most useless controller
If I recall correctly, the original intent of this post was to find a solution to keep a control object at the end of the bone chain (not allowing it to be moved away from nub bone during animation– which happens when you constrain the IK Goal to the control object), correct?
@DenisT, I look forward to trying your solution (because I’d like to do this for a rig I’m making)… I guess the drawback to the solution I proposed is that it makes the control object as a child of the bone chain (similar to nub bone) thus embedding it in bone heirarchy– which is undesirable.
I don’t mind that it moves away during the animation process, I just wish it would automatically snap back to the nub bone after I release it with the mouse… I’m sure if I were smarter, a Maxscript solution would present itself.
do you mean like this?
delete objects
b0 = BoneSys.createBone [0,0,0] [20,0,0] z_axis
b0.boneScaleType = #scale
b1 = BoneSys.createBone [20,0,0] [24,0,0] z_axis
b1.parent = b0
p0 = IKSys.ikChain b0 b1 "IKHISolver"
LockedTracksMan.SetLocks on b1.transform.controller undefined 0 off
p = p0.pos.controller = position_list()
p.weight[1] = 0
sc = p.available.controller = position_script()
sc.addtarget "len" b1.position.controller[1]
sc.addobject "par" b0.scale.controller
sc.addobject "pos" p[1]
sc.setexpression "(normalize pos.value)*len*par.value[1]"
d = p.available.controller = b0.pos.controller
the IK control is constraint now… but! this is not a good idea and i will not show how to do it right