In the Rhino 9 WIP I’ve worked to add some quality of life improvements to the boolean commands (union, intersection, and difference).
These improvements include:
Booleans will continue through failures
This means if one part of multiple in a set has a problem, the boolean will continue processing as many objects as possible instead of failing entirely.
The intersection process has been made to run in parallel
Booleans between objects with many intersecting faces should feel snappier.
Booleans have been updated to avoid non-manifold geometry
When a boolean creates non-manifold geometry the regions will be separated into distinct pieces. NonManifoldSeparation.3dm (121.6 KB)
At the same time I’ve been trying to squash as many boolean bugs as possible. The primary problem I see is some kind of intersection issue. As our intersectors improve the robustness of booleans should as well.
The old SDK functions should continue working as they currently do. My plan is to provide new SDK functions which allow you to enable the multithreading and the failure processing. As for the nonmanifold results I think that’s just the correct answer and there won’t be any option for it.
Nice I appreciate your hard work on this. I wanted to make a post about Boolean improvements in Rhino and before I could post I saw your post.
For V9…
McNeel must get real time Booleans working in the viewport.
Cutters should display as simple wireframe outlines and the user should see the effect once he turns on a boolean process. Like in other programs. He should be able to move the models around and see the effects in real time.
For designers this is a must for when things get changed or for designing free style mock ups. This old code for Booleans is primitive and stifles a designers creativity. How can McNeel developers keep heaping newer code on a debased way of working? The first thing you need to do is make boolean and hole cutting realtime interactive and enabled with good history that allows the user to make changes to the models at anytime. Other programs have great boolean modeling in real time, Rhino is primitive by comparison and apparently not improving user experience but making the code more robust, but that still means Rhino’s boolean modeling is not up to standards.
RM
A little aside, BUT, this is the one KILLER APP of Grasshopper for product designers.
Apart from the larger plugin development I do in GH, 90% of my GH scripts are some sort of automated boolean operation preview tool chain.
I’ve done an video in the past detailing this workflow:
Of course it would be nice to have some of this built into the Rhino workflow, but there are huge advantages to adding some GH scripts to an otherwise traditional modeling workflow.
I’m already aware of Gh and use it for these purposes I have many GH scripts for placing rivets, screws and cutters before that I had created vbscripts to add holes and cutouts in Rhino V2. The gh approach is a cheesy work around as it doesn’t have materials and needs to be baked for the most part at least for people still using V7 rhino. This approach doesn’t compare to real time booleans nor have the ease of use, nor provide the feedback a designer needs for fast design iteration. By the time you open a GH file and fiddle about you could already have a design iteration done in another program.
Having this native and work in realtime would be better overall for user experience,
RM
I remember old Matrix 7.5 and 9 having a Boolean Builder Tool, with a few tricks to overcome some of the dificulties Rhino has with Booleans, especailly in the jewelry area, where sometimes you could have hundreds of cutters on several intersecting polysurfaces.
More experienced modelers got around boolean limitations beign mindful when building up the model, but even then, jewelry can get messy and the objects can get heavy (flow on surface, mesh objects mixed with polysrfs, cage manipulation, scultural features, etc…).
In old Matrix, when the option “One by One” was on, you could see it go trough each difference operation, cutter by cutter, and to avoid memory limit crashes that were common in 32bit, the tool would do aClearUndo for each cut, and it would highlight the problematic cutters if some of them failed to do the cut.
There have been a lot of papers in the past few years in the area of mesh booleans (see Shaped Code). Hopefully the team has been looking at these efforts as some of them are very impressive. I actually was able to try the Shaped Code implementation, and it was extremely fast and robust.
