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.
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.
Great, glad to hear I improved someone’s workflow.
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.
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.
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.
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.
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.
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.
FWIW, MESHmachine’s Offset Cut also works with the old/FAST booleans (by default) and predates the new EXACT solver.
I agree that polygonal modelling tools aren’t getting a lot of attention in any major 3d apps, and haven’t for years. Despite there being a lot of room for advancements.
Thanks for this. These are important tips to getting Exact Boolean to work every time.
The issue with the very large scale example is likely this: when you snapped the two faces together, the coordinates for the two resulting coplanar faces ended up not exactly the same. You probably can’t even see that in the interface because the floating point values used for coordinates in blender only have 6 to 7 decimal digits of precision.
For Exact Boolean to detect coplanar faces properly, the coordinates have to be truly exactly the same. If you manually, or with a script, set the coordinates so that they all have (say) exactly the same x value, then it should work, even at large scales. Also, this has to be done without an object transformation on either object, because applying that transformation (which has to be done in order to do a Boolean between two separate objects) will likely cause the coordinates to not exactly match again, at that large scale.
And wouldn’t it be possible to have a tolerance? Or would that defeat the whole purpose of “exact”?
It would be possible to have a tolerance, but not straightforward. One way to do it would be to find points that are almost at the same place, and snap one to the other. But what if a number of points are all close to each other? Do I create a cascading sequence of merges?
I meant a threshold for co-planarity, but… maybe it’s the same?
There’s a pretty recent and interesting video that I found where someone manages to achieve a Non-Destructive Bevel after Boolean of round surfaces. It seems this involves an ungodly amount of modifiers, as well as a bit of duplication of the boolean objects. Unfortunately, the author of the video doesn’t explain anything, rather is just indicating stuff on the screen.
I was wondering if this type of functionality could be plausible as an additional option in a modifier (not sure which one)…