Delete Geometry node face mode behaves unexpectedly when used after Join Geometry #99664

New Issue

Zhen Dai · 2022-07-13T11:53:32+02:00

Zhen Dai commented

2022-07-13 11:53:32 +02:00

System Information
Operating system: Windows-10-10.0.18363-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.68

Blender Version
Broken: version: 3.2.1, branch: master, commit date: 2022-07-05 15:44, hash: a2d59b2dac
Worked: N/A (problem exists on 3.1.2)

Short description of error

Not sure if this is by design, but I find that the following behaviour unexpected:

By itself, a Mesh Line output connected to Delete Geometry + Geometry Proximity node using Face mode won't delete anything.
However, when such a Mesh Line is joined with a Grid primitive, then Delete Geometry + Geometry Proximity in Face mode will cause all of Mesh Line to be deleted, regardless of distances.

Exact steps for others to reproduce the error

Download the blend and observe Mesh Line is preserved.
Unmute Grid node link to Join Geometry, and observe Mesh Line is now gone.

line-deletion.blend

**System Information** Operating system: Windows-10-10.0.18363-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.68 **Blender Version** Broken: version: 3.2.1, branch: master, commit date: 2022-07-05 15:44, hash: `a2d59b2dac` Worked: N/A (problem exists on 3.1.2) **Short description of error** Not sure if this is by design, but I find that the following behaviour unexpected: - By itself, a Mesh Line output connected to Delete Geometry + Geometry Proximity node using Face mode won't delete anything. - However, when such a Mesh Line is joined with a Grid primitive, then Delete Geometry + Geometry Proximity in Face mode will cause all of Mesh Line to be deleted, regardless of distances. ![Screenshot 2022-07-13 175154.jpg](https://archive.blender.org/developer/F13290102/Screenshot_2022-07-13_175154.jpg) ![Screenshot 2022-07-13 175147.jpg](https://archive.blender.org/developer/F13290101/Screenshot_2022-07-13_175147.jpg) ![Screenshot 2022-07-13 175140.jpg](https://archive.blender.org/developer/F13290100/Screenshot_2022-07-13_175140.jpg) **Exact steps for others to reproduce the error** - Download the blend and observe Mesh Line is preserved. - Unmute Grid node link to Join Geometry, and observe Mesh Line is now gone. [line-deletion.blend](https://archive.blender.org/developer/F13290110/line-deletion.blend)

Zhen Dai commented

2022-07-13 11:53:32 +02:00

Added subscriber: @Zhen-Dai

blender-admin commented

2022-07-13 11:53:32 +02:00

#102190 was marked as duplicate of this issue

Jacques Lucke commented

2022-07-13 12:08:39 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2022-07-13 12:08:39 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Jacques Lucke commented

2022-07-13 12:08:39 +02:00

When I open the file it looks different from you screenshot. Can you also maybe simplify it a little bit more. It doesn't seem necessary to deal with materials or to have a Geometry Proximity node in there.

When I open the file it looks different from you screenshot. Can you also maybe simplify it a little bit more. It doesn't seem necessary to deal with materials or to have a Geometry Proximity node in there. ![image.png](https://archive.blender.org/developer/F13290115/image.png)

Zhen Dai commented

2022-07-13 12:20:30 +02:00

@JacquesLucke sorry for the trouble, I was trying to make the deletion quad stands out, i hope this version is more clear. (and my result for reference.)

line-deletion-new.blend

@JacquesLucke sorry for the trouble, I was trying to make the deletion quad stands out, i hope this version is more clear. (and my result for reference.) [line-deletion-new.blend](https://archive.blender.org/developer/F13290128/line-deletion-new.blend) ![Screenshot 2022-07-13 181859.jpg](https://archive.blender.org/developer/F13290130/Screenshot_2022-07-13_181859.jpg) ![Screenshot 2022-07-13 181912.jpg](https://archive.blender.org/developer/F13290129/Screenshot_2022-07-13_181912.jpg)

Wannes Malfait commented

2022-07-13 12:21:32 +02:00

Added subscriber: @wannes.malfait

Wannes Malfait commented

2022-07-13 12:21:32 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Wannes Malfait commented

2022-07-13 12:21:32 +02:00

I think this is a bug, but it will require some big changes to the delete geometry node to fix.

I think the problem is the following:

When "separating" geometry, the node only keeps those elements which are in the selection. This works perfectly fine.
When "deleting" geometry, the node does a separation on the inverse of the selection. This fails in the example above, because the points on the line are not on any faces, and will therefore get deleted regardless of the selection.

So what needs to change is that, when the domain is faces or edges, the points/edges which are "loose", i.e. not on an element of the domain, should be kept regardless of the selection when deleting. This is because the selection doesn't say anything about these elements.

For the separate geometry node, this would mean that the Inverted output also contains these "extra" elements.

I think this is a bug, but it will require some big changes to the delete geometry node to fix. I think the problem is the following: - When "separating" geometry, the node only keeps those elements which are in the selection. This works perfectly fine. - When "deleting" geometry, the node does a separation on the inverse of the selection. This fails in the example above, because the points on the line are not on any faces, and will therefore get deleted regardless of the selection. So what needs to change is that, when the domain is faces or edges, the points/edges which are "loose", i.e. not on an element of the domain, should be kept regardless of the selection when deleting. This is because the selection doesn't say anything about these elements. For the separate geometry node, this would mean that the `Inverted` output also contains these "extra" elements.

Jacques Lucke commented

2022-07-13 12:42:24 +02:00

Hm seems reasonable. It feels like it would be better to split up Separation and Deletion a bit more then, and maybe just share some common functions.
It feels wrong to output these extra elements in the Separate node.

I'm a bit more concerned right now that the file looks different in 3.3 compared to 3.2, probably an unrelated bug though.
delete_geometry_deletes_too_much.blend

Hm seems reasonable. It feels like it would be better to split up Separation and Deletion a bit more then, and maybe just share some common functions. It feels wrong to output these extra elements in the Separate node. I'm a bit more concerned right now that the file looks different in 3.3 compared to 3.2, probably an unrelated bug though. [delete_geometry_deletes_too_much.blend](https://archive.blender.org/developer/F13290145/delete_geometry_deletes_too_much.blend)

Wannes Malfait commented

2022-07-13 12:56:00 +02:00

In #99664#1389633, @JacquesLucke wrote:
Hm seems reasonable. It feels like it would be better to split up Separation and Deletion a bit more then, and maybe just share some common functions.
It feels wrong to output these extra elements in the Separate node.

I think it makes sense to add them, since this way, when you join the two outputs, you get back the original geometry (except maybe at the boundary). Otherwise, part of the geometry just disappears for seemingly no reason.

I'm a bit more concerned right now that the file looks different in 3.3 compared to 3.2, probably an unrelated bug though.
delete_geometry_deletes_too_much.blend

I feel like that might be caused by this: {c4e11122c537}. I think this adds different behaviour when the selection is empty for example, but not entirely sure.

> In #99664#1389633, @JacquesLucke wrote: > Hm seems reasonable. It feels like it would be better to split up Separation and Deletion a bit more then, and maybe just share some common functions. > It feels wrong to output these extra elements in the Separate node. I think it makes sense to add them, since this way, when you join the two outputs, you get back the original geometry (except maybe at the boundary). Otherwise, part of the geometry just disappears for seemingly no reason. > I'm a bit more concerned right now that the file looks different in 3.3 compared to 3.2, probably an unrelated bug though. > [delete_geometry_deletes_too_much.blend](https://archive.blender.org/developer/F13290145/delete_geometry_deletes_too_much.blend) I feel like that might be caused by this: {c4e11122c537}. I think this adds different behaviour when the selection is empty for example, but not entirely sure.

Jacques Lucke commented

2022-07-13 13:02:21 +02:00

I think it makes sense to add them, since this way, when you join the two outputs, you get back the original geometry (except maybe at the boundary). Otherwise, part of the geometry just disappears for seemingly no reason.

Hm not so sure about that. If I separate faces I kind of expect to only get faces. Also I'm still thinking about the generalization of the node where it has a id input instead of a selection can can split the mesh into more than two parts. Then it would be very non obvious where the extra elements should go. If anything, those should be put into a separate output. But it might be better to just have separate nodes to get loose points and loose edges instead.
As you mention, you don't get the original geometry back anyway, so that's not an important requirement to me.

I think this adds different behaviour when the selection is empty for example, but not entirely sure.

I'm bisecting this now.

> I think it makes sense to add them, since this way, when you join the two outputs, you get back the original geometry (except maybe at the boundary). Otherwise, part of the geometry just disappears for seemingly no reason. Hm not so sure about that. If I separate faces I kind of expect to only get faces. Also I'm still thinking about the generalization of the node where it has a id input instead of a selection can can split the mesh into more than two parts. Then it would be very non obvious where the extra elements should go. If anything, those should be put into a separate output. But it might be better to just have separate nodes to get loose points and loose edges instead. As you mention, you don't get the original geometry back anyway, so that's not an important requirement to me. > I think this adds different behaviour when the selection is empty for example, but not entirely sure. I'm bisecting this now.

Jacques Lucke commented

2022-07-13 13:14:02 +02:00

You're right, it's caused by c4e11122c5. Will check if that can be fixed, otherwise I'll revert the change.

You're right, it's caused by c4e11122c5. Will check if that can be fixed, otherwise I'll revert the change.

Jacques Lucke commented

2022-07-26 12:06:37 +02:00

We could probably also rename the Inverted output of the Separate Geometry node to Rest or so. Then it would be more obvious that it can also contain e.g. loose points when the domain is set to Face. We should still keep node setups which depend on the current Inverted output working though. That probably means that we'd have to add another Separate Geometry node in versioning with an inverted selection input. Alternatively, we could also have three outputs in the node.

We could probably also rename the `Inverted` output of the `Separate Geometry` node to `Rest` or so. Then it would be more obvious that it can also contain e.g. loose points when the domain is set to Face. We should still keep node setups which depend on the current `Inverted` output working though. That probably means that we'd have to add another `Separate Geometry` node in versioning with an inverted selection input. Alternatively, we could also have three outputs in the node.

Iliya Katushenock commented

2022-11-08 20:59:35 +01:00

Added subscribers: @PaulGeraskin, @Vyach, @mod_moder, @HooglyBoogly

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Delete Geometry node face mode behaves unexpectedly when used after Join Geometry #99664