anyone else experiencing a refusal to remove the reflect symmetry on subd?
it seems buggy, any advice?
This is an annoying bug that have been reported several months ago and is still not fixed. But here is a workaround until then: Simply select the SubD model, use the ! _Explode command, then delete the unnecessary symmetry copy of the original SubD. 
1 Like
@zale_orcid or @Rhino_Bulgaria Could you share an example of this or a link to the previous report? This sounds like it should be on my list but I can’t find it in our bugtrack system or on Discourse. Thanks.
I figured out another work around from @Rhino_Bulgaria — which I have used since the beginning. I think it just got so annoying yesterday that I couldn’t resist putting it up here.
I do not have an example. However, I can say that it’s usually when I have 2 reflections on a subd object. Once I have that. If I go for the reflect command, the option to remove the symmetry disappears. I’m just kind of like, stuck with symmetry on. When I go to mess with the only options it provides, it will somehow make mirrors of my entire part in both the y and x - – depending on how much I fool around with it. Finally, once I realize that’s happening normally after I zoom out and see them… I will have no choice but to delete them.
I’ll be working in subd for the next month probably so I’ll post if it happens again.
The _RemoveSymmetry command is there to remove symmetries.
The _Reflect command only offers the remove symmetry option when the object: 1. already has an existing symmetry and 2. this symmetry is compatible with adding a second reflection. When there is already a double reflection present, _Reflect would not be able to add a third reflection, so it treats the object as if it had all symmetries removed and offers the normal pick a plane / XAxis / YAxis options.
It also prints a message about what it is about to do in that case:
"
Selected SubD already has a non-compatible symmetry.
Continuing will remove the existing symmetry.
"
Please do post again if you find a case where _RemoveSymmetry or _Reflect don’t work like this.
Typing “Rhino remove symmetry” in google pointed me to other Discourse posts that also tried to use the remove symmetry option in _Reflect instead of _RemoveSymmetry. I updated these posts too with the new solution.
Can’t find any mention of the _Explode trick but hopefully that will help people finding their way to the correct command
Yes I have tried _removesymmetry (by itself) for this when I’ve used up both x and y reflections. Did not work. I forget what happens, but I think you click the object that’s being weird - and it does nothing. I’ll make sure to post, thanks @pierrec
Maybe you can make something that can clear all symmetry from all objects no matter what?
That’s exactly what _RemoveSymmetry does. Let me know when you come across another object acting weird, and we can take a look at what goes wrong.
Maybe some of the confusion will be cleared up by the help page for the XAxis/YAxis options:
This part:
Command-line options
XAxis / YAxis
Reflects the SubD across the x or y axis of the active CPlane.
- The reflection plane set by XAxis or YAxis options does not move with the object.
- The reflection plane set by picking two points moves with the object.
Reflection planes set with the XAxis/YAxis options work differently from the ones set by picking two points. That could be what you mean by objects that are being weird. I imagine if you set a XAxis reflection on a SubD that already had a double reflection, and that is far from the XAxis, then if you only look at the original part of the SubD _RemoveSymmetry appears to do nothing. Here’s an example:
I don’t remember those topics, but here is a quick example showing that the command for removing the symmetry does not work as it’s expected:
Edit: The 4K quality of the video is still being processed.
@Rhino_Bulgaria It looks like that button is using the old bad trick (! _Reflect _Pause _RemoveExistingSymmetry) instead of the correct command which is ! _RemoveSymmetry. I don’t know when it was set to that or why it is not updated with a new installation.
You can change the definition of that button to use ! _RemoveSymmetry instead, or run the ToolbarReset command in a recent version to reset all you buttons to the current defaults.
1 Like
I have seen other people complaining about this legacy command that didn’t worked on their Rhino 7. Looks like there is some issue with the SubD panel specifically when it comes to updates. About a month ago I figured out that my SubD panel lacks one icon with a tool that I have never seen before.
Just tried the ! _RemoveSymmetry and it works as it should. Thanks for the advice! I replaced the old RMB command with this one.
Hi Bobi -
This is not an issue that is specific to SubD tools. As users tend not to create separate toolbar files when they customize the interface but simply modify the standard toolbars, toolbars are not automatically updated when new versions of Rhino have modified toolbars. The only solution is to run ToolbarReset that will update all default Rhino toolbars to their new defaults.
-wim
1 Like
I only changed several icons in the SubD toolbar last year. Is that a reason for the toolbar to refuse to update itself after the numerous updates of Rhino 7?
No.
It never updates itself.
Doing so would remove all customizations.
-wim
I mean, updating all icons and commands less the ones that were customized by the user. Also, adding newly introduced commands and icons while keeping the custom changes intact.
Hi Bobi -
I’m trying to explain that the behavior that you describe here does not happen.
Apparently, that is changed in Rhino 8.
-wim
Thanks for the explanation! So, basically any customization of the toolbars in Rhino 7 will prevent them to update with any newly added commands?
No.
Even if you don’t customize any toolbars, they will not update. You always have to do that manually by running the ToolbarReset command.
Rhino has no way of knowing if a user has modified a toolbar or not. It therefor can’t update them.
-wim
That’s pity, because in this case users can be leaved unaware of some important new commands and icons despite regularly installing Rhino with the Service releases. A simple check if the code is same or modified should tell Rhino if there is any customization done by the user.
Anyway, seems like I have to carefully save all my custom macros and icons and reset my Rhino 7, then apply them again over the reset toolbars.