While Zbrush’s radial symmetry is very nice that feature is not comparable. The extremely dense mesh is getting realtime-displaced by brushes – it works with meshes of arbitrary topology as input and only moves the individual vertices in space. Some shading tricks let everything look nice and smooth.
In subdivision surfaces symmetry across one or two planes is easy to accomplish and common, for radial symmetry one had to manually rebuild the cage (when e.g. changing radial divisions from 5 to 7) to retain a valid mesh layout. I don’t know a single SubD program that does this.
Considering editing an entire object built using symmetry tools it occurred to me to ask:
Should there be a kind of master/slave relationship between the one segment that is editable with the rest following automatically? This would require some type of unique visual depiction of the master section - something that would also serve to define the whole object’s status as a symmetrical object. That would mean some kind of scheme to govern when the display mode is turned on - automatic would be best, but how would it work?
Or should all the segments have a peer relationship so that no matter which part of the object is edited or adjusted the rest just follow - perhaps surprising a designer who didn’t realize the object was a symmetrical one the first time he/she works on an inherited project? Of course, in this case especially, but actually either way, the object’s identity as a symmetrical object would need to be included in the properties display.
You can apply all manner of transformations and deformations to a selection set in Rhino, so what’s to stop you from selecting control points belonging to multiple segments and dragging them in a way that would break symmetry?
Good point. Of course at a minimum Rhino should recognize that situation and issue a warning. Maybe the answer is to not allow the user to select more than one segment or perhaps when more than one segment is box selected just highlight one of it’s own choosing. Or maybe use the usual multiple selection possibility dialog to let (force) the user to choose which one he’d like to use.
There’s also the case where a user might start with a symmetrical object but actually WANTS to destroy the symmetry as the next step in modifying the object. I suppose the answer to that is to do a special kind of join for symmetrical objects that transforms them into a single normal object.
Partial symmetry would be awesome
Symmetrical modeling has been on the wishlist for as long as Rhino has existed. The addition of SubD is not going to come with symmetry tools, as any creation of symmetrical modeling also would apply to curves, surfaces, etc.
Our goals for SubD in Rhino 7 is to add support for creation and editing of this new geometry type. Symmetrical creation and editing is not in the scope for V7.
Thanks for the info Brian - I guess I’ll have to ‘roll my own’ in GH to get what I need.
symmetry and radial symmetry is a pretty crucial need for a sub d modeler at any level.
yup Kyle, I’ve been trying to SubD model in V7 without symmetry. SubD modeling in V7 is still very rough. It’s like a cold shower: It does the job, but man, it sucks compared to a hot one. …But modeling without symmetry is like showering without soap: It doesn’t really work.
I already told Brian here:
2 posts were split to a new topic: Fusion Integration as replacement for T-Splines?
Unlike Nurbs, SubD surfaces change their form when uncreased edges are welded together, so to visualize one’s end result, it would be great to be able to automatically model in radial symmetry in real time.
When modelling in Clayoo with symmetry on, as clunky and awkward as the UX is, the symmetry makes it easy to make sure that the shape near the symmetry line will turn out right.
Clayoo lacks tools to snap it’s subD surfaces’ vertices to rhino objects, but Rhino SubD, even at this early stage, has those tools. This means that all one would have to do to guarantee a smooth, tangent seam at a line of symmetry would be to snap vertices to a straight line that crosses the symmetry line. There appear to be features in Xirus that do this even better. Come to think of it, if I was McNeel, I’d consider buying Xirus, integrating it’s features into Rhino, and creating optional simplified UX for some of Xirus’ over-complicated procedures.
Bumping this thread, as I’m playing around with the WIP, not having symmetry makes it very difficult to do SubD modeling.
As mentioned in this thread. T-Splines may not have been perfect, but the symmetry was dialed for sure. Hope this is on the to-do list for V7
I’m sure they’re working on symmetry now, with so many people requesting it.
But if it’s going to take a while for symmetry to work for SubD in rhino, could we at least get the Brep Join component in Grasshopper to work with SubD input? That would allow a very short Grasshopper definition made mostly of Mirror and Join components to do SubD symmetry in any direction, including radially and other options more complicated than simple bilateral symmetry like Clayoo includes.
Hello - Since GH will use Rhino Common, most likely any Symmetry that is implemented there will be in Rhino as well, most likely first…
Aaah… yeah, finally we hear official confirmation from McNeel that symmetry is in fact coming to V7.
Thanks Pascal and all your team in the typing pool.
I thought I hedged that pretty well with conditionals and hedging.
I am confused: joining SubDs is possible and easy in Rhino7 WIP.
That being the case, why is a Grasshopper component that joins SubD objects not currently possible?