Website Youtube GitHub

mGear Framework Forum

controlBuffer have no shapes

I’m finding that often the controlBuffers are empty groups and therefore after a rebuild of the rig the controls don’t have shapes either. Is this a known bug? It seems like it’s happening on anything that is marked as “center”, either that or its todo with being zero’d on world X.

I’ve found the cause. It’s the menu item “Mirror Contols” - “Left to Right”.

It’s seemingly killing the shapes under controls in the buffer group. “controllers_org”.

At the moment, I’m shaping controls on the left side, throwing them into the controllers_org via the extract control button. Then I’m shaping central controls. Sending those to the buffer also. Then on a rig rebuild I’m mirroring the controls as a currently manual post process. That’s when the buffer gets corrupt.

If we decide to move to mGear, I can fix this, but until then, it would be nice to gauge feedback (testing the forum / bug response I guess)


Can you say more about what you’re doing in your manual post process?

And what are you doing to mirror them? Is this your own custom code? Or are you calling the Rigbits mirroring functions in your manual post process? When you say “post process”, do you mean a Shifter post custom step?

Can you help us recreate what you are doing? For example, sharing this post process code (or steps) you are running.

Also, what version of mGear?

I’ve done a quick test in mGear 3.6.0 and can’t easily recreate any problem using Rigbits -> Mirror Control Shapes, and then extracting them.

1 Like

Hi @chrislesage

I’m using vanilla mGear, no scripts at the moment. Just the menu buttons provided in the mGear toolset. I’m on 3.3.1

I tried to explain the process above, not well, I’ll try again.

I’m building the rig multiple times from the guide.

Once a rig component is working I shape the controls on the rig and then capture them in the controllers_org group with the mGear "Extr. Ctl. button.

I’m only doing left and center controls, after each rebuild I’m running the menu rigbits>mirror controls menu with the “left to right” option. I do this each time I rebuild the rig. It’s at this point that the shapes get corrupt under the controllers_org group, and by corrupt, I mean the transform has its child shapes deleted from the controlBuffer transform. Subsequently, the next rig build is corrupt with missing shapes.

I can get over this issue, by keeping an eye on the controllers_org group and when I see a control that is corrupt, I select that control in the rig and re-run the “Ext. Ctl.” button in Shifter.

I’ll investigate further once I have a finalized rig and can step through the code as this happens. It might be an order of operations issue as I’m new to mGear.


First of all, yes I think there may be some bugs in mirroring code. (And I checked. does not seem to have changed since 3.3.1, so upgrading won’t make a difference.)

I’m investigating a bit, and I did find one definite bug. If one of my controllers doesn’t already have a shape under it, the script gives an error and fails mid-function, leaving some broken nodes in the scene.

My guess right now is that you likely have some errors happening when you run the Mirror Shapes command. Can you check and paste the output from your script editor?

The “Selection” option in Mirror Controls seems to work just fine, as far as I can test so far.

1 Like

Hi @chrislesage

I’ve not had chance to dig into this further, but instead, to help me while I’m developing the rig, getting a feel of the mGear framework, capturing my troughs etc. I’ve bypassed the issue by utilizing our internal code for mirroring controls from our tools. As an alternative to duplicating nodes and scaling by -1 and re-hooking up connections, we do that in memory and just update the cvs’ on the shape node, leaving the connections as they are.

This idea needs more testing, but for now, it seems to work well.

for source in rigbits.mirror_controls.get_controls_without_string("_L"):
    target = rigbits.mirror_controls.get_opposite_control(source)
    tdtools.core.rigging.mirror_rig_shape(source, target)

Where our code looks like…

def mirror_rig_shape(source, dest):
    Mirrors one shape to another.
    :param source: str or PyNode (transform)
    :param dest: str or PyNode (transform)
    :return: None
    source = pCore.PyNode(source).getShapes()
    dest = pCore.PyNode(dest).getShapes()
    for ii, sourceShape in enumerate(source):
        d_shape = dest[ii]
            s_cvs = [[p.x * -1, p.y, p.z] for p in sourceShape.getCVs(space='world')]
            for i, c in enumerate(s_cvs):
                d_shape.setCVs(s_cvs, space='world')
        except Exception as e:

Cool thanks for the update. When I get a chance, I’m going to review the mirroring code and see if there are some improvements I can find and make.

1 Like

Hi I’m having the same problem with the controlbuffers having no shapes. Mirroring the controls also destroys my Maya prefs. After mirroring the controls and breaking the shapes the IK also breaks ,even on older rigs that where fine.I have to rebuild my Maya prefs folder to get everything working again.
Any one else having this problem with mgear 3.6.


Hi @craigb Can you please include some information like:

  • errors you are seeing in the script editor.
  • What version and revision of Maya.
  • What steps are you taking afterwards to extract controls? Do they disappear from the controlBuffers when you run the mirror command, or afterwards in a different step?

What do you mean that your Maya prefs are being “destroyed”. Can you please explain what you are seeing happen?

A screen capture or a gif, or some detailed step-by-steps would help a lot. Or perhaps upload your rig so someone can try to recreate your problem.

Hi Chris.
sorry the maya prefs thing was driver error and not related.

The problem doesn’t happen all the time but here is a link to a rig where the right leg ctrls
aren’t being made after mirroring.

It seems to happen after extracting the ctrls , mirroring them(left to right) and then rebuilding the rig.
Again it is intermittent .
I’m using Maya 2020.2 and mgear 3.6

1 Like

Ok yes, there are some bugs with mirroring, it would seem.

I get the following error when attempting to mirror:

# Traceback (most recent call last):
#   File "/production/tools/mgear_3.6.0/release/scripts/mgear/rigbits/", line 143, in mirror_button_pressed
#     mirror_selection()
#   File "/production/tools/mgear_3.6.0/release/scripts/mgear/rigbits/", line 15, in mirror_selection
#     mirror_pairs(pairs)
#   File "/production/tools/mgear_3.6.0/release/scripts/mgear/rigbits/", line 99, in mirror_pairs
#     source_copy, mgear.core.curve.get_color(target)
#   File "/production/tools/mgear_3.6.0/release/scripts/mgear/core/", line 317, in set_color
#     shp.overrideColorRGB.set(color[0], color[1], color[2])
# TypeError: 'NoneType' object has no attribute '__getitem__'

if the mirror target doesn’t already have a shape:

  1. On line 99 of, it fails and gives an error, because it is trying to set the color to None.
  2. In rigbits.__init__.replaceShape() line 410 cnx is an undeclared variable.

The error quits the mirror process, leaves your rig in a broken state, and then users try to extract controls on something with no shape.

@Miquel I made a PR to fix these two particular bugs. I’m not sure if the other people who were experiencing this were getting other bugs too.

There is one side effect of this. If the target shape doesn’t exist, when it mirrors, it will not set the color. So it will have the same color as the opposite side. (When you rebuild the rig, it should set the colors properly.)

1 Like