I wanted to use SDIFF to subtract the cutter shapes from the vase shape, but that did not work. The first SDIFF worked fine, but the second one did nothing. The only way I could get the final geometry was to bake the 3 sets of geometry into Rhino and then use the Rhino command Solid/Boolean Split. This was quite tedious because I had to manually select each cutter rib (there are 64 of them) individually to add to the group of objects with which to split the original vase geometry. So I’m wondering if there is a better or alternative way to do this.
All of the geometry is comprised of closed Breps. Here are things I tried, all of which failed:
SDIFF each set of cutters individually
Brep Join the 2 sets of cutters and SDIFF those
Repeat above using the Fast SDiff cluster I found here a few weeks ago
Mesh everything and MDIFF the cutters
Export vase and cutters to Rhino and use Rhino’s Solid Difference
Export vase and cutters to Rhino and use Rhino’s Boolean Two Objects command
Sort of - the vase is 2 capped closed BReps of revolution, with a smaller one inside a bigger one and SDIFFed from it to make a vase with interior space and solid walls. To this I joined 3 conical feet with fiIleted edges. I did try SDIFF with just the capped outer shape (no feet), which is about as simple as it gets. The produced all the same failures.
The cutters have to be subtracted from the vase because, due to the curvature of the bottom portion of the vase, anything extruded out from the surface results in overhanging geometry that can only be printed in a zero G environment. And I do not have access to something like that.
You could use the innermost surfaces of your strips as attractors to create a mesh approximation of this shape. Would take forever to process pulling all the mesh points to the surfaces but it could get close.
That’s an interesting idea for sure - thanks. Meshes have always seemed like some sort of black magic to me, so I have very little experience with them. I’m hoping there is a solution somewhere that sticks with Nurbs geometry.
Maybe something like this? The splitting is done on a surface in the xy plane using the Lunchbox Diamond Pattern and then trimmed on both sides so the diamonds align when it’s extruded and wrapped around the vase shape using Sporph. Because there’s still a seam when it’s wrapped, it results in an open brep, but since you’re going to be printing it anyway, and you need a mesh, if you weld it, there are no naked edges but some non-manifold ones. I imagine your printing software has some way of handling these…
Oh my! That is quite a fancy method for adding ribs to the outside of a vase shape. I have never tried using any of the Lunchbox tools, even though I have that software installed. I did find all the components in your purple group for handling seams quite interesting (and confusing actually) - I’ll have to take some time and try to understand what’s going on in there.
I think the reason Sporph results in an open BRep is the fact that your vase geometry is a simple single surface of revolution - it has no thickness. It’s easy to fix that however. I think what I’ll do is do that and then see if there is a way to subtract the paneling ribs from that.
Without the purple group, wrapping the extruded shape around the vase form would produce no “coffers” where the two ends meet, it would just be solid diamond shapes running down the seam. Clipping off the ends leaves a half-diamond on each side so when they meet, a full, indented diamond is formed.
in your first image it looks like the diamonds are indents but then it looks like your cutters will leave diamonds sticking out?
Anenome could be used to create a loop so you take away one cutter from the vase then use the result to feed back into the loop for the next cutter and so on.
This is really slow mind… Set the boolean toggle to TRUE before changing any parameters and be aware that I’ve just used basic geometry… I know it doesn’t work for all combinations of parameters
I have never used Anemone but I see what the objective is - namely to use SDIFF one cutter at a time in a loop that does them all. I can see how a separately coded add-on would be needed to provide the looping function - what I don’t see is why it’s necessary to do that.
Of course the reason for that is I have no idea what the internal code for SDIFF looks like (and frankly I don’t want to know); it’s just surprising to me that the SDIFF code works differently when handling a bunch of cutters VS one at a time. I’m also surprised that this problem seems to be unique to me; I’ve got to believe that people who use GH for a living have encountered many cases like this. Perhaps that is why Anemone was developed.
Yeah using Anenome shouldn’t be necessary, is just another way.
I think its common to have problems with SDiff, SUnion, TrimSolid and all the Boolean operations because you need to be precise with everything from tolerances to valid Breps and avoiding the results yielding thin slivers, being aware of seams etc etc etc. Over the years I’ve seen people criticise Rhino for its Boolean operations for both meshes and surfaces / solids. They are frustrating but you know what they say about Booleans… it’s a game of give and take
As a mere 3D printing hobbyist quirks like this are really nothing more serious than an entertainment for me. But for people who do this as a real job the quirks must be a major issue indeed. Maybe that’s why my son, who is a MechE, migrated his development group to Catia. I’ll have to ask him if that’s got a parametric piece.
