I’m coming over to Rhino from Turbo CAD Mac. There are lots of reasons, but the main one being the size of the Rhino community and the programming interfaces available.
Currently, I’m struggling with a simple extrusion and boolean subtraction operation. Attached is a file that has a simple cylinder, a helix path, and a polyline profile. In TurboCAD, it’s about a 10 second operation to select the profile, extrude along a path, and then subtract from the cylinder and have a properly shaped thread.
I cannot figure out how to do this in Rhino. After the extrusion, the part looks odd - it looks more like a shell than a solid (I did select Output: Solid). After several seconds of the spinning beachball, I get the "Boolean difference failed.” message.
Both the exported step file and the 3dm files are attached. I’m sure I’m missing something simple here.
Rhino doesn’t call what you want to do an ‘extrusion’ along a path, it’s a Sweep 1 Rail, so you “extruded” a weird inside-out object. Using Sweep1 to make the threads cutter worked here.
The shape generated by Sweep1 looks more correct with the “Roadway” option. The “Freeform” option looks wrong for this operation. Even with that, I’m getting “Boolean difference failed.”
Here’s what my steps are -
Sweep1
select the helix as the rail
select the cutter profile as the “Sweep Shapes”
“Done” in Sweep1 / Select Shapes
“Done” in Sweep1 (at Drag seam point to adjust)
“Roadlike” in Sweep1 Rail Options
“Sweep” in Sweep 1 Rail Options
This results in an open poly surface. Then using “CAP’“ do close it.
Finally, using boolean difference-
Select surfaces or poly surfaces to subtract from
pick the cylinder
Select surfaces or polysurfaces to subtract with
select the swept cutter polysurface (now closed)
Then “Boolean difference failed.”
Is there a specific setting on one of these steps I need to change?
The issue isn’t the geometry but the mathematical representation of the geometry. Unlike a physical cutter that will plough through material without concern about the accuracy of its profile or positioning, the representation of that process is the intersections between surfaces.
To carry out your boolean difference Rhino has to consider every surface involved and establish where it intersects other surfaces and then trim away the unwanted parts. The representation of the surfaces may involve approximation. Where an intersection comes close to the edge of a surface it is possible that it will be incomplete. By considering each surface of your cutter separately:
So, while there is nothing wrong with the geometry from a pure perspective, it has limitations when reduced to surface representations. It just isn’t the best geometry for your purpose.
I guess the modelling mantra should be “No representation without limitation”: in time you’ll find plenty more scenarios where limitations interfere with your intent. But you’ll come to recognise where they are likely and work around them. That’s not to be blase about them: do lobby McNeel to address particular special cases like helical thread intersections.
I saw a comment in one of the Rhino help/manual pages, I don’t remember where. It went something like “Rhino is a surface modeler, not a solid modeler”. I didn’t really think much about it at the time, but it seems pretty relevant now. I have gotten used to working in solids where this doesn’t seem to be an issue - even opencascade in c++ does this operation pretty easily (although coding up the details is a mess).
Maybe I just need to come to terms with what Rhino is or is not. I’d say my biggest source of confusing was not knowing if it was a problem with my geometry, with they way I was trying to use Rhino, using the wrong commands in Rhino, or something else.
It would be interesting to see what kind of tolerances it’s working to. I have had situations where it was easier messing with the unit tolerance in Rhino to ham-fist a boolean through, but it’s not exactly best practice.
I was thinking it worked fundamentally different based on solid geometry instead of surface detection. I really have no idea how the internal algos work.
I can easily post the resulting .step files from:
Rhino with the fixed cutter geometry
opencascade c++ equivalent (actual algo was borrowed from FreeCAD)
Turbo CAD’s extrude-path command.
If there is any way to compare the results. Or if it’s even a rabbit hole worth going down.
David asked about the tolerance that was used when doing the operation. In Rhino, you can easily check the document tolerance in the document properties. Is there such setting in Turbo CAD?
At any rate, that one application does something will never automatically mean that Rhino will do the same. As the original developers of much of the code in Rhino have been retiring in the past couple of years, new developers have taken over the responsibility for parts of the code. The intersection code is one of these parts. While that definitely leads to changes in the code - and resulting geometry - this continues to be a slow evolution of the robustness of intersections rather than a revolution.
-wim
You will compare apples with oranges. There are some CAD apps which will handle these edge cases better, but it will still be a bad thing to do. Without a light-weight and obvious cutter geometry, you likely worsen the quality of your target geometry. Just because Solid modellers might not expose you to surface properties, they can still be exceptionally bad after such operation. Unless its a polygonal modelling software, shapes are represented in parametric equations (usually Nurbs) and it will always be a problem if you force them into difficult computations.
Yeah more or less this. If the priority is just getting the command to complete, My slightly naive assumption is that it would be relatively easy to get a line of best fit from the partial intersections and approximate a result, at the cost of precision. The fact that rhino will only give you a result when it’s able to be accurate is a good thing.
There is really no difference in the way solid modelers work and the way Rhino does. Both use BREPs
The problem here is you went to extra trouble this to produce an unreliable and less accurate result. Rhino has always had problems computing the intersection curves that are needed to define a boundary representation when the intersedtion lands near an existing boundary. . Rhino8 in particular has problems with making useful intersection curves. Rhino 6 and 7 don’t have this problem and they will make the single complete intersection needed.
Regardless of what program you use you will get a better result if the surfaces fully intersect. Making surfaces that don’t quite reach each other in places is always going to be less optimal than constructing surfaces that do.
I suggest you learn to do this using the Trim command. Construct only the surfaces you need for the result you want and make sure they intersect fully and then all you have to do is click on the parts you know will be deleted and then join the parts that are left. Trim_command.3dm (2.7 MB)
The second method shown in this video from the Rhino Help is what I’m talking about
Thanks for all of the great suggestions. I do like what Rhino is able to do, but there’s a lot of new things for me to learn. I’ll admit that I don’t spend a lot of time going down into the details of the math behind it all. Most CAD apps that I’ve worked with have many ways to do, more or less the same operation - finding the right one is often the trick.
The biggest thing here is the absolute tolerance setting in the document. That’s really nice to know about. It makes a lot of sense that would be set on a per-document basis and not globally for the entire application.
It would have been helpful to see an error or warning message steering me toward that setting; but if you know, you know. I can live with that.
To spin it another way though - if the operation can’t be done at the requested tolerance, the next immediate question is - “what tolerance can you hold?” Then I’d be able to make the judgement call as to whether it’s “good enough”, or “back to the drawing board”.
Ultimately, this particular part is going to be 3D printed - which doesn’t require particularly tight tolerances. The document setting was 0.001mm; which is much tighter than necessary.
I do an internal and external screw thread modeling exercise with our apprentices and we always make sure that swept cutter profile extends a little outside the surface to be cut.
In the case of 3DP parts, the file tolerance isn’t as much of an issue as the export settings are - as well as what your printer and it’s slicer are actually doing. I recently printed a bolt/nut as a result of the exercise and I was surprised to feel some facetting when I threaded the nut onto the bolt. I checked the STL meshing and it was way fine, I concluded that the slicer software was reinterpreting the polygons somewhat coarser when outputting to the printer. I had to put a bit more clearance than I expected on the threads in the nut part to get it to run nicely on the bolt.
