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.
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 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.)
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.
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.
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.
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
As a temporary workaround you can mirror using “left to right”. Then delete all the control buffers. Then extract the control shapes from the “rig_controllers_grp”. Should be good to go
@Miquel just want to add to the ticket. For some reason (haven’t found the source yet, might relate to the original problem), but sometimes when mirroring “left to right” or even on multiple selection, it doesn’t seem to mirror all the shapes. It also creates an empty null group. Had a fix now, by extracting the controls as is, rebuilding the rig then retrying the mirror.
If it is doing that, there is a very high chance you should be seeing some errors in the script output. If so, please share the error.
Sometimes if a certain attribute can’t be copied or connected, it fails. I’ve even noticed this if I have isolate selected turned on, because then it fails somehow on the connection to the selection set. (Or something similar.)
# File “C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\internal\pmcmds.py”, line 217, in connectAttr_wrapped
*# res = new_cmd(*new_args, *new_kwargs) # RuntimeError: The attribute ‘MayaNodeEditorSavedTabsInfo.tabGraphInfo[0].nodeInfo[896].dependNode’ cannot be connected to ‘head_C2_ctl2Shape.message’. #
@Miquel I think this should be considered a bug, what do you think? I don’t exactly know how to reproduce. But it seems if nodes are connected to things like sets, or views, it can cause these attribute connections to fail, even if the connections have nothing to do directly with the control icon’s parameters. (I wonder if that can be filtered by connection type somehow. Or explicitly choose which attributes/connections to transfer.)
Hello !
I was wondering why my controllers in “controllers_org” broke at some point. But i’ve found that when I use the tool Rigbits > Mirror Control Shape, and I check on “Left to Right”, then half of my stored controllers break.
