SubD Symmetry?

Good point, a simple XY XZ ZY bullet option + a tilt in degrees from -90 to 90 degrees would be all we need. + a plane from 3 points of course.

And aybe this is the time to wish back the great animated, reflective water plane that @jeff made for the v5 wip… It was great for both architecture close to the water and for boats on the water… :stuck_out_tongue:

1 Like

Have you tried this plugin: Flipper Modo Plugin. It should help with more than one axis symmetry. I haven`t used that.

I make 1 axis symmetry with mirror meshOp in Modo. I think with that MeshOp should be also possible to have more that one axis symmetry.

For radial symmetry there is also: Wheely Modo Plugin

the reflect command continues to develop, and jeff is working on a ui that shows the line of symmetry and a color for the reflected half.


Kyle, another weird thing about the current tool: you go about selecting a bunch of stuff on the reflected side, and you go to move it just to realize that was the no-touchy side. Could you guys fix that too please?


jeff is working on a graphic indicator for the no touch side.


RH-57206 is fixed in the latest WIP

On first impression it looks good, with the Display Mode override option.

Would it be possible do ditch the no-touchy-side concept altogether?
When modelling with symmetry, you sometimes see a detail you don’t like / want to change from a certain angle, but if it happens to be on the child side, there is no possibility to change it right there. This felt limiting when I tried it out and I kept wondering, why this limitation has been chosen in the first place.

Sorry if I missed an earlier discussion of the importance of the no-touchy-side, just wanted to possibly reiterate, why I personally think it would be nicer to ditch the concept and let the users have more freedom in interacting with a _Reflect object


Just saw @leex comment, you can add my vote to being able to edit both sides :slight_smile:


latest wip with the new display for reflect-

I see several requests to mod both sides, but how is that different than our current parent child relationship for history?

remember you can always kill reflect, mod the child side then re-reflect using it as the parent…


Hi Kyle

I think that to edit both sides with the history, after each change, turn off the history and then automatically mirror with hidden mode for the user.

That is so.
History is always off.
Editing for example a parent. Made a change - a reflection without history. Just constantly reflect the side over which the changes were made.

Or with a story, but until started editing the daughter side. Block the daughter side is not necessary.
If we edit the daughter side, then we reflect it and it becomes the parent and the other side the daughter

I hope I clearly stated my thoughts :slight_smile:

The difference is that it is clumsy.
This maybe able to do almost or even exactly everything that the standard sub_D-symmetry implementations in just about any 3d modeling program is able to do, but it is very convoluted and requires to much user intervention/attention.
Usually you turn on symmetry and every action on any one side of the symmetry axis reflects (doh!) automatically on the other.
No need to re-invent the wheel.

To me it seems the Reflect command should be used as a way to

  1. create a symmetrical object in the first place.
  2. re-establish lost/broken symmetry.

it should not replace the normal symmetry method [used every where else].
if it is just a fill-gap method to allow us to work while proper symmetry is being developed? then that is very good temp solution. But it [as I feel many user would agree] is not the right method going forward. replace actual/regular symmetry.

I see reflect as similar to the Mirror & Weld faction in Zbrush, with Rhino History added to it.

thanks a lot

Concur: The difference is that it is clumsy.

It does both of these things now but you do need to define a reflection plane. The second if you use the same reflection plane again.

I don’t see one approach across apps. For instance in Blender you need to cut the model in half first and then add a Mirror modifier, in Maya you could use Mirror or enable Symmetry for the mesh object for it to persist and in ZB it’s a transform setting per tool. Some Rhino users helping test this wanted to know what side was the parent visually which led to what was added, others want both sides to be the parent and others want the child side to not be selectable at all. I don’t believe these two were possible now. We can make changes to how Reflect works of course but it’ll help to know what the biggest pain point is now, or what is requiring too much intervention.

Personally I have found Reflect really useful and it matches the Rhino command workflow versus object property idea poly modelers with modifiers use. Rhino doesn’t have much of a history with stuff like that, the closest being custom render mesh properties.

You could Turn off the reflection and then re run it. Or maybe a flip option.

I broadly agree. What might be cool is the child side updating live, whilst gumball dragging on the parent side for example.

I obviously do not know EVERY 3d modelling app, so you might very well be right (and I don’t doubt it) that Blender and Maya have approaches to symmetry similar to “Reflect”.

But in nearly every other app I used that had some kind of symmetry modelling it worked as the following:

  1. Establish or define symmetry in model (here the axis is defined too)
  2. There is no point 2
    From now on every transformation, extrude o whatever modeling operation is applied to whichever side of the model, it will be applied to the mirrored side too.

I hate to point out the obvious but have a look at symmetry in T-Splines.
T-Splines was not free of flaws but it nailed symmetry IMHO.

1 Like

My vote.
Friends vote for this option. I think this is the most important at this stage of the Reflect tool

I agree TS symmetry works great.


Another vote for Tsplines style symmetry.

To be completely honest, Tsplines style symmetry is actually why I brought my first copy of Rhino and Tsplines and why I still use Tsplines daily.

Almost everything I do has a at least single symmetry plane, and 90% has two, x and Y. Tsplines gave me this built in and then taught me control point manipulation and SubD work flows.

But it’s the symmetry planes and the ability to grab any point on the model and know the partners will follow, that’s WHY I own Rhino, because Tsplines give me that work flow.

Please just copy that system and be done.




This is exactly what I was think as well when - “concurring”

Full disclosure - I haven’t even tried to use Reflect, so it’s possible I haven’t a clue…But in reading, I thought to myself… really… why the complexity?

As an F360 TS user, all I can say is: if I define a symmetry plane, I’m designing a symmetrical object. Why would I choose not to immediately visualize that symmetrical development, and what do I care between parent side and child side of a symmetrical object? And if I no longer want symmetry (such as I start with symmetry initially to get to stage A, then deviate to a form which is no longer symmetrical for stage B) I turn symmetry off at that point.

Maybe I’m missing some valid use cases here???


Yes. and this is where Reflect is working great. But it is not proper symmetry, and like other here are saying, I feel Tspline style symmetry is the better direction.
we do need both of the commands:
Reflect : to repair or establish the initial symmetry.
Symmetry: to run symmetrical modeling on previously established symmetrical objects.

thank a lot