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)
Cheers.
1 Like
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.
-Dave
First of all, yes I think there may be some bugs in mirroring code. (And I checked. mirror_controls.py 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]
try:
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')
d_shape.updateCurve()
except Exception as e:
log.exception(e)
2 Likes
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.
cheers
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
cheers.
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/mirror_controls.py", line 143, in mirror_button_pressed
# mirror_selection()
# File "/production/tools/mgear_3.6.0/release/scripts/mgear/rigbits/mirror_controls.py", line 15, in mirror_selection
# mirror_pairs(pairs)
# File "/production/tools/mgear_3.6.0/release/scripts/mgear/rigbits/mirror_controls.py", line 99, in mirror_pairs
# source_copy, mgear.core.curve.get_color(target)
# File "/production/tools/mgear_3.6.0/release/scripts/mgear/core/curve.py", 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:
- On line 99 of mirror_controls.py, it fails and gives an error, because it is trying to set the color to None.
- In
rigbits.__init__.replaceShape()line 410cnxis 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
Ah, great thing I was able to find this thread through the search box!
Yeah some of my controls also vanished after I used the Extract and Mirror functions. You can see in my Outliner, some shapes are gone.
Any idea how I could resurrect them?
Here are a capture of my guides and the final build where the control’s shapes are gone 
Thanks!
Actually the issue is even more puzzling… I tried to use the “replace shape” (wouldnt it be more intuitive to call it ‘copy shape’ or ‘transfer shape’?) then use the ‘extract Ctl’ which improves things in the outliner but somes shapes are still invisible and I get some really bizarre issues for some reason to the point that I have started to recreate my rig component by component in the end
The screenshot of the shapes being gone doesn’t tell us much. It would be nice to know at what point in your process they disappear. Or to know what you mean by “really bizarre issues”. And what version of mGear you’re using.
I once discovered that some of the controlBuffer shapes were instances. Which is bizarre to me. I’m not sure which functions extract them as instances. But if your shapes are instances, then any edits you do on your rig, will edit the controllers_org shapes too. So maybe some bugs are occurring because of that. controlBuffer sticking around when outside of hierarchy of export selected - #6 by chrislesage
From a backup of a previous rig. You can export the shapes out from the controllers_org group and import them into your latest working file. Otherwise the data isn’t stored anywhere where it could be resurrected.
I don’t see how that would be any more or less intuitive. It’s a replace function. It gets rid of the old shape (including none) on all targets, and replaces it with the specified source.
1 Like
Unfortunately I was just testing mGear and the creation process.
It would be very difficult to spot at which stage the issue started since I was working on different limbs and components until I finally realised the shapes were gone but it looks a lot like the issue mentionned at the start of the thread.
Currently I am using Maya 2019 and mGear 4.0.3. I saw there are new versions but I am more familiar with 4.0.3 and rather stick to something I know.
In the end I deleted a bunch of components and restarted from scratch and I am still having an issue with the shapes but I should open a different thread for it since it might not be related to extracting and mirroring shapes.
If you provide details to recreate the problem, it can potentially be fixed. Otherwise there isn’t much that can be done.
You say “extract and mirror”. Do you not mean mirror and then extract? If you extract, and then mirror, maybe that is what is deleting your shapes (possibly because of the instancing I mentioned). Extracting needs to be the last thing you do.
Actually it was a lot easier to replicate the problem since I knew it had to do with extract or mirror and now I can clearly see it is coming from the Rigbit > Mirror Control Shape.
I am amazed hardly anyone came across this before.
In the following example ( sorry I can’t show the geometry ), I am selecting the left ear’s shape and operating a Rigbit > Mirror Control Shape.> Left to Right in order to mirror that shape for the opposite ear.
As soon as I do it, a good chunk of the controBuffers lose their shape.
For now I will stay away from it then
1 Like
Ok thanks! Yeah that’s pretty bad. But judging by the fact that there is a “Selection” option, I think the option you’ve chosen must run on all controls.
And I’m guessing the bug must be related to the fact that the shapes are instances (which makes no sense to me. That should likely be revisited in design.)
As a workaround in the meantime, you should likely only choose “Selection”. And extract the controls after you mirror them.
1 Like
hehe why didn’t I think of just using “selection”! 
lol thanks for always being available Chris 
Wow! That is prety bad! I have created a ticket to fix it .
I didn’t found it before, because I always mirror from selection, so never use from left or from right 
Thanks for the feedback!
3 Likes