Boolean Modifier - Difference (Subtract) Operation Broken #71524

New Issue

Adam Janz · 2019-11-12T19:13:13+01:00

Adam Janz commented

2019-11-12 19:13:13 +01:00

System Information
Operating system: Windows-8.1-6.3.9600 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 417.22

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-12 13:28, hash: 1252577580
Worked: (optional)

Short description of error
When using a boolean modifier on a plane mesh with the "Difference" operator, the operation will incorrectly show as if "Union" was selected, unless the cutout mesh is EITHER:

A. Flush on one edge with the plane; OR
B. Partially outside the plane.

Please see attached image and attached .blend file for a clear example.

Thank you so much.

Exact steps for others to reproduce the error
.blend file attached

Boolean Error.blend

**System Information** Operating system: Windows-8.1-6.3.9600 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 417.22 **Blender Version** Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-12 13:28, hash: `1252577580` Worked: (optional) **Short description of error** When using a boolean modifier on a plane mesh with the "Difference" operator, the operation will incorrectly show as if "Union" was selected, unless the cutout mesh is EITHER: A. Flush on one edge with the plane; OR B. Partially outside the plane. Please see attached image and attached .blend file for a clear example. Thank you so much. ![Boolean Bug Blender 2.81.16.PNG](https://archive.blender.org/developer/F8051056/Boolean_Bug_Blender_2.81.16.PNG) **Exact steps for others to reproduce the error** .blend file attached [Boolean Error.blend](https://archive.blender.org/developer/F8051061/Boolean_Error.blend)

Adam Janz commented

2019-11-12 19:13:13 +01:00

Added subscriber: @AdamJanz

Adam Janz commented

2019-11-12 19:38:13 +01:00

I can confirm this bug affects every version of 2.8, including the official release. I tested every build I had on hand all the way back to Blender 2.8 Hash: 388ff003e2 (v 2.80.48), and they all behave the same. The only version of Blender where this bug does not exist is 2.79.6.

I can confirm this bug affects every version of 2.8, including the official release. I tested every build I had on hand all the way back to Blender 2.8 Hash: 388ff003e28b (v 2.80.48), and they all behave the same. The only version of Blender where this bug does not exist is 2.79.6.

Adam Janz commented

2019-11-12 19:55:50 +01:00

Adding a solidify modifier at the top of the stack and un-checking "only rim" appears to cause the boolean operation to behave as normal. This could be a temporary workaround, but reveals that the Boolean Difference operation CANNOT presently work on objects without thickness (ie. a 2D plane).

Stanislav Blinov commented

2019-11-13 09:18:46 +01:00

Added subscriber: @Stan_Pancakes

Stanislav Blinov commented

2019-11-13 09:18:46 +01:00

Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

Philipp Oeser commented

2019-11-13 14:33:05 +01:00

Added subscribers: @howardt, @lichtwerk

Philipp Oeser commented

2019-11-13 14:33:05 +01:00

Actually, I think the upper example you marked in red (not working), is the one I would judge "working" -- and the other ones failing...

Yes booleans are on the list of things to rewrite.
There is a long list of stuff that fails, see #47030 (BMesh booleans (track todo's))

Pretty sure this is a duplicate [will assume it is #61845, but it could be others of the list as well...]

I could add to the list an example where object transform will make it fail [apply rotation in the following file to see a difference]
untitled.blend

Lets hope for the work of @howardt to release us from the pain soonish :)

Actually, I think the upper example you marked in red (not working), is the one I would judge "working" -- and the other ones failing... Yes booleans are on the list of things to rewrite. There is a long list of stuff that fails, see #47030 (BMesh booleans (track todo's)) Pretty sure this is a duplicate [will assume it is #61845, but it could be others of the list as well...] I could add to the list an example where object transform will make it fail [apply rotation in the following file to see a difference] [untitled.blend](https://archive.blender.org/developer/F8060273/untitled.blend) Lets hope for the work of @howardt to release us from the pain soonish :)

Philipp Oeser commented

2019-11-13 14:33:31 +01:00

Closed as duplicate of #61845

Philipp Oeser closed this issue

2019-11-13 14:33:31 +01:00

Adam Janz commented

2019-11-13 17:22:31 +01:00

Thanks Philipp. Well, since the difference operation is supposed to be "subtract" (ie. cutting a hole), the 1st example which "combines" the geometry together is incorrect, while the other two examples work as expected. But as mentioned, this error only occurs when the object being acted upon has no thickness. So yes, it is definitely a strange bug and I hope the super-smart Blender devs will discover the root cause of this... :-) And wow, I didn't even know about that bug when applying rotation. That makes absolutely no sense. You'll notice that it switches to the same incorrect "combine" mode after the geometry is applied, so no doubt the two bugs are somehow related...

Adam Janz commented

2019-11-13 17:32:35 +01:00

In #71524#810103, @Stan_Pancakes wrote:
Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

Thanks Stanislav. I will look forward to that fix... :-)

> In #71524#810103, @Stan_Pancakes wrote: > Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long. Thanks Stanislav. I will look forward to that fix... :-)

Howard Trickey commented

2019-11-13 19:07:42 +01:00

Boolean operations are intended to be interpreted as if they are operating on 3d volumes. So, e.g., difference A-B (for objects A and B) means everything inside the volume of A, but excluding any point that is also in volume B. The currently implemented BMesh Boolean code assumes that the two objects are closed volumes -- that is, there are faces all around that are tightly sealed together and you can clearly figure out what is inside and what is outside the volume implied by those faces connected faces.

The example here doesn't have that property, so technically this is not a bug. The code tests inside vs outside by shooting a ray in an arbitrary direction and counting how many faces of the other object it encounters. This is guaranteed to work in the watertight-closed-faces situation I just described, but not otherwise. But it might accidentally work sometimes, which is why you are finding situations where it seems to work and others where it doesn't.

The old Carve solver handled some non-closed-face cases, though I don't know in detail for which cases it was guaranteed to work. I believe it worked when one object was a plane and the other object was a closed object, for instance.

The code I am writing right now (it is getting very close to working -- works on a number of cases already) is using another method to test inside vs outside: something called the "generalized winding number". This is more expensive to calculate (so I may have to make it optional, and use faster ray shooting if the user wants), but it allows non-closed objects to be roughly considered as having insides and outsides. I think it might handle the case in your example, but am not sure yet.

Boolean operations are intended to be interpreted as if they are operating on 3d volumes. So, e.g., difference A-B (for objects A and B) means everything inside the volume of A, but excluding any point that is also in volume B. The currently implemented BMesh Boolean code assumes that the two objects are closed volumes -- that is, there are faces all around that are tightly sealed together and you can clearly figure out what is inside and what is outside the volume implied by those faces connected faces. The example here doesn't have that property, so technically this is not a bug. The code tests inside vs outside by shooting a ray in an arbitrary direction and counting how many faces of the other object it encounters. This is guaranteed to work in the watertight-closed-faces situation I just described, but not otherwise. But it might accidentally work sometimes, which is why you are finding situations where it seems to work and others where it doesn't. The old Carve solver handled some non-closed-face cases, though I don't know in detail for which cases it was guaranteed to work. I believe it worked when one object was a plane and the other object was a closed object, for instance. The code I am writing right now (it is getting very close to working -- works on a number of cases already) is using another method to test inside vs outside: something called the "generalized winding number". This is more expensive to calculate (so I may have to make it optional, and use faster ray shooting if the user wants), but it allows non-closed objects to be roughly considered as having insides and outsides. I think it might handle the case in your example, but am not sure yet.

Adam Janz commented

2019-11-13 21:44:21 +01:00

@howardt Thanks so much, Howard, for that detailed explanation and clarification! I look forward to seeing the advanced solutions you are creating.

For me, I'd like to be able to achieve a cut like #1 (top) in my example BUT one that behaves like #3 (bottom) (ie. have a Boolean modifier cut a hole in a 2D plane, but then ALSO be able to Solidify that plane ONLY along its rim and the rim of any cut holes using the Solidify modifier [at the bottom of the modifier stack with "Fill Rim" and "Only Rim" selected]. This way the plane is only "thick" at the cut and does not have backfaces anywhere else, thus saving on wasted geometry for later import into a game engine).

Thank you again for all your hard work!

Adam

@howardt Thanks so much, Howard, for that detailed explanation and clarification! I look forward to seeing the advanced solutions you are creating. For me, I'd like to be able to achieve a cut like #1 (top) in my example BUT one that behaves like #3 (bottom) (ie. have a Boolean modifier cut a hole in a 2D plane, but then ALSO be able to Solidify that plane ONLY along its rim and the rim of any cut holes using the Solidify modifier [at the bottom of the modifier stack with "Fill Rim" and "Only Rim" selected]. This way the plane is only "thick" at the cut and does not have backfaces anywhere else, thus saving on wasted geometry for later import into a game engine). Thank you again for all your hard work! - Adam

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Boolean Modifier - Difference (Subtract) Operation Broken #71524