Hello everyone,
I am trying to make eyelids follow the aim control with the values I put on H and V tracking. It seems to be working but when I move main parent control, it just behaves like its flipped.
This is my settings:
Yeah it isn’t your settings. I believe it is a bug.
I noticed it in 2019 and never reported it. But I see in my POST scripts that I drive that eye_L_upMid_ctl.vTracking in reverse. So I set it to 0 to -1.0 in my rigs.
The logic is just backwards. And I think it is because the multiplyDivide node that connects to that attribute input2X is driven by translation. But the blendshapes go 0-1, towards the middle.
Blue is the blink-space coordinates. Red is the translation-space of the mid controls.
I guess the bug should be fixed. But the temporary workaround is just to set that attribute to negative values, or reverse the multiplyDivide.input2X input that comes from eye_L_aimTrigger_ref.translateY. Or equivalent.
Thanks for the reply.
That didn’t fix the problem, I don’t know the purpose of that parent control. Tried using ‘eye_L0_Over_ctl’ that comes with eye component instead of eye_L_over_ctl (one that comes with eye rigger, parent control). I can move the region, scale and rotate without issues. When should I use that parent control?
What didn’t fix the problem? What did you try?
I tried adding another multiplyDivide node between eye_L_aimTrigger_ref.translateY and node it connects. Did same for eye_L_aimTrigger_ref.translateX.
It fixes the weird issue when I move the eye_L_over_ctl (eye rigger parent control) but then when I move eye aim control, upper and lower eyelid movements are being reversed.
I also tried unlocking H and V tracking and putting negative values separate from the method above, its working as expected when I move aim controller but then eye_L_over_ctl is going reversed.
I am so confused.
First of all, in your settings, I just noticed you put “eye_L0_Over_ctl” as the rig parent! That isn’t right. “Rig Parent” means a node that the entire eye rig is going to be parented underneath, just for organization. Maybe this is why your rig is reversed when you move , if the eye rig is parented underneath the controller. It might be double-transforming or something.
In “Static Rig Parent” you put “eyes_setup” That is the node you should put in “Rig Parent”. You can also use it for the Static Rig Parent. It’s an organization group.
Also, I just tested in mGear 3.7 on a fresh geometry. I do not even need to reverse vTracking anymore. Maybe the bug was already fixed. So maybe the real problem is the parent you chose. Sorry for misleading you!
This is the result of those two settings. You CAN choose the same group for both.
But if choose the right parent, and you still do have it reversed:
translateX should be fine. You shouldn’t have to change that.
hTracking should also be fine. You should not negate that.
And just to make sure, you also should not have to change the lowMid control. Only the upper.
I tried creating a fresh scene, just added eye component and a control component to be an aim object.
Captured a video about my first approach, it didn’t work out of the box. You can see it in the first video.
So I tried negating translateY values coming out from eye_L_aimTrigger_ref and putting positive values for hTracking, negative for vTracking. That square control still doesn’t behave as expected, am I missing something?
Could you share a rig file with the eyes built? And what version of mGear, just to make sure I’m not testing a completely different version.
Sure, here it is:
mGear version 3.7.11
https://drive.google.com/file/d/1mDas7Em-i0Cz6WTC0uMfb9K5Qa13S8n6/view?usp=sharing
I just noticed in your video you’re putting vTracking to 4.91. You shouldn’t drive it past 1.0.
Your rig seems to be working fine. If I put the tracking to 4.91, it goes backwards/weird like in your video.
That said, you shouldn’t really be translating eye_L_over_ctl. You can, but it isn’t designed to do anything super useful.
Also I was surprised your rig works. The eye rigging tool is design to work with open eyes. Because the blendshapes move towards the middle. It seems to work fine with closed eyes. But then the tracking seems to be a bit weird. Which might be part of your problem.
Here is what yours looks like (with vTracking set to 1.0), and then what an open eye rig would look like, when moving the eye_L_over_ctl. Notice in mine, the up and low mid controls are supposed to follow.
I think the reason is that when the eye is closed/blinked, that is when they are designed to stop following, so the blink remains closed. And I think maybe some logic is reversed in the way you set it up with closed eyes.
2 Likes
I will try rigging with open eyes, you’re right. That might be the problem.
Thanks again Chris, its good to have such a community!
I tried with open eyes, same problem is happening. When I set my H and V Tracking to 1, they don’t follow the main control as they are in your last gif.
All I want to do is adjusting fleshy eyes and be able to use main eye control so animators can offset the eye.
Am I setting something wrong?
This is the scene I tried with open eyes. Built with settings above.
https://drive.google.com/file/d/16K4_Id1xlROOB87XYt0AjML60kGCMhCu/view?usp=sharing