Arm IK Controllers not Zeroed Out in Rig

[ViM]

This is true for any arm component in the latest version of mGear 4, in Maya 2023.

Take the famous arm_2j_01 that creates the famous arm_C0_ik_ctl. No need to rig more than the component itself, so no Space Switching. If you Rotate the arm guide and then Build Rig, arm_C0_ik_ctl is going to have some rotations, in order to keep the pose rotated. If you zero them out, they will pop into a pose that has the hands perpendicular to the body.

This creates either

1. an odd and possibly unusable binding pose, if you zero out the controllers, with a pose that is not ideal to use for the default rig pose; or

2. a binding pose that doesn’t have zeroed out controllers, so it has odd rig values that are not ideal to use for the default rig pose.

arm_C0_ik_cns is unavailable, no other upper group that I could use to fix the pose, after rigging. btw, the same problem happens if you use the terrible Tr-Rot separation [I really hope you guys change this from being ON by default btw, because it produces not only a setup that’s difficult to work with but I believe it’s also quite broken, the rotations are unusable if you move the “main” IK control away from its parent. also, what you consider Main, I consider Secondary, and the Parent is the actual Main. or else you leave the parent behind, and it becomes unusable.]

I found the “Wrist rotation control won’t freeze transform” bug, incorrectly marked as solved. I’m not sure if that hack works, but I think this is a pretty important bug that deserves a proper fix, because arm setups are quite often necessary in rigs. ^ ^ I haven’t found anything else so far, that’s not zeroed out, this might be the only case, and I’ve tested all your components.

[abrahams]

Hi ViM

You can do this in a post custom step to create a neutral position offset

import pymel.core as pm
from mgear.rigbits import addNPO
addNPO(pm.PyNode("arm_R0_ik_ctl"))

It might not be a bad idea to modify the components to add a checkbox so this is done automatically

[ViM]

‘pm’ is not defined.
Maybe if you could explain what I need to do, without any code?
And is there no risk changing the rig’s hierarchy after rigging?

[abrahams]

Hi ViM

All this code does is create an empty group above the wrist control. You can do that manually of course.

I added the pymel import. I suggest adding that line in your userSetup.py since pymel is the most pleasant way to script Maya and the default when using mGear.

Don’t be afraid to go in and customize your rig after it’s built. Most things are pretty robust. If you break something and can’t fix it then you can always rebuild!

[ViM]

Thanks, I’ve added a Fix group on top of the ikcns control, manually, for testing, it seems like the rig doesn’t break. I’ve tested it on one arm tho, FK-IK blends, switches, and ranges still work. I didn’t test it with mirroring, because your mirroring is odd and I can’t make sense of it yet - sometimes it works, sometimes it fails in various ways, like not mirroring at all or mirroring the wrong pose.

Pls don’t close this bug just because we have a hacky way to go around it. This is not a solution, I hope you guys fix your code, it’s probably a simple fix on your end as well. And it’s a bug that’s been around for a long time it seems. Thanks!

[actoratwork]

I usually add an - NPO node on top of the IK controller to set everything to 0,0,0

[Moustache_Animation]

I am not in front of the computer so can’t test.

I have only done one rig with mGear in T-pose so I wasn’t aware of the non zeroed arms IK controls for A-poses.

Does it mean the FK arms also inherit a rotation?

That would actually be good for the animators if I am understanding correctly.

I will test when I get home.

[scofrona]

Hey! Looks like this is still an ongoing issue. Even when “FK Rest T-Pose” is disabled, the IK control’s neutral will be set to the T-Pose rotation and position.

Is there a known fix for this?

[actoratwork]

for situations like this, i usually use the Rigbits- NPO node. That way, the control you want, will get 0,0,0 values

[scofrona]

Thank you for the suggestion, @actoratwork! This certainly gets the job done of making “zero” be the expected neutral pose. I’m still a bit confused if this is expected behavior though, considering the UE legs don’t appear to have the same problem.