When generating the rig using the template biped from mgear.
A locator looking control named leg_L0_ikcns_ctl gets generated.
Im not sure the purpose of this control as there is leg_L0_ik_ctl
Any ideas?
B.
I think it is just a secondary control.
If I recall correctly, when it builds, it is the parent of the IK control, right? It might be meant to be used to constrain the hand or foot, and still be able to animate the main IK control under that constraint.
We decided to reverse it though, especially for the hands. In a POST script, we flip it, so that it is the secondary offset control. To add some secondary animation under the main IK controls.
Another example for the hand: Constrain a prop to the first control. Still be able to adjust the hand without moving the prop.
Thanks for the reply Chris.
I was going to just F8 and scale the controller small and extract the controls so I don’t select them.
Any chance of sneak peak into that post script?
You can also just delete the shape, and extract it. Then you are guaranteed not to select it. An extracted empty transform works too.
Here is my post script. But I only do it for the hands, seemingly.
I also do a fix, where I orient the hands locally. If I remember, the cns node is world space, and I align it to match the local rotation of the wrist. You might want to omit that for a foot control.
import mgear
import mgear.shifter.custom_step as cstp
import pymel.core as pm
from mgear.core import attribute, transform
from mgear import rigbits
class CustomShifterStep(cstp.customShifterMainStep):
def __init__(self):
self.name = "final_rig_cleanup"
self.charName = pm.PyNode('guide').rig_name.get()
def run(self, stepDict):
for side in 'LR':
self.fix_ik_hand_orientation(side)
return
def fix_ik_hand_orientation(self, side):
# by default, the ik hands are oriented by world.
# This makes them match the local rotation of the wrist.
handRef = pm.PyNode('hand_{}0_ctl'.format(side))
ikCns = pm.PyNode('arm_{}0_ikcns_ctl'.format(side))
ikCtrl = pm.PyNode('arm_{}0_ik_ctl'.format(side))
handChildren = ikCtrl.getChildren(type='transform')
pm.parent(handChildren, None)
transform.matchWorldTransform(handRef, ikCns)
transform.matchWorldTransform(handRef, ikCtrl)
# ALSO SWAP THE ORDER OF THE IK and IK OFFSET. arm_R0_ikcns_ctl should be child.
pm.parent(ikCtrl, ikCns.getParent())
pm.parent(ikCns, ikCtrl)
pm.parent(handChildren, ikCns)
oRoot = rigbits.addNPO(ikCtrl)[0]
attribute.lockAttribute(oRoot)
attribute.lockAttribute(ikCns, attributes=['v'])
3 Likes
Thanks Chris for the script.
I hadn’t thought of the idea of deleting a controller and then extracting controllers again.
B.
Ah great idea, I was also wondering what those ikcns_ctl were and I’d rather delete their shapes.
The ikcns controllers are unfortunately the main Translation controllers tho, because the normal ik controllers cannot be moved away from them, or will break rotations. Rotations, weird enough, happen on a separate controller. I’ve never seen this in any other rig and for me it’s by far the biggest problem with mGear. I don’t want to separate TR and ROT in 2 controllers, with a third one that should never be used. I would like just one Wrist, like in any other rig. Should I hide 2 unnecessary controllers and make extra connections to enable 1 good IK controller? Or is there any other way around this?
Thanks Chris, I just found it! Was about to come here and edit my comment… ^ ^
This solves 2 problems in one hit. I need the wrists to follow global, and by default they are set to Auto, and I don’t think you can fix that in guides, only after building the rig. But now Auto works as expected, after having just 1 Ctrl for ROT and TR, and the wrist stays in Global and doesn’t do the funky rotation dance anymore, when moving/rotating the chest for instance.
There still is the issue of the Extra, ikcns, parent Ctrl… which may be useful, but it’s also rather odd to leave it behind. Cuz if you animate its child, you leave the parent behind, and it can’t be used anymore. I feel like it, being the parent, should be used for Animation, and the normal ik ctrl is actually secondary, and could be used for props or anything… or more like just hidden and never seen again. ^ ^
Btw, unrelated, it would be cool if you guys would include a template for Games, with root motion. To create an animroot I have to manually parent the main spine bone to a Root bone, After building the rig. Is there a better way to do this?
Cheers!
ViM
…Eh? The Mannequin and Metahuman templates already have that world joint, and it’s already named root.
Also that isn’t true. You can create any combination of controls you want, and include a joint.
And in the guide settings, there is also this:
There is basically nothing you have to do manually. Set up your rig settings well. But then you have Python post scripts to clean up the rest.
If you don’t have those templates, make sure you’re on the latest version. Maybe you accidentally downloaded from the old version 3 repository.
1 Like
I think you’re absolutely right. I do this in my own rigs, as I mentioned above, including the Python script I use to do so.
(Making structural changes like this may sometimes have unintended consequences with the built-in tools, like IK/FK switching.)
About the ikcns first. I turned it into a larger Ctrl, and I have something like 2 Circles, ikcns and ik, Main and Secondary. The cool thing about it is that you can indeed use Main/ikcns for constraining to a hip or something, and then only animate the Secondary, ik Ctrl, on top of the constrained one. And it’s fine for both to stay in the viewport. Personally… I think you should consider changing your defaults tho… and allow 1 Ctrl for both ROT and TR. Your default, separating into 2 Ctrl, is really problematic and atypical.
Now about animroots… I don’t think you understand what I meant. I looked at all 3 gamey templates you have, and yes, I use the latest mGear 4 version. None of your examples contain an animroot. Let me explain - I hope you don’t mind. An animroot is the root of the bones hierarchy, but not of the ctrls hierarcy. As you can see in the picture below, the arrow is the Animroot Ctrl, and it moves independently of the body [I moved it away from 000]. It’s parented under Global, but is not the parent of anything else. Only the bone is the top, or root of the bones hierarchy. This is how we cancel Translation and sometimes Rotation of a skeleton, and basically keep all the animation at 00, by having the animroot follow the hips/base of spine, while locked to the floor. Seems to export correctly to fbx btw.
It would be great if you guys decided to include an Animroot component, if possible. A simple Ctrl node that allows bone parenting without guide parenting. If not, as you said, a post script might solve the problem. It just needs to parent the main bone to the root bone after the rig build is completed.
Maybe I should have written about animroots somewhere else… sorry about this. I’m new to the forum.
I have another question btw. The arm_C0_ik_ctl is not zeroed [try a simple arm_2j_01, nothing else in the scene. or on your humanoid template, same issue]. That creates a rather weird T pose or Bind pose, if zeroing it after rig build.
I don’t mind at all.
You can create a control_01 or EPIC_control_01 and use that as a space switch, to make anything, like only the root bone - or everything - or nothing - follow a certain arrow control. I think once you’ve spent a bit more time with Shifter, you’ll find you can do the things you’re trying to do. But yeah, otherwise sometimes just use a Python script.
Feel free to pitch the idea of an AnimRoot as a feature request. I think more generally, I would suggest the request be the ability to choose a custom joint parent. There is already a “Parent Joint Index” setting, but it doesn’t give a specific-parent control. It’s more like an offset. You might be able to find a value that does what you intend.
The EPIC_mannequin_arm_01 component has “FK Rest T Pose” and it seems to neutralize all the controls if you uncheck it. If you check it, I guess that means zeroing out the controls goes to T pose, rather than neutral built pose.
That script I posted near the beginning of this thread, I think that is how I worked around the non-neutral values of the hands. I agree, it does seem weird if there isn’t a way to automatically neutralize them, but I guess I just worked around the issue myself with Python, as is my habit. Feel free to post this as a feature request. Another alternative is to copy and modify the components as your own custom components, to suit your needs.
The EPIC mannequin arm is not really what I’d want to use, but it also doesn’t seem to zero out things either, even if FK Rest is unchecked [it is by default]. I tried all arm components and all of them have the same issue. It’s not normal in any case to build components that are not zeroed out, so this is a bug I hope you guys will address.
Space switching for the animroot is an interesting idea, thanks!
Btw, Space Switching, as you wrote above, is indeed the terminology that I’d love to see used in mGear, instead of the esoteric Reference Array. And Sets, not Groups. Maya terminology, clearer terminology, and industry standards pls… XD
For a really long time I avoided mGear due to a lack of tutorials. And probably the separated wrist TR-ROT issue is something I saw and then… died. I’m really glad I gave it another try this year, there is more YouTube content for it. The beginner series are especially useful. A bit chaotic… but it’s great there’s an Intro to mGear now, to bring new people in. ^ ^ It would be really good for you guys if someone with great teaching skills made some high quality, thorough video tutorials, covering all of mGear!
In any case, all in all, I really enjoy working with mGear, it’s maybe the best rigging toolset I’ve ever used. And the resulting rig is excellent, so fast and so good!
Thanks for your help Chris!
1 Like
I recommend you start a new thread in the Bug category so it doesn’t get lost in all this discussion.
All excellent points. But again, I suggest you make a separate Feature Request for every major thing you’ve brought up in this threads, so it doesn’t get lost in a long thread.
1 Like