Home Website Youtube GitHub

Range Switch breaks with a namespace?

Support
#1

Hi, I’m testing out the mgear rt-click menu’s Range Switch functionality, trying to convert an IK arm animation to FK.

It ONLY seems to work if my rig has no namespace. If it has a namespace, the script breaks. This is problematic since character rigs are generally referenced into an animation shot, not imported, so they will generally have a namespace.

Anyone know of a fix for this issue? The script works great if the rig has no namespace. Otherwise I get the following errors:

Can’t find object : arm_L0_fk0_ctl
Can’t find object : arm_L0_fk1_ctl
Can’t find object : arm_L0_fk2_ctl
Can’t find object : arm_L0_fk0_ctl

Thanks.

#2

it should work, if is not working with namespaces is a bug. I will check ASAP

1 Like
#3

is it working for you?

#4

Yes it is working for me with and without namespace.

#5

@AC10 can you please provide more detailed information?

  • Version of Maya (including service pack)
  • Version of mGear
  • OS
  • The full, complete error from your script editor, surrounded by ``` triple backticks so it formats properly as code.

More:

  • As for the objects it can’t find, are those unique names (with AND without the namespace)?
  • Did you change your naming conventions in your rig controls?
  • Are you testing the script with one character in the scene, or multiple characters? Does the result change?
  • Have you tested the script on a build of the example biped templates that ship with mGear? That will help isolate if it might be a problem with your guide settings.
1 Like
#6

@chrislesage i’m running Maya 2024.2.1, mgear 4.2.2, on Linux Rocky9.

the objects it can’t find are unique names, yes, with and without the namespace. they are the FK arm control names.

the only naming conventions we changed, as far as i’m aware, are renaming the “body” to “cog” and renaming “global” to “main”. the rest should be the same i think.

i’m testing with only one character (referenced) in an otherwise blank new scene.

i did test the script on a build using the example template that ships with mGear, and that does actually work just fine, referenced or not. i’ll have to study the differences between that template and mine. at first glance, one thing i’m noticing right away is that the rig builds with separated Trans and Rot ctls on the IK wrist. my template does NOT separate Trans and Rot. i’ll do some more digging.

this is the error i get in the script editor when trying to run the range switch on my rig:

Can't find object : arm_L0_fk1_ctl
Can't find object : arm_L0_fk2_ctl
Can't find object : arm_L0_fk0_ctl
# Error: AttributeError: file /rel/rez/third_party/mgear/4.2.2.x.0.1.0/ext/scripts/mgear/core/anim_utils.py line 1955: 'NoneType' object has no attribute 'hasAttr'
#7

i’m very confused… i tried building a test rig using my template, saved it, referenced it into a blank scene, and the range switch worked.

but if i reference in any of the other rigs i built with this very template, the range switch only works when the rig has no namespace.

my template is very very similar to the mGear default biped template. it includes very basic face controls: lip_up, lip_low, two cheek controls, two ear controls, nose controls, two brows controls, and basic eye controls (no lid controls). and that seems to build a rig that works with the range switch.

i then add more advanced facial controls using mGear’s “facial rigger”: eyelid controls, better brow controls, and lip controls. could the facial rigger somehow break things??

#8

getting the same error when trying to range switch the IK leg to FK:

Can't find object : leg_L0_fk1_ctl
Can't find object : leg_L0_fk2_ctl
Can't find object : leg_L0_fk0_ctl
# Error: AttributeError: file /rel/rez/third_party/mgear/4.2.2.x.0.1.0/ext/scripts/mgear/core/anim_utils.py line 1955: 'NoneType' object has no attribute 'hasAttr'
#9

ok… sorry for the multiple posts, but i seem to have figured out what breaks things. we run some scripts after building a rig that rearrange some of the top level hierarchy of the rig, and somehow that seems to break the range switch when the rig is referenced.

in the normal template, the top node is called “rig”, and main_C0_ctl (aka global_C0_ctl) is a child of “rig”. when the rig is organized in this manner, range switch works perfectly, with or without the face rig, referenced or not.

however, for various pipeline related reasons, we have been rearranging things slightly as follows:

  • top node of the rig is callled a control called “ALL” (basically a placement control to position the rig in the scene… all assets must have this node for our pipeline.)
  • “rig” is a child of “ALL”
  • “main_C0_ctl” (aka global_C0_ctl) is now a child of “ALL” (no longer a child of “rig”)

this rearranging breaks the range switch, but ONLY if the rig is referenced.

we honestly don’t use the range switch feature much, but i’m going to look into whether we could reorganize things in a slightly different manner so as to not break the range switch.

#10

THIS is the step that is breaking things. putting this back under “rig” fixes everything. i think we will adjust in the future.

1 Like
#11

Thanks for following up and digging into it.

Another point is in the script, that line error is

    def _getMth(self, name):

I remember once I built a different arm component which was missing the _mth node. I just added it manually, and fixed some similar but different problem.

Which is just to say, there might be other workarounds, like modifying the anim_tools script to suit your structure, or making sure you store the correct attributes on your top node, so it can point to the right things. I don’t know if the top node needs to be called “rig” or if it just needs to contain the correct metadata attributes or connections that exist on the “rig” node.

2 Likes
#12

Right, that makes sense. I am seeing the _mth nodes in the rig, but yeah, it might be that our ALL doesn’t have the correct nodes. I’ll discuss this further with my colleague who is much better at scripting than I am. I’m sure we can find a solution. Just moving the “main_C0_ctl” back under “rig” works. We need to toggle some inherit transform checkboxes to accomodate this change, but it does work. I think my colleague can script all of it so it’s automated. Thanks for the help!

2 Likes