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?
(Kyle Houchens - McNeel and Assoc. )
jeff is working on a graphic indicator for the no touch side.
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
(Kyle Houchens - McNeel and Assoc. )
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…
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
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
create a symmetrical object in the first place.
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.
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.
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.
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.