I know that many of the addon writers here build on top of the builtin Boolean. It might be time to start testing this new boolean to see if it breaks your code, and let me know in this thread if so. I have started putting builds of my branch on the experimental buildbot site: https://builder.blender.org/download/newboolean/ .
Here’s an example of where the new boolean does better than the existing one - cases where there is exact coincidence between geometry of the two sides of the boolean. The old boolean leaves a hole; the new one does not.
Other cases that work in the new one involve coplanar intersections.
One thing that I have not yet implemented: the ability to use non-closed-volume objects as operands. So no “plane cutter” yet. I do intend to add that. (It is not something the cited paper handles, so needs more development).
Hi Howardt,
This is awsome, thank you for the hard work !
Looks like union fails to merge objects when not touching - empty geometry ?
Using nested union + difference, disabling any union operand in “AutoBoolean” object does work, but fails when both are enabled.
Thanks Stephen. I only recently added the code that handles disjoint meshes (a surprisingly hard case for the algorithm in the paper!), and seem to have a bug here. I will fix it.
History is being made here!!
For so long that Blender has that wooden leg that I thought it will never evolve.
Thank you so much for all of the hard work and the passion at taking that challenge up to the end!
Mr Howard, you rock!!
Yeah. Reading the paper, it seems like this will be a very robust method , which sounds awesome! Most of it is way over my head , but I’m super happy you were able to accomplish this.
Hey @howardt,
That will be one of the most needed improvements for me.
I just tried it with an existing (quite complex) model, and it crashes Blender. The only output I get in console is: zsh: floating point exception (core dumped).
There are new builds up at the buildbot link. They fix Stephen’s bug and another regarding reversed normals.
@cdog and @blndrusr - I need .blend files if you want me to look at the problems, preferably as simple as possible. That said, I already have several examples of crashing .blend’s that I am working on fixing, so you might also want to wait until I have fixed my known crashing problems and then try again.
I’m excited for the possibilities of what this could offer. We have long preached to avoid “hotlining” or placing a bool directly on top of an edge precisely. It cant download quick enough.
I tried that - I added a cube, duplicated it, scaled the second by .5 in z, moved it up .5 and 1 in y. Then put a boolean modifier on the first cube subtracting the second. It worked for me. If you can upload a .blend, I can look to see what is different.
I should caution that when I say “coplanar”, I mean exactly coplanar. There is no snapping to planes if they are within some epsilon tolerance. That said, the boolean should still work if things are not exactly coplanar – there just will be some very skinny triangles in the result. So I don’t think that’s what is going on here. Did you check the “Exact” box in the modifier? It is the default in my builds, but if you made this model in another Blender, it will be off by default.
admittedly plane on plane violence was my first test with it.
theres a workflow where a mesh is used as a difference but can be shifted into a slice or intersect / inset / outset. The solidification portion of modifier evaluation seems to be hit heavily. The smaller window is current 29 and the bigger is the branch.
this is the best thing i have seen since mirror got bisect.
I see changes happening to like 20 different systems off the top of my head. So amazing.
One more thing. So I have been working on an idea to make booleans handle bevels dynamically. And well, youve done it.
Im not joking when I say I had plans that depended on this solve. I see so many possibilities already!
