About a week ago I saw a screenshot of something someone was 3D printing. It had an interesting pattern on the outside and I decided to see if I could replicate it on a simple vase shape. This is the vase geometry:
It’s pretty clear that the problem happens when the Splop result is processed by SDiff.
To fix this I tried all the combinations I could think of with Flatten, Graft, Join, and Sunion. None of them worked. I also tried converting the BReps to meshes; that also failed. I even tried using a torus, but that was no better. So I’m hoping someone can suggest a fix that will work.
I’ve attached a simplified version of my GH file that has the Splop surface and vase geometry internalized. I left all the detail for generating the pattern geometry in place, along with some panels that show when Join sometimes works and sometimes doesn’t. Here’s what the attached GH file looks like:
Note that the final SDiff is disabled - on my system it takes 10 minutes to complete processing, so don’t enable this unless you really want to try some sort of fix. fail1.gh (70.2 KB)
This is more of a general nurbs “solid” operation problem.
You are trying to merge surfaces that are reciprocally tangent in some place… almost a loophole in math calc.
The most reliable solution would be to trim your rings from top view with a square, to make a clean and decisive cut, and then simply joining surfaces together.
Anyway…
Try to make your ring with Revolution surface function instead of Pipe function (much simpler surface > easier solid operations).
Rotate your circle/ring by 45 degree, so that the seam point doesn’t is inside the solid union calculation.
Adjust the construction of the ring so the double-seam point (U and V) is outside of the solid operation.
Another solution, probably the fastest and simplest:
if the diameter of your rings is 10mm (for example), move them by 10.1mm, so the intersection is more obvious and there are no co-tangent parts.
You can join pipes like in image (blue and red group) than move one group a little bit in z direction and use union again.
Create solid difference in xy plane and transform the result
Ricccardo: I tried all of your suggestions except for the one about trimming the ring array with the square. I got the following results: (1) switching from a piped circle to a surface of revolution did not seem to make any difference. (2) Moving the seam did make a difference, but not a helpful one: I tried various values between 0 and 1; most of them had no effect, but some of them crashed the SUnion function. Of course I have no idea why this happened. (3) Rotating the ring behaved similarly to #2; I reckon this is because it does basically the same thing. (4) Separating the rings by a tiny amount did allow the SUnion functions to work better in some cases, with the result that the final SDiff generated different results. But none of them were correct - there were always missing and discontinuous cutouts on the vase geometry.
Seghier: for some reason your GH file does not work properly on my system. Specifically, the SUnion objects in the middle that you disabled fail when I enabled them. I tried to work around this, but nothing I tried worked. Basically I was unable to get any of the disabled components downstream of these SUnions to work.
I did look at the script you made and must say I don’t understand how it works. You have used a number of GH objects I am unfamiliar with (I’m a self-taught GH user), but even so I was able to duplicate the basic results you got with your 2 separate ring arrays.
So I thought I had the solution when I read your statement “move one group a little bit in z direction and use union again.” I thought "Aha! All I have to do is separate the rings into 2 separate arrays (like you did) and then do 2 separate SDiffs. I was happy when the first SDiff looked good, but the second one resulted in the same type of broken pattern I showed in my first post. Again I have no idea why this happened. I will spend more time with your script and see if I can figure out how you were able to get the nice result that is eluding me.
I’m thinking now that both the SUnion and SDiff components have some internal quirks that result in “unpredictable results” when they are given certain types of input. Fortunately I am just a 3D printing hobbyist, so there’s no real consequence for not being able to resolve problems like this. Nevertheless I’ve not given up - yet.
By even further simplifying it, we can see that you just need this portion of the pipe:
(which is the result of a small, simple, single solid boolean intersection… with no tangent edges… etc…)
So, with some array:
This is all perfectly joined but the external perimeter… which are naked edges…
This script make only the “module” for the interior of your pattern, just do the modules with “1 free side” and you’re done. fail1_re3.gh (19.1 KB)
Note: all the torus surfaces have the seam toward Z+ … when you’ll do solid difference with your vase, make so the geometry fall with seams not inside the vase solid.
(If you are able to “trim out” the seams, any further operations, like filletting, will be so much easier for you and rhino)
With a little tweak your solution worked Riccardo. What a clever way to go about it. Many thanks,
What I did was internalize your result into a Geo object and then paste that into the file I’m working on. Then I just used it as input to Splop and fed that output to SDiff. It failed. But when I looked at the results of the SPlop I saw that there were holes aloone each of the edges. So I just ran a Cap function on the Geo to close everything up. That made the results I showed above. So now i just have to generate enough of the pattern to cover the vase.
Your idea of using just a portion of the ring would never have occurred to me. But it clearly resolves whatever the problems are with SDiff and SUnion. It is somewhat disturbing to me that my original approach doesn’t work. I agree it is a far simpler approach than any of the ones suggested here, but it does seem to me that it should work. Of course I’m not the one who is writing the code that makes things work, so I can say that.
Thanks again to all who helped me with this. Hopefully I’ll soon have a finished print to show here.
boolean operations also sometimes work better in rhino and not grasshopper, meaning u can bake ur rings, bake ur vase, and do the boolean difference operation in rhino. Its annoying because you cant keep your design fully parametric but is also a workaround. Grasshopper and RHino have two different boolean algorithms. Sometimes a boolean in Rhino doesnt work, but it does in work in GH, and vice versa.
It’s like piking a fork (or a rake), which usually have equal-length teeth, and touching a flat surface with its teeth:
Are all the teeth touching at the same time? Or just 2? Or 1?
In a non-pure math context even a good algorithm would go crazy.
It’s simpler to polish the teeth with a flat abrasive surface, and so you are sure they all touch at the same time.
(how much dumb was this example ? )
Reciprocally tangent surfaces are always a problem for solid operations.
From my experience, also in other programs, even parametric ones.
This is a screeshot of the patterned vase in my slicer program. It loaded as a manifold file which means it is a true solid with no gaps or weirdnesses. The slicer sliced it OK and predicts a print time of about 10 hours. I’ll find out just how good that prediction is tomorrow.
Interestingly enough, when I got the number of rows & columns tweaked to properly fit the vase, the final SDiff did not work! It appeared to do nothing, even though it ran for more than a minute. So I added the BBox and subsequent SDiff from Seghier’s solution and that worked OK. So I just SPloped that around the vase surface, added a bottom, and Voila!
From this it’s apparent that SDiff works differently (or not at all) on curved surfaces compared to flat/planar ones. I guess this is not surprising. But it is a bit disappointing.
)
