New Boolean

P.S. I will note that the idea of reconsidering (1) in the previous post isn’t so obvious: what if one operand had a planar face-like thing with a coplanar grid in it. Should that grid go away when we get the Boolean result? Does the answer differ depending on whether or not that plane is involved in an intersection with the other object? I think users would probably be surprised to have the grid go away in either case, but that’s what would happen if I implemented reconsidering (1) as stated.


ProBooleans in 3dsmax has an option where you can choose to remove edges or not.
Could be a good solution depeding on user scenario?


Decimate modifier in planar mode should handle edge removal, so a solution exists - and provide some options like preserve material indexes and so on.
At some point boolean must be kept as “simple” and fast as possible, without code / functionality duplication of other modifiers.

True. Sometimes new options are the only way to solve problems, but Ton has always advised developers to try to figure out ways in which they are unnecessary, because they complicate the UI and understanding of how to use the program (not to mention the added maintenance burden). Ask ourselves: is there a way the program could automagically figure out what option a user would have chosen and just do that.

In the current case, I’m wondering about a rule like this: if any of the operands has a group of coplanar faces touching each other, then assume the user cares about internal edges in faces. Otherwise, assume they user doesn’t care (and doesn’t want) them. Do in the former case, use the current behavior of Boolean; in the latter, dissolve all edges that are internal to a coplanar face. What do people think about this? Some nuance to figure out would be whether to make this determination looking at every face of each operand, or just those involved in a particular face-set/facet-set intersection.

1 Like

Unless a lack of options degrades and hinders a tool’s usefulness. Sometimes assumptions about how a tool is going to be used are not sufficient and fine grained control should be exposed.

Sorry for the tangential plug, but it’s still a major issue for me, and prevents me from further building on what you have done.


Noted. I’ll see what I can do for you on that request. Honestly, I’d hoped to be much further along by now on my plans to greatly improve bevel this year, but keep getting distracted by bugs/performance improvements on Boolean (and, more lately, Constrained Delaunay Triangulation, used for curve filling in Geometry nodes). And I still have a promise to get the fast-object-io project over the finish line into master.


How is this related to amount of options?

I don’t see a reason why fixing this would only be possible by adding additional UI knobs. It’s actually quite frustrating to think that bevel tool should have some extra UI option which should only be tweaked to fix specific corner case. Such options should never exist. They don’t concern making art. They are just a manual lever for user to pull to fix the bug themselves.

1 Like

It doesn’t have to be an option in the UI necessarily(the comment in the task states as much) but it should be adjusted/removed/exposed to Python. There’s a hardcoded limit of 14 degrees that changes the way the loop slide works vs. the previous versions that causes it not to work as well with no trade off for the loss of functionality. The user having to move their mouse farther isn’t really something that should be optimized for in this particular situation imo.


I don’t mean to rush you, please take your time and work on what you want to work on primarily.


There is a hard coded, non-exposed angle threshold that prevents bevel loop sliding to work in a significant amount of cases. This means its unusable in those cases, with no alternative work around, that doesn’t involve manual vert moving.
The angle threshold should either be exposed, or not be present at all. Ideally it would just work without such a threshold of course, but there must be a reason for it, and exposing it may be easier than developing an approach where the threshold is redundant.

1 Like

The reason for it was that without that threshold you can get ugly spikes that overlap far into other faces or out into space. You can say: OK, I’ll just turn off edge slide if that happens, or redo my geometry. But there may be other selected edges that can be loop slided, so it is good to be able to have the whole bevel do something on most edges but not on the ones that would cause spikes.

Maybe I was too quick to “fix” the spikes problem. Maybe that wasn’t as important as the downsides that you find for your use cases. Of course now we are in a bit of a “don’t break legacy models” problem: if I just removed that limit altogether, some existing models with bevel modifiers would all of a sudden grow spikes.

All I can say is, I prepare the pre-bevel geo exactly as I need it, and all I need then is for all edges to properly loop slide. Currently some don’t and so it’s as unusable as the spikes you tried to avoid with the threshold.

But anyway, happy to email/dm if you need more feedback.

I have a question about Boolean that I’d like the opinion of from users.

With New Boolean, the algorithm that decides whether you are inside or outside of a shape uses the normals to make that decision: you are outside if you are on the side that the normals point to (and it is assumed that the normals are consistently oriented).

With Fast Boolean, the algorithm is ray shooting: from a point that you want to test for insideness, just shoot a ray (in the positive x-direction only) and count how many faces it hits. If it is odd, then the point is inside; if is even, then outside.

One way in which the Exact Boolean way can be better is if you want to cut out holes in the volume of space: you can reverse the normals of an object that is inside another object. Then if you slice through both with another boolean, you’ll see the hole in space.

I’m looking at some bug reports that happen when one or both objects in a Boolean has a negative transformation applied to it. Which of the above methods is used to say whether something is inside or out has some effect on how to resolve these bugs.

What are user’s expectations around this? Should I always just reverse face directions if a negative transformation is applied to all arguments and continue to use the normal direction method for insideness testing?

1 Like

Normals are for sure “mathematically correct” way for doing this, but in practice normals can get “off” really fast. From my expirience - there is a lot of cases where judging stuff on normals can became unreliable from user-expectations point of view, all-of-sudden. i`m making some custom operators for myself and also used to use normals for orienting stuff (from python) and after many cases of frustration just give up on using normals where possible // You just can not be sure that mesh with proper normals will have proper normals after several editing steps applied. For example armature/deformation modifiers or creating/moving mesh stuff from python. Or importing models from other sources. It is always (frequently) leads to manual fixing normals for every small crease on the mesh which is a pain.

So… while tricks with inverting are nice, but they IMHO rarely usefull in practice. you have to be 100% sure for every face on mesh to be 100% right under any kind of deformation (that you need in scene) and this is not feasible in reality. Raycasting is way more predictable/intuitive

1 Like

@MACHIN3 I just committed a change that lowers the limiting angle from 0.25 to 0.0001 (radians, about .006 degrees). I think you are unlikely to run into this limit but let me know if you do.


Will test tomorrow, thank you so much!

This fixes the first example blend, nice job!
The second blend with the bevel mod still has issues when used with percent bevels. 100% bevels will go further than they should in some places. Happens with the mod, but also on the mesh level, and it wasn’t really happening before 2.91.

Also, is there any chance to get these fixes into 2.93.2 or will they only be available in 3.0?

Thanks again, I truly appreciate what you do!