Home Website Youtube GitHub

"local_C0_jnt_org" removed between versions of mgear 4?

Hi,

In mgear 4.0.9 on Maya 2023, I have a Guide set which produces a rig root structure with “local_C0_jnt_org” between “jnt_org” and “local_C0_0_jnt”, and have produced a bunch of animations using Unity’s avatar system.

In moving to mgear 4.2.2 on Maya 2024 (to benefit from the bug fixes in Graph Editor) the same mgear Guides have removed the “local_C0_jnt_org” node. It’s cleaner no doubt but Unity’s avatar fails because the hierarchy has fundamentally changed.

Is there a setting I’ve missed in the guides between 4.0.9 and 4.2.2 that can retain the original structure?
What do you suggest?

SameGuides_Maya23_mgear409 SameGuides_Maya24_mgear422

I don’t have an answer for you. I’ve never seen that *_org structure. Because whatever I was doing was creating a completely separate skeleton.

But here’s one suggestion for you. It might not work for you. But it’s worth strongly considering if you can: Go back to 4.0.9, and don’t upgrade mid-way through a project.

I’ve been on projects when Maya 2020 had been released, and the studio was locked on 2016 until after release.

Thanks for the response and the advice. The project was coming out of a prototype phase so upgrading the software before locking down for the rest of the process has merit.
To that end it’s obviously very useful to be able to use animation made during the prototype phase and the changes to the hierarchy was unexpected. Much of everything else is fine.

I could probably find a definitive answer so apologies for being lazy but is 4.0.9 Maya 2024 compatible?
I’ve no problem using that version going forward if the structure is consistent

I’m certain it’s not 2024 compatible. The release says “2023” and there is no folder for 2024 plugins. If you grabbed plugins from a later release and just put them in the folder, would it work? eh… maybe?

(I’m still on Maya 2022, and for reasons I wish I was still on 2020! :sweat_smile:)

Totally. I hear that. Personally, if I were committed to upgrading, I’d look into a workflow for automating a bake process to transfer animations from the old rigs to to the new skeletons.

I’m not even sure how you’re getting all those _org groups. I loaded 4.0.9 and I don’t get that. I tested the biped template, and epic template. And in all my old rigs since the 2.6.1 days, I never had that. (Did you start from one of the Shifter templates?). If you’re doing a game that needs to be mobile/VR/Switch friendly, you’ll likely need to keep those counts down. Do the groups get turned into bones in Unity? I don’t know what the optimization implications would be. Did your prototype get that far into testing target platforms?

BUT, if it’s working, it’s working. Otherwise second option if you’re committed to upgrading and having the old hierarchy, I’d check the code to see what changed in the Shifter components or in the build process that changed that hierarchy. And fork my own version to put it back. Or hack in a post-script to add the parents back.

Third option is to investigate the “Connect to existing joints” and keep your old skeletons. But then you’ll end up with a maintenance pain.

Fourth option is someone who KNOWS answers you and maybe there is a simple checkbox. :slight_smile:

I wish I had better ways of impressing you, Chris! :smile:

I didn’t start with a Template iirc. I believe I was putting the rig together using components in conjunction with following Miquel’s tutorials, at that point the first time I’d used mgear. The animations had been working fine and it was only when I was checking out 4.2.2, necessary for Maya 2024 that I’d encountered the issue…
I could send you the guide export if that’s helpful, or provides an answer to your never having encountered this issue?

It’s interesting that the issue appears to be solved in 4.2.2 using the same guides, at least insofar as the structure is more typical.
There are a number of ways we can go and thanks for the options you’ve suggested.

1 Like

Sure! I don’t what the “export” would do. That would work if it doesn’t change your structure in any way. Otherwise can you send me an original guide scene? (Delete your geo and rename any IP nodes if you have to.) Then sure, I can take a look. (You can DM me a link, or I’ll send you my email.)

A screenshot of your guide in the Outliner might be enough of a clue. Were the components separate rigs by any chance? Or was it all contained and parented as one single guide? (Although if the guides were separate, I think it would build completely separate rigs… I think.)

If you load up a Biped template just to compare what the guide looks like, does it look very different than what you had built?

@Jay Same here, I am not sure about this groups. My memory is very weak, but I remember that happening :sweat_smile:
I was checking the release log just in case, but didn’t see anything related to that
https://mgear4.readthedocs.io/en/master/releaseLog.html#id11

Thanks to both of you for the replies.

The Shifter components were all built under a single guide as per the tutorials, so generates only one rig.

Following your suggestion, I loaded a 4.0.9 Biped Template, built the rig and a _org node is generated in the root structure as spine_C0_jnt_org. You can compare Rig and Rig1 below

I’m happy to email or DM a guides only file to you, Chris. Is the Message option on this forum the best DM for you?

  1. The why

In your guides, you have a bunch of loose controllers that have no parents. It seems that’s why those joints were getting an org group. That seems to have changed in 4.2.2 (or earlier). This doesn’t have anything to do with Maya 2024.

(If I build in Maya 2023 with 4.0.9 vs. 4.2.2 I have org groups and not, respectively. So it’s just something that seems to have changed sometime between 4.0.9 and 4.2.2)

  1. The WHY? :slight_smile:

In your rig, you have a bunch of loose controllers and joints that don’t follow the rig. I guess you end up having to constrain them in post scripts or additional steps?

The Biped template has that too. But only for the UI nodes. Those nodes don’t have corresponding joints. And you can attach them to the rig by parenting the guides, or by giving them a single space switch to follow. I make mine follow my COG control.

And when I make something like a weapon joint, I still make sure it’s parented under the root, and all the other joints are under the root. Even if there is a root-motion control to be able to move the root independently. (More for Unreal, maybe?)

Anyway, none of that matters if your rig works!


  1. The what-to-do:

Again, I’ll just say I would personally clean up the rig and have a clean skeleton going forward. But I get it if that would be too costly to fix up all your existing game systems.

So here is a potential alternative. A Python post-script which should be general enough to be able to run on any rig, and commented enough for you to fix if it doesn’t suit all your rigs. But I made this with only one example rig. So ya know… test. :sweat_smile:

  • It looks through all the first-level children of your guide.
  • If there is a matching joint, AND if that joint doesn’t already have a jnt_org group:
  • It will add that org group at origin, and parent the joint under it.
  • So on the guide you sent me, if you run this on the build 4.2.2 rig, it will add the extra _jnt_org groups for local, root, and gun.
import pymel.core as pm

guideRoot = pm.PyNode('guide')

for eachGuide in guideRoot.getChildren(type='transform'):
    # After the rig is built, it will name clash, so find only the shortest name:
    shortGuideName = eachGuide.name().split('|')[-1]
    # Then grab the first part of the name. Example gun_C0_root -> gun_C0
    nameToken = shortGuideName.replace('_root','')
    # Then check if (example) gun_C0_*_jnt exists.
    # This finds every joint that has a corresponding UNPARENTED guide root.
    matchingJoints = pm.ls('{}_*_jnt'.format(nameToken), type='joint')
    # If that joint is found, then add an npo and name it _jnt_org
    if matchingJoints:
        # Get the first one in the list since we were searching by wildcard.
        # We searched by wildcard because the joints have an additional _0_jnt or _root_jnt name.
        matchingJoint = pm.PyNode(matchingJoints[0])
        # Also make sure it doesn't already have that group. If so, skip it.
        if matchingJoint.getParent().name() == matchingJoint.name() + '_org':
            continue
        print("adding joint_org to {}".format(matchingJoint.name()))
        # Add an empty group. In 4.0.9, the jnt_org group was at origin.
        npo = pm.group(em=True, name=matchingJoint.name() + '_org')
        pm.parent(npo, matchingJoint.getParent())
        pm.parent(matchingJoint, npo)
2 Likes

Chris, thank you so much, I really appreciate your time on this!

The advice makes sense and I’ll try doing as you suggest, spending a little time fixing the rig, and seeing what if anything breaks within Unity. Otherwise I’ll try the script.