Its a limitation of the exact solver, it doesnt support non manifold geometry afaik
3 Likes
So, using the case above as an example, placing a solidify modifier before the boolean would give the expected result, right?
Then @Howard_Trickeycoudl implement a simple “delete” modifier to delete vertex groups and add it to solidify group output.
Can’t you do that with the mask modifier?
I was going to comment the same.
Besides this, having to open a solid object to make a cutout doesn’t make much sense. It would be easier to incorporate a cutting mode.
1 Like
Oh my. Look how beautiful it is 
Thank you @Howard_Trickey for continuing to work on this new amazing boolean code!
23 Likes
I am running into a similar problem as MrTheRich here and I also have an actual usecase for this. Though I am not too sure whether this is a new boolean question or if everything nodes is going to solve this with a version of procedural ‘bisect’.
My concrete problem is this: I am trying to replicate a similar setup to Luan Vetoreti’s learning videos (“Fundamentals of modular Kits”) for modular game assets. He bascially creates a plane template to start off, which he instances and cuts, rotates and merges into modular wall pieces t that the original plane can easily be edited and iterated on. He uses 3DS Max and a version of procedural bisect modifier to cut the pieces.
So trying to replicate this setup in Blender seems only possible with boolean operations so far:
So the problem is: Exact algorithm produces this result:
While the fast algorithm includes the connections to the cutter object:
As a game art set solidifying isn’t really an option as it would either increase the polycount without real benefit and manual editing isn’t an option as it would be a destructive process. Plus - remaining on the grid is paramount for snapping. Solidify is a rather fast way to stray from precise bounding box values.
Especially once the geometry nodes become more mature over the next iterations this could be a super powerful addition for modular game asset creation. Though it would probably really need to work on thin meshes as especially modular pieces need to:
a) remain procedural/non-destructive as long as possible as changes might need to propagate over many pieces
b) need to be aware of polycount as they may be used many times in a scene.
This wouldn’t only go for shortening walls but also for cutting panels, windows, holes etc. in geometry.
Did you try the Blender currently in the nightly builds of master? I changed the algorithm that Exact Boolean uses a couple of weeks ago in cases where both objects are not volume-enclosing. I am hoping it will give the desired results more often, especially if you are doing a difference with a cutter that is a closed volume.
14 Likes
Oooh. No, I didn’t. Thanks - will give it a try immediately. 
(edit) 
Wow. Seems to work smoothly. You rock! Thank you.
(edit2) and I just realized that it can even work with a single poly plane as a infinite/slice plane, now!!!
That is even cooler! Thanks a LOT.
6 Likes
Great, glad to hear I improved someone’s workflow.
24 Likes
It seems overhangs on open meshes are still a tough problem to solve, though.
I mean - this isn’t a thing that entirely keeps me from working or anything.
I just realized it when I edited the prototype and suddenly had some artifacts in there that weren’t there before.
Sorry!. The problem is that Boolean is still try to treat this as a volume operation, which means that it may have contributions from both operands in the result. Now it is clear what parts of the planar thing are inside and outside the cutter box, but it is not clear what parts of the cutter box are “inside” and “outside” the planar thing (when regarded as a volume).
I think I eventually will add more modes to Boolean (more than just Union, Difference, Intersection). A mode that would help use cases like this would be a “Trim inside” mode, where the second operand still has to be closed (like your box) but the result of the operation would be defined as “only those parts of the first operand that are not inside the cutter”. There would also be a “Trim outside” mode. Other modes people have asked for would be ones like the “Knife Boolean” modes in the edit boolean tool – doing the face intersections but then doing different things with how those edges separate or do not separate the various pieces involved.
17 Likes
Ah I see, all good.
Thank you very much for the in depth explanation.
A procedural slice tool would of course also be great in this case, especially with geometry nodes.
Yet for now, just means that there has to be another way to work around this. 
2 Likes
Hi,
i noticed there were performance improvements coming for the exact solver. Is this already in the 2.93 build? Im currently working in 2.92 and the results are insanely accurate, but some little speedups would be greatly appreciated.
1 Like
There is a performance improvement in the 2.93 build that, for the boolean exact modifier, avoids a step of converting to and from the internal BMesh format. It provides a modest improvement (25% speedup) on some large meshes. I’m not finished performance tuning, but it will be a while before you see any more because I’m working on something else right now.
15 Likes
Nice to hear, thanks for your response.
I hope we will see soon destructive bevel, because analogs already exist and they appeared a very long time ago, but one has limitations (Bevel after boolean addon), and the other is paid (MESHmachine). Due to the fact that modeling in blender is almost not developing, at the moment the blender resembles a Free to play game - pay for not to s@ck.
https://www.youtube.com/watch?v=GKQIv29oow8
that’s not really a fair thing to say considering BAB and MESHmachine are both utilizing the new exact boolean system described in this thread. Is there more that can be done? sure, always. Is your statement emotional hyperbole? absolutely.
7 Likes
1 - BAB work on 2.79 without exact boolean system.
2 - it’s not about Is there more that can be done? and what the blender has in fact and how the modeling problems are solved, more precisely - why they are not solved, especially against the background of large investments. Why is it done by users, and not done professional developers who are paid big money?
The team does not cope - hire freelancers, but better buy out them ready-made projects at all, why waste time and reinvent the wheel.
3 - Ye emotional… over the past 8 years boiled. Because professionals don’t care, they just use the whole range of CG software. And simple users do not understand what is happening at all, and they have no money for other software, therefore, have to whine and drip on the brain those who take part in the development of modeling.
I still had to remember frozen Texture Paint mode, but even I scored, even though Modeling, Texturing is the fundamental basis of computer graphics and should always be in development, always! But instead, users get indifference and disregard.
For a project like Blender, the current funding is insufficient. I have seen much worse products built with 10 times the money that blender has. This is how software development works. As product complexity increases, adding new features or update existing ones takes much more time.
5 Likes