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.
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.
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?
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)…
I know I am sounding like a disappointing broken record by now, but it has long been my intention to do a non-destructive bevel-after-boolean (as well as, and because of, a bevel that doesn’t mess up when the expanding edges hit other edges) as my next big project. Unfortunately, maintenance on stuff I’ve already committed / committed to keeps delaying this.
My hope is that eventually, something like this will be possible with Geometry Nodes too. Performance probably won’t be same as if it was a native boolean modifier option, but at least user would get a simple, single GN modifier with only few exposed relevant parameters instead of giant modifier stack with tons of setup required, which makes what’s shown on the video unfeasible for practical use
@Howard_Trickey
I was just wondering if 2D Booleans made it to the your to do list? I know they are possible with some work arounds, but was wondering if native support will be available anytime soon?
Sorry, not in the near future for me. I am currently working on the obj exporter then importer, and a bevel uv problem. Then maybe some more boolean performance improvements. Then a bevel that works beyond the point where things start to overlap. So a long todo list. But maybe some day I can get to 2d booleans.
