bool nodes 's edge out have rubish edge #101067

New Issue

SensArice · 2022-09-14T18:24:37+02:00

SensArice commented

2022-09-14 18:24:37 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Quadro RTX 4000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.40

Blender Version
Broken: version: 3.3.0, branch: master, commit date: 2022-09-06 15:39, hash: 0759f671ce
Worked: (newest version of Blender that worked as expected)

Short description of error
[Please fill out a short description of the error here]

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

bool edge bug.blend

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: Quadro RTX 4000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.40 **Blender Version** Broken: version: 3.3.0, branch: master, commit date: 2022-09-06 15:39, hash: `0759f671ce` Worked: (newest version of Blender that worked as expected) **Short description of error** [Please fill out a short description of the error here] **Exact steps for others to reproduce the error** [Please describe the exact steps needed to reproduce the issue] [Based on the default startup or an attached .blend file (as simple as possible)] ![屏幕截图(2).png](https://archive.blender.org/developer/F13492799/屏幕截图_2_.png) [bool edge bug.blend](https://archive.blender.org/developer/F13492803/bool_edge_bug.blend)

SensArice commented

2022-09-14 18:24:37 +02:00

Added subscriber: @SensArice

Richard Antalik commented

2022-09-15 04:37:31 +02:00

Added subscribers: @HooglyBoogly, @iss

Richard Antalik commented

2022-09-15 04:37:31 +02:00

Can confirm the issue. I am not quite up to date on current boolean status. Also can't quite map node functionality to modifier to compare these directly if that is even possible.
@HooglyBoogly is node supposed to produce as clean mesh as possible, or is result like this expected?

Can confirm the issue. I am not quite up to date on current boolean status. Also can't quite map node functionality to modifier to compare these directly if that is even possible. @HooglyBoogly is node supposed to produce as clean mesh as possible, or is result like this expected?

Hans Goudey commented

2022-09-15 04:42:25 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2022-09-15 04:42:25 +02:00

I don't know about the internals of the boolean implementation, but I think we should expect that this doesn't happen, I'd call this a bug.

Philipp Oeser commented

2022-09-15 09:24:52 +02:00

Added subscribers: @howardt, @lichtwerk

Philipp Oeser commented

2022-09-15 09:24:52 +02:00

The boolean modifier requires two meshes, whereas the node seems to happily act on a single mesh (this then has the "extra" edges).
If the three cubes are separated into individual objects and then booled, it works as expected:
bool edge three meshes.blend

@howardt : was this by design (ability to act on a single mesh)? Or should we just pass on the original mesh in case only a single input is provided?

The boolean modifier requires two meshes, whereas the node seems to happily act on a single mesh (this then has the "extra" edges). If the three cubes are separated into individual objects and then booled, it works as expected: [bool edge three meshes.blend](https://archive.blender.org/developer/F13494912/bool_edge_three_meshes.blend) ![image.png](https://archive.blender.org/developer/F13494916/image.png) @howardt : was this by design (ability to act on a single mesh)? Or should we just pass on the original mesh in case only a single input is provided?

Howard Trickey commented

2022-09-15 14:53:11 +02:00

The Boolean modifier has, by design, the idea that you can have the other operand be a collection, and that collection can be empty. The effect of doing this is that the modifier will detect and resolve self-intersections, which is a useful feature that people wanted. So in the modifier, this is by design and not a bug.

I had less to do with the design of the Boolean Geometry Node. It doesn't offer the distinction between the other operand being a single object and it being a collection, as far as I can tell. But I would still think it is useful to use the Boolean Geometry Node to resolve self intersections on a single object.

Now, one could argue that leaving the "Self Intersect" box unchecked should cause the code not to do the self-intersects check -- in other words, just return the same input that it was given. I have been regarding the "Self Intersect" flag as an optimization, not a guarantee that self-intersections will not be found: if it is checked, then the code needed check overlaps between the two arguments (when there are two). When there is only one argument, the "Self Intersect" flag is not currently consulted. If we want to make "Self intersect" a guarantee that self-intersects will be ignored, then that could be done but kind of violates the idea that Boolean is going for: trying to take n meshes, each representing a volume, and coming up with a mesh that encloses the volume represented by the boolean combination of those argument volumes.

I have to ask: If one doesn't want the result-self-intersection behavior then why use the Boolean node in the first place with no other argument? It would be trivial to check the case of "self intersect not checked" and "one argument" and return immediately. Is that what people think should be done? My inclination is to close this issue as "working as intended" but willing to listen to other arguments.

The Boolean modifier has, by design, the idea that you can have the other operand be a collection, and that collection can be empty. The effect of doing this is that the modifier will detect and resolve self-intersections, which is a useful feature that people wanted. So in the modifier, this is by design and not a bug. I had less to do with the design of the Boolean Geometry Node. It doesn't offer the distinction between the other operand being a single object and it being a collection, as far as I can tell. But I would still think it is useful to use the Boolean Geometry Node to resolve self intersections on a single object. Now, one could argue that leaving the "Self Intersect" box unchecked should cause the code not to do the self-intersects check -- in other words, just return the same input that it was given. I have been regarding the "Self Intersect" flag as an optimization, not a guarantee that self-intersections will not be found: if it is checked, then the code needed check overlaps between the two arguments (when there are two). When there is only one argument, the "Self Intersect" flag is not currently consulted. If we want to make "Self intersect" a guarantee that self-intersects will be ignored, then that could be done but kind of violates the idea that Boolean is going for: trying to take n meshes, each representing a volume, and coming up with a mesh that encloses the volume represented by the boolean combination of those argument volumes. I have to ask: If one doesn't want the result-self-intersection behavior then why use the Boolean node in the first place with no other argument? It would be trivial to check the case of "self intersect not checked" and "one argument" and return immediately. Is that what people think should be done? My inclination is to close this issue as "working as intended" but willing to listen to other arguments.

Hans Goudey commented

2022-09-15 19:11:33 +02:00

I think the current behavior with self intersections is fine. Maybe it would be more intuitive if it didn't do anything here unless self intersections were turned on, but I could see how that could be inconsistent with the goal when there are multiple.

The issue in the report is the "extra" edges when there's only a single input. Maybe that's inherent with the way self intersections are calculated, or maybe it could be resolved, I'm not sure.

I think the current behavior with self intersections is fine. Maybe it would be more intuitive if it didn't do anything here unless self intersections were turned on, but I could see how that could be inconsistent with the goal when there are multiple. The issue in the report is the "extra" edges when there's only a single input. Maybe that's inherent with the way self intersections are calculated, or maybe it could be resolved, I'm not sure.

Howard Trickey commented

2022-09-15 21:19:24 +02:00

The "extra" edges are completely expected if the boolean operation is doing self intersection: those edges are the result of that self-intersection.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

bool nodes 's edge out have rubish edge #101067