hinging controls

#1

hey yall,

im trying to figure out how would one go about hinging controls., say, ie., to different parts of the body.

an example:
characters hands are ik. but what if i want him to touch his face. i saw rigs that let you select to which control is the wrist stuck and then if you want it back unstuck, it doesnt move one bit. it doesnt jump to the original position. so… what the f…? ^^

i tried scriptjob, but that broke, i tried messing around with the parent constraint, but that didnt help either…
at this point, im not really sure what keywords to throw into google for it to spit back some results, so i figured this is the best place to ask directly. im sure some of you have experience with that…

and i also think there must be a good tutorial on that, so if you guys could throw me in the right direction or share a ink or two, that’d be just swell. and of course much appreciated :slight_smile:

thanks

oh yeah and i want something useful and animation friendly, so a plugin is out of the question, as well as a script that would be setting keyframes… stuff like that. what i would love is a node-based approach to keep things awesome ^^

#2

You can try searching “space switching” or “dynamic parenting”. Essentially you will create empty groups or locators that represent each space to which you wish to attach. Parent them under their relevant objects (head, chest, pelvis, world). Then create parent constraints on a node above your animation control, connecting the node to all of the different “spaces”. Drive the weights of the constraint to switch it to the different parents/spaces with a custom attribute. You will need to script a “match” script that stores the worldspace location and rotation of you control before the switch, and then move the control there after the switch. You can use xform for this.

float $pos[] = `xform -query -worldSpace -translation [i]yourControl[/i]`;
   float $rot[] = `xform -query -worldSpace -rotation [i]yourControl[/i]`;
   [i]switch parent constraint weight command[/i];
   xform -worldSpace -translation $pos[0] $pos[1] $pos[2] [i]yourControl[/i];
   xform -worldSpace -rotation $rot[0] $rot[1] $rot[2] [i]yourControl[/i];
#3

thanks gonzalimator, but this all i already know :slight_smile: what i was looking for is really more of an animation friendly approach… i can do it like you say, which is essentially the same as ik-fk switch, but for that to ease animators life, the script would also, as the fkik, have to key the position one frame before the change, and then key on the current frame the proper position, but then it would mess the keys totally (hide them from the animator and make them non-understandable for him) and if animator decides ‘nah, im gonna have him touch his face on frame 250 instead of 270’, there goes the problem.

is there really no way to do this without a script? :confused: nodes would be really awesome…

oh, and thanks for the ideas on the keywords for google :slight_smile:

#4

You were on the right track then when you tried to use a scriptJob that runs the match script anytime the space/parent attribute changes. It does make the rig a bit slower and it can have update/undo problems. Check out Jason Baskin’s “Blake” rig for a great example.

#5

thanks mate, I downed it and will look over it right now.
the problem i had with the scriptJob, is that it didn’t evaluate when i scrubbed through timeline, which created lots of issues when the hand was flying all over the place cuz it was still parented to just one control… etc…
hey, i just thought of something that could work, i’ll try that first to see if my theory is valid and then check the Blake rig.

now for the speed… what are we talking about? how heavy are scriptJobs on the scene? should i consider them as heavy as expressions? (in which case, unless one works at a big-ass feature film studio, one doesn’t really need to worry about it…) or is it worse? it’s just math, right? just as expressions are…

plus, for animators mainly, we already switched to 2012, a bit hasty move maybe, but with the editable motion trails… what im getting to, is the interface. our animators used to have to have proxy puppets for animation, but with 2012, they’re able to work without any constraints only with the smooth mesh of the real character. So I expect the scriptJobs to not hold it back that much… hopefully ^^

#6

Jason explains a bit what he did to get the scriptJob to update while scrubbing and playblasting in this thread.

http://forums.cgsociety.org/showthread.php?f=54&t=736991&page=2&pp=15

#7

looking into it extensively today, muchas gracias, Marcos :slight_smile: hopefully, i’ll have mine up and running in no time. I need to examine the under-the-hood operations, i am reluctant to implement anything in my rig unless i know exactly how it works.

Thanks again.

#8

So just to elaborate, I looked at how it was setup in the blake rig, but that’s just moving the hand to the right place after switching the space. I could have done that from the start, but that was not what i wanted. (Besides, his ik fk match is far from complete, since it jumps as hell, but i haven’t looked over what’s happening wrong in the code, so I can’t say, and that’s for another topic.) Anyhow, what I wanted was to keep the hand in the same place (keeping it’s transforms, and rather moving the offset of the parent constraint of the group above it. I thought he somehow implemented a method for the scriptJob to evaluate during playback, playblast, scrubbing, whatnot, but that’s not the case…
Im 96% certain it’s cuz maya doesn’t change the attrs (the change of which is driving the scriptJob) of a node while scrubbing/playback, but rather when stopped on a frame.
I tried even changing the modes when the sJ is supposed to evaluate, especially the ‘time’… with no luck.
I’m left with the rough solution of moving and keying the hand control, but i don’t like it… it’s almost the same as ik/fk, and thats just sad, haha… I’ll stick with it for this project, but I’ll keep researching into how to do it better, cuz there’re always ways to do it better :slight_smile:

Anyhow, thanks a bunch for being the only person reacting on this, hehe. You have a great day :slight_smile:

#9

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.