Thanks for the continued efforts and updates Howard! We always appreciate it!
2 Likes
What happened with boolean modifier in 2.90?
2.83
2.90
6 Likes
I noticed that as well. You’ll get the 2.83 behavior if there’s a modifier on the cutter, though.
I made another progress update to the Boolean Design task. I wrote there:
Now the code to remove triangulation edges after doing the boolean is done. Also, coplanar intersections work. I also did a fairly big refactor to reduce copying of vertex and face data, and to prepare for using floating-point filtering of exact arithmetic predicates (to improve performance). Also did the very first step of performance improvement: using bounding boxes and BVH trees to greatly reduce the number of triangle-triangle intersections tried. The performance is still very far from what I want it to be (currently about 100 times slower than the BMesh boolean on test that intersects two 8k face spheres; and 10 times slower on two 250 face spheres). But I still have a lot of things to do that I know will improve performance.
In terms of functionality, still to do: using original mesh attributes on created new ones (though plumbing is there to make this easy now); hooking up the boolean modifier to this code; doing proper post-operator selection; handling the proper final cutting in the Boolean Knife intersect mode; some handling of non-manifold inputs.
29 Likes
On the plus side, the boolean union of two 8k uv spheres with the current BMesh Boolean actually gives the wrong answer (one half of the union is missing). Whereas my new code works.
10 Likes
Great news that there is progress!
Can we test it now or if it’ s better to wait to upcoming changes?
Currently about 100 times slower than the BMesh boolean on test that intersects two 8k face spheres; and 10 times slower on two 250 face spheres
do you believe you’re gonna make this to current bmesh in terms of performance with those things that you already have vision?
It is not unreasonable to try testing, at least a little, now. Remember that you need to use the Boolean tool, not the modifier - though I’ll fix that very soon.
I probably won’t reach the current BMesh performance, in all generality, at least singled threaded. There is just no getting around the fact that some intersections and intersection tests have to be done in multiprecision, with my new approach (upside: correct results; downside: it takes longer). But I would like to get it to be reasonably competitive in the sense that: where BMesh boolean feels “instantaneous”, the new one will either also feel that way or at least feel not annoyingly too long.
Two tricks I have in mind are not actually implemented in the current BMesh boolean, so there may be circumstances in which the new one would outperform the old one, if these tricks are not backported. These are: (1) parallel execution of the mesh intersection code (current BMesh boolean does parallel execution of the “finding possible overlaps” code, but not the intersection code itself); and (2) using some simple tests to exclude and “summarize the topology of” huge sections of the input meshes that can easily be detected to not possibly be involved in intersection.
And there is a third thing: my current code does not use BMesh at all - except in the final stage, to apply the result. The current Boolean modifier uses BMesh, so the Boolean Modifier has to convert from Mesh to BMesh, do the boolean, and then convert back to Mesh. While I will do that first, as it is easy, I also have open the option of skipping the conversion to and from BMesh and just operating directly from the Mesh data.
I think when I first release this, I think it will be with a flag that will let users choose between the old and new Boolean. Then for cases where that one works, you can use it for speed; and switch to the new one when it doesn’t work. But maintaining (i.e., bug fixing) two versions in the long term is not very appealing, so there may be at some future point, the appetite to have only one. A lot will depend on where I get to with the final performance, I think.
23 Likes
I’m happy to report that my latest rounds of speedups now have the new code only 5 times slower than the current BMesh Boolean code on the two-8k-sphere test (down from 100 times slower, four days ago). And, as mentioned before, it gives the correct result where the current BMesh Boolean does not. So good progress. I still have more ideas to try.
Currently, the new code always does self-intersect of both sides of the boolean, as well as the intersect with each other. I don’t know if this is a good idea. I will likely make it not do this, at least optionally. It would be faster if I did not do this.
Also, it has the capability of boolean’ing n objects at once, not just two, at no extra performance cost. But I haven’t yet made a UI that would take advantage of that. What this means is that if you have, say, built a character out of lots of pieces of separate mesh that interpenetrate each other (body, arms, legs, etc.), you can get a nice shell with interior stuff eaten away by doing an n-way boolean. Of course it would likely need retopo after that if you wanted to animate it.
40 Likes
probably just a bug- did you report it?
1 Like
I now have some builds of the newboolean branch available at https://builder.blender.org/download/newboolean/ .
The code is now reasonably complete (but no non-closed-volume operands handled yet). It also runs reasonably fast, though still not as fast as I eventually hope to get to.
Here’s a picture of where the new code does better than the old code: when geometry coincides exactly,
(Maybe a bit hard to see, but the old boolean leaves a hole; the new boolean fills it.)
23 Likes
Thanks Howard! I just did a quick test. Unfortunately I cant reproduce your feature, I might be overlooking something though.
.blend : newB.txt (136.6 KB) (rename to .blend)
@rbx775 - It seems that the new boolean is working as expected on the mesh in your newB example – change the Viewport display to Material Preview or Rendered to see this.
There is some property on Cube.001 that is causing the “see-through” effect in Solid viewport display mode, but I can’t discover what it is – do you know? That property is getting transferred to the newly cut faces of the boolean, which is why the result of the boolean also has that see-through effect.
1 Like
Thank you very much Howard. The option that causes this is called “Backface culling”.
If turned off, you can see the faces:
That would mean, that the new faces are created with the normals pointing in the opposite directions.
thats also what the “face orientation” viewport overlay says:
5 Likes
Thanks rbx775. OK, I have a bug in the normal directions for the Difference case (hmm, that used to work). I will fix it.
11 Likes
Fantastic! Im already playing around with it, works like a charm otherwise.
Thank you so much for your hard work Howard!
2 Likes
Why the mesh that has boolean modifiers goes back to normal when I try to edit it. Can we overcome this limitation?
Instead of going back to normal we can have a wireframe added to it that can be manipulated and the result of the boolean in shaded mode.
There is another software that does that but i’m not allow to say the name or post any screenshots, but just to let people know that it can be done. 
1 Like
So you are asking for a BooleanModifier.show_in_editmode and BooleanModifier.show_on_cage property?
like those of the mirror modifier.
I think it isnt there for performance reasons. Otherwise I definately would love to have it! 
3 Likes
Looking back at the very roots of this thread, in the first post there’s a screenshot that i’m copy pasting down here:
Now, that’s not a good result imho, since there is way too much new topology that can mess up geometry, that is not even affected by the intersection. Why should I want those futile edge loops?
But now look at this:
What if each ‘new vertex’ just gets connected to the nearest (pre-existing) supporting edge?
I think this result looks a lot like better topology than nightmarish triangle fans or two single often bad positioned edges.
You might argue that they are new vertices on untouched (not intersected) edges.
Yes they are. New vertices are expected anyway in a boolean operation, so why not? And anyway these new vertices/edges can be thought as new geometry for the whole face affected by the boolean operation, and therefore, needed added geometry.
1 Like
Interesting. The intermediate product of boolean is a triangulation of the face that is generally cleaned up by dissolving edges that were not original edges until removing another edge would make an invalid BMesh face. You are proposing a different kind of cleanup from that state that inserts extra vertices so as to avoid extreme angles of the supporting edges.
You realize of course that on the top and side faces there are hidden triangle fans now? That is, when the ngon is converted to triangles for rendering, there will be lots of triangle fans on those faces. But maybe it is nicer for a modeler to have those remain hidden. Also, I know that things like bevel would work better with your topology.
3 Likes