Face Rigging Help

>>531380
watch out for double transformations if you're going to combine blend shapes and on-face controls. direct connections, using set driven keys instead of point on poly constraints/follicles, are two ways to circumvent that problem.

you don't zero out joints since joints represent world space values/pivots. so I don't get why you want to zero them out. is it because you want to drive these joints with the gui controls? what you CAN do, if you want to create direct connections between controls and joint values, is connect to a group above each joint, or connect to a zeroed out joint that is moved via a group above itself.

note that what i described is pretty fucking tedious so you should script some of it

honestly, I don't entirely get what you're envisioning, also I'm not really a rigger or a high level artist at all. but I did make a rig a while back that had a sort of gui and combined a joint + blendshape setup: https://vimeo.com/176342795
go to 0:52, conceptually is this kind of what you're talking about?

>>531389
First of all your stuff is amazing, I hope to get to that level someday.
I've only barely scripted in MEL but if I found some straightforward documentation on it or something I could try. And yeah, that's basically what I'm talking about.
Before this I've just done parenting, which wasn't a problem because as long as the control was in front of the face and parented to the head rig, the face joints moved properly. Since I want to use a GUI here I can't parent them and haven't really connected them any other way, but if you're saying connecting to a null group above each joint would fix that then I can do that easily.

If I'm not mistaken this rig https://www.youtube.com/watch?v=VQQO4koP7Q0 shows what I mean.
Also thanks a lot for being kind and offering your help!

>>531391
Oh forgot to mention, I really want to stay away from blend shapes and just use set driven keys instead since a lot of the expressiveness will come from the eyes and mouth anyways. My computer's pretty old and Maya LT runs kind of shitty as is, haha.

>>531393
cool, if you are going for a pure joint/cluster approach you won't have to dance around the double transformation problems i talked about.

and yeah what's in that video is probably similar to my setup.

Yeah, what I mean is not parenting. I mean to create a direct connection - this can be done either in the Connection Editor or in the Node Editor. It essentially copies the channel values of one node to another. So you'd do this between each part of the gui and its corresponding cluster/joint. It shouldn't be too bad and although a bit tedious you could do it without scripting

>>531400
and one potential issue - if say you move the GUI control by 1 and you want this to move the cluster by 10, you need to multiply it by a scale factor. so to do this, you'll need to create a multiplyDivide node (in the node editor, press the tab key and type the node name, press enter). basically you use this as an intermediary. and I'd recommend scripting this because it would be a pain in the ass otherwise. you could also brute force this of course and create SDKs instead, but that would probably take longer.

>>531400
>>531401
Awesome, I haven't really played around in the Node editor much yet but that is definitely a rigging basic so I should jump right in. To be honest I totally didn't think I'd even be doing rigging until recently but I've kind of accidentally become a generalist so I'm learning it now even though I've found it really daunting, since I'm not a very technical-minded person. But the way you're explaining it is really straightforward so I really appreciate you taking the time to explain this stuff rather than B me TFO (standard /3/ response)
>connect to a group above each joint, or connect to a zeroed out joint that is moved via a group above itself.
Which of these do you think would be less intensive? Doubling all the joints (what I think you're saying in the second option) sounds problematic but if I connected a joint to an empty group or something, wouldn't that disconnect it from the main rig? Or would I connect their values in the node editor to zero them out? Sorry if I'm not understanding you correctly, I am really new to this.

File: cleanest.png (18KB, 824x309px) Image search: [Google]

18KB, 824x309px

>>531403
I'd say the first method is less labor intensive. See attached. so you basically see that when you group the joint to itself the transform node has clean channel values. this means you can direct connect to it and not mess anything up.
As you see in attached, it's still in the hierarchy. But technically, joints don't even need to be parented to each other, it only helps visually in some instances. Because what is really controlling the hierarchy in practice is how the controls are connected to each other. You can have floating joints and it's not an issue.

>>531405
Also note that if your joints are in a hierarchy you're gonna run into the issue with joint orientation. Basically you'll see this if you create direct connections, you may find that the joint goes opposite or 90 degrees to how you move the control if the orientations do not match. If you make parent/point constraints instead the constraint math will fix this, but the issue with that is you're not able easily able to do what I said concerning scale factors - you're more bound by what the constraint feeds you. So what I actually suggest is to have your joints be floating. This way their orientations are the same as world orientation and they shouldn't move oddly.

hope that makes sense... if not, try playing around with it and you will encounter what i am talking about

>>531406
That does, I guess there's really no reason for face joints to be connected to the head as long as they move along with it. For simpler rigs I did where I just had the jaw and eyes moving and like three joints for the lips and eyes, it makes more sense, but I guess this is another step forward in complexity.
I really appreciate your help, I'm going to take some time to explore this stuff but I'll keep checking this thread in case you or anyone else posts anything else pertinent. Hopefully can update with something cool sometime.

File: 5342f58e372cdd9cc7ff8f6f2f7a21ed.png (250KB, 1543x599px) Image search: [Google]

250KB, 1543x599px

>>531407
So I finally had time to crack this open again.
I wanted to ask, with floating joints, how would I get them to follow the rest of the hierarchy? Would I have to connect them to invisible controllers that are controlled by the main head controller?
I tried driving the grouped joints with the node editor while they were parented in the hierarchy and floating like you said. When they were parented the transforms worked fine except for the x transform, which worked in reverse. Is there a workaround for this, or does it have to do with the joint orientation like you mentioned?
When the joint was floating it stuck to the cluster and wouldn't stay in its original position. I'm a little stuck but maybe playing around with it some more will help. I'm sure I'm missing something super obvious.

>>531406
Oh shoot, sorry reread this and see that as long as they're still in the main hierarchy they don't need to be parented to a root...I think. Still need to test this, been busy the last few days and haven't had time to go back to this side project. Hopefully I figure out a way to make them work.
If anyone else has any tips about working with the node editor in rigging I'd appreciate them.