Trying to populate these interlocking polygons over a surface… and failing… miserably!
There is to be material thickness between the polygons, and thickness to the mesh.
Like this
Watched the excellent videos recommended by Scott in this thread:
I am not sure how to create a grid of points with a specified distance apart, surface the gaps or wrap the result onto a curved surface.
The video uses a mesh to give it thickness.
P.S. Here is another “sketch” that demonstrates three things:
The Bounding Box is scaled slightly larger with different factors for X and Y so that the mapped hexagons don’t touch the edge of the target surface.
The areas of the mapped hexagons are not the same, they vary from 25.86 To 42.42.
SrfSplit and Area are very slow! So SrfSplit should be disabled while messing with params to map the hexagons.
Another way to do this that would result in the mapped hexagons being closer to the same size is to map only the points and then construct the “irregular” hexagons in place using surface frames.
Well, that didn’t work out very well. The mapped hexagons are indeed nearly identical in area but they are crowded together along the top so are too close together there and too far apart in the middle.
I don’t know if this is useful to you but I extruded the offset around each mapped hexagon. Had to reverse the surface normal to extrude “out” instead of in. As you can see, the cyan group is extremely slow, the better part of three minutes, so I disabled SrfSplit in the attached file. This is a variation of version ‘b’ posted earlier.
Thank you Joseph. I will explore these ideas some more.
Typically I create the shape, surface it, replicate it, extrude it, punch holes in the target surface and then convert that surface to a mesh in a separate .gh file because the processing can take 30 mins even on a fast machine.
Thus whenever that file is opened to work further downstream on the model that uses that surface, you need to take a long coffee break! I use the DATA OUTPUT module to write the surface to file on disk and just read it into a new .gh file.
In the video Scott linked, he suggests that converting to a mesh and using thicken makes all this virtually instantaneous and that the resulting surface is a valid degree 3 surface.
53:00
Weaverbird Thicken instead of extrude
Once I am able to successfully position the irreg polygon and loft a surface between all of them as he does, I will experiment with this too.
I note that punching holes to create a realistic metal/plastic mesh grill is a full time job for this designer, which in 2021, is more than a little surprising. Unless I missed it, there is only one thread on this forum that deals with Automotive grills in any depth, and as TOM points out, most of the solutions are utterly impractical to build.
Perhaps I will respond in that thread and hope he sees it and has some ideas for what a production Grill
I won’t have time, since I’m not running Rhino on my current computer.
A while ago I posted an unfinished gh adding here.
It offers some components you might find useful:
It offers a working flange/draft component, you can crown and extrapolate surfaces with it. It may be helpful for you. Be aware, i never finished it, and some functionality is not working well. Also make sure to stay on non-rational Beziers.
Also have a look at the section I have posted in the other thread. that should be a guide line.
This is because CAD is usually single threaded. Many operations are not thread safe, and so are not suited for parallel processing.
I would try _filletEdge in Rhino. Not all, divide and conquer. You could even split the geometry, open multiple Rhino instances and fake parallel processing. The more lightweight the surfaces and the better they positionally match, the more likely autofilleting works! One of the least known reason to model anything in non-rational Bezier representation is performance.