I couldn’t use your GH file because I don’t have all those add-ins, but I did recognize the opening shapes of the piece you showed. If I am not mistaken it’s a squircle,
which I first found out about here:
I made the attached GH script based on this and it might help you find a way to make the shape you showed.
To make the shape maybe you could extrude 3 squircles, sit them on a larger extruded rectangle with filleted corners, and then use FilleEdge to blend all the intersections. I’m going to try that myself.
squircle.gh (10.5 KB)
Here’s my first attempt at what I suggested above.
It may or may not be able to achieve the final desired effect because the FilletEdge component is fairly finicky; for reasons I don’t know it was unable to make a larger fillet between the square pipes and the base.
Also, I had to edit by hand the edge indices provided by EdgeCvx in order to remove the internal edges at the bottom of the square pipes. If I included these the max fillet size that worked was much smaller.
Finally, note that for 3D printing I have to stick with closed BReps. This means I need to avoid overlapping surfaces (particularly fillets in this case) and other geometries that result in things other than closed Breps.
squircle2.gh (27.6 KB)
2 Likes
From the image alone, it looks like the two fillets in the foreground are about to overlap, which would certainly cause failure. Yes, looking at the model, that is clearly the case.
The white groups demonstrate two methods for automagically finding the edges to be filleted.
squircle_2021Sep29a.gh (37.8 KB)
Great job Joseph - thanks. My GH file is pretty messy right now, so I’m going to try to clean it up by perhaps making some clusters. I’ll see if I can fit your code in there because every time I change something I have to re-jigger the edge list by hand. That’s rather tedious to say the least. Here’s a current image:
Right, who needs that. I revised one of the filter operations (yellow group) to use two less Cull components by adding an And component. So now it requires two criteria to be True:
- Edge length must be the same as your original ‘squircle’ curve AND
- Edge MidPt ‘Z’ value must be the same as your base extrusion value (12).
squircle_2021Sep29b.gh (38.9 KB)
Yup, you did it again. (Smacks forehead, “Now why didn’t I think of that?”) Since I wanted to allow each of the 3 vertical shapes to be different (orange image) I made a cluster out of your yellow group and put it in my file 3 times. But of course this was only after thinking (incorrectly) that “Hey, I don’t need the Z test because each object is a Z-only extrusion.” I got stuck in that delusion for a while, but finally came to my senses this morning. I did discover some interesting things however.
When changing the size of the 3 fillets, if they get to the point of overlapping themselves the Brep remains closed, exports to an STL file ok, and can be sliced OK for printing.
But if the fillets get so large they overlap the base fillet, then the Brep changes to open, the STL file contains 133,069 errors, and the slicer won’t touch it without repairing all the errors.
I have more tweaking to do because as it is now the part is a bit too big for my printer, but this should be a fairly simple fix. Thanks again for your help with this.
That doesn’t sound like “The Grasshopper Way” to me because you’d have to copy the cluster to add shapes (extruded “squircles”). So I dug into it and had to modify your ‘squircle’ cluster to work properly with multiple radii. (flatten is bad!)
I made a few more changes to handle the shapes as branches in a data tree, such as using Entwine for the Z values (height) and Move vectors. I also noticed that you had “disentangled” the two ‘squircle’ clusters, which defeats some of their benefit (changes to one cluster affects all “entangled” copies). So I copied my modified cluster for the base.
Ultimately, the change to my yellow group fillet edge filter was minimal, consisting of flattening the Cull output to get a single list of edge indexes for FilEdge.
squircle_2021Sep30a.gh (50.3 KB)
WOW! I think my head just exploded since I have never tried using Entwine before. I sort of get the idea of what it’s doing, but I’m going to have to do some experimenting and Googeling to really understand what it does. Thanks for showing what it can do.
I have been able to fit your methods into my GH file, so although it is a total mess right now it does give a good result. I’ll work on cleaning it up tomorrow. It will be a lot smaller of course. I did change the squircles from polygons to rectangles because I wanted better control over their shapes. Doing that meant I had to introduce new sliders for the rectangle X & Y values - which was not a big deal. I also now have 3D vectors with X & Y sliders to move all the verticals around.
I’ll post file GH file when I get it cleaned up and with a nice set of verticals. Your methods make it much easier to tweak the parameters so I can get what looks like a nice result that will slice ok and fit on my printer.
Really Birk? That means you don’t understand data trees at all, which is really surprising given how long you have been active on this forum. Understanding differences between Merge and Entwine is extremely basic to understanding GH data trees at all.
By the way, I forgot to mention two things:
-
The ‘squircle’ cluster produces an “Invalid Line” with the same point being used for both ends. It was in your original code and I didn’t fix that.
-
Inside that cluster, you had a Remove end cluster which I replaced with Shift List.
Actually I do understand data trees, but just have never had a need to use them to any significant extent. The most complicated things I’ve printed have been those with multiple holes or “stick-ons” that have all been the same shape. This is really the first time I’ve had to deal with multiple objects having different shapes.
While cleaning up my GH file I discovered that the squircle routine performs quite differently with polygons compared to rectangles. I thought using rectangles would give me the ability to vary length & width, which it does, but the resulting squircle is far different (and far less nice) compared to how it looks using a 4 sided polygon. So in addition to just cleaning up my GH file I’m going to go back to polygons, and this, in turn, will probably change my overall final design.
Here is what I now plan on printing:
I modified the squircle cluster (again) so it behaved better with rectangle input rather than polygon. This enabled me to maximize the size of the vertical columns. I think my mods make the result not a true squircle shape, but the results are OK for this part.
It also occurred to me that filleting the inside edges would make the part nicer, and I was able to do both inside and outside fillets with just a combination of EdgesCVX, Dispatch, Cull i, and FilletEdge.
The inside and outside fillets require different radius values and it quickly became clear that there should be a better way than trial & error to determine the largest workable radius numbers. So I may do another one of these if I can come up with a better approach.
squircle2.gh (53.9 KB)
