Hi
A request for the Upcoming [soon] Radial Symmetry: In regular Radial Symmetry there’s an axis and a defined number of symmetry points [as far as i get it from a purely user perspective] and all these points lay on the same defined plane [have same hight].
Which is all that is needed when working on a planer surface or a sphere [with the same curvature in every direction].
But on a double curvature Srf or any other more complex object. That [Planer] radial Symmetry does not work correctly.
So the request is to have an option to define the hight of each symmetry point. perhaps like this it can work…
call the command
select object
define symmetry axis
define number of symmetry points
points are now visible on the same plane as the axis point
Enter. or…:
define point distance from axis [or click a location]
With an option to select each symmetry point and snap it to the correct hight on the object or define an hight for it in space.
Looking past the horizon perhaps…
I would have hoped this is already in development, even if in early stage? So I put that Hight-Individuality request.
as I see that limitation in other App that has the regular Radial Symmetry
Maybe that’s new? I couldn’t get it to work a few months ago.
I’ll give it a shot. That would allow radial symmetry in grasshopper, as long as the user keeps the edges of the master wedge planar. Somewhat limited, but doable. The SubD Union tool @DanielPiker is working on would make it perfect.
Apparently not? A few months ago when I was trying to make smoothed versions of geometric tilings using subD and brep join, I had to convert to mesh and back.
I can see how it’s confusing since the Join command works on Breps and Meshes outside of Grasshopper but in GH they are separate and the Brep Join doesn’t work on meshes which are more closely related in this case I think to SubD.
subd-mirror-PolarArray.gh (21.8 KB)
Problem with that is that it won’t support ngons. These will be converted into triangles by the mesh weld component.
A bunch of mesh components break nGons, and pentagon faces on subDs are common enough that this can be a problem when moving subD objects to mesh and back.
Somebody made a python script that adds ngons to meshes, but it’s just calling _addNgonsToMesh, so it won’t fix non-planar ngons.
The subDcontrolpolygon component preserves non-planar ngons. I don’t remember all the mesh components break them. I know explodemesh breaks them. I also remember that when I was writing this definition, I had to convert to breps and back because mesh components were breaking up planar ngons.
I see these issues as a good case for creating a subD join component. Either that or a lot of mesh components need to be rewritten with a “preserve nGons” boolean toggle input.
Is there separate subD join in RhinoCommon? could a python component run it?
No, it’s not exposed in RhinoCommon (yet). If McNeel gets it working like the command Join now works for SubD we basically have full radial symmetry in gh
Basically if you work in full quads (which is good habit anyway) you can already make all the cool stuff or use the above method to have a live preview, then when ready bake the separate subds and join, that’s how I do it now.
Full quads is a good habit, but braking rules is fun. Also, things like starpoints and imperfect surface continuity aren’t big deals for me, because my medium is CNC carved wood: it’s all getting sanded anyway, so small imperfections disappear.
Like, the definition I linked to is 100% pentagonal faces. If the discontinuities and edgelines that show up in my zebras are less than .005”, they’re irrelevant.
Here are some of the aggregations I could find when I played around with some of the weirder things that RhinoPolyhedra can make. The polyhedra with few faces, especially those with non-convex faces and other oddities make some interesting results when piled on eachother and converted to subD: