Delete Geometry vs Separate Geometry

[Wannes]

Summary

I have made a patch to convert the Delete Geometry node to work with fields (D12491). When working on this I came up with the idea of replacing this node with another called “Separate Geometry”. I wanted some feedback on which node would be preferred. Below I placed a small description of what each node would do.

Delete Geometry

Has a selection field as input, as well as a drop-down to select the domain (point, edge, face, face corner, spline). The node then deletes the geometry in the selection on that domain.

Separate Geometry

The same as Delete Geometry but has two outputs. For one of the outputs the selection is inverted. This is a more general version of the Point Separate node.

Reasons to choose one over the other

These are some that I could think of, but feel free to add your own reasons why

• The Delete Geometry node is simpler, and more to the point. It is clear what the output will be when you use it.
• The Separate Geometry node is more versatile, and can still do the exact same things as the Delete Geometry node. But because of its two outputs it can be difficult to tell which output will have which “half”. This was also a problem with the point separate node.
• If there are very few use-cases of actually needing both outputs of the Separate Geometry node, it just fills up more space then necessary and creates visual noise.
• It is not very difficult to recreate the Separate Geometry node using the Delete Geometry node, so there is no “real” extra functionality. The Separate Geometry node just makes it more compact.

• Delete Geometry
• Separate Geometry

[Eary]

I guess this is what it looks like?

[LeonardSiebeneicher]

Delete functionality might be done that way, but discoverability also matters.

Someone who looks for a node which deletes geometry won’t discover the functionality he looks for.

[Joze]

I voted delete geometry as that is what you would search for /look for quickly. However Is it such a bad idea to just have both? Some things in shader nodes there is often two ways to do the same sort of thing.

[Bobo_The_Imp]

They perform two completely different operations and I’m not sure why people are conflating the two as if only one can exist. I strongly feel both are needed.

Consider in the 3D viewport if there was only delete, and no separate selection, wouldn’t that be odd? The context in geometry nodes is different, but when using a separate geometry node it’s usually because that specific part of the mesh will undergo many operations that the “rest of the mesh” simply won’t, and is often re-joined to the base mesh later. Separating it allows you to perform whatever you need on that piece without using a “selection” on every node, it also allows you to extract parts of a mesh that in many circumstances need to be separate after being created procedurally, such as different moving parts in a rigid body simulation etc.

The list can go on, but a separate geometry node is both for ease of use and for necessities in specific scenarios.

[RiccardoBancone]

I voted for Delete, but I agree that they should both exist for discoverability and better UX.
I’m all for minimal number of nodes, but In some cases like this, having only one of the two, makes the use of one node to serve the purpose of the other feel like a hack .

Eg. Using separate node to delete piece of geometry, just not using one of the two outputs feels odd. Same if you use delete to split the geometry from delete node’s output and the previous node’s output.

If just one is kept, I foresee beginners posting the same “how do I delete geometry” or “how do I split geometry” over and over on stack exchange and forums.

[Wannes]

Yes, pretty much that.

[GeorgiaPacific]

I also think that having both of the options would be best.

[LazyDodo]

Deleting / Splitting / Separate all seem specializations of a filter in one way or another, perhaps having a single filter node would work discoverability wise?

pardon my mspaint skills here

guess you the second inverse output could stay? (but didn’t want to redo the image)

[Bobo_The_Imp]

I should have mentioned in my previous post there are performance considerations as well. Delete geometry is a more efficient use of resources compared to separate. Separate has to “remember” the mesh and slows things down a bit, whereas delete doesn’t cause as much of a slow down. In small scale setups it’s not a big deal but often in larger ones the difference in performance can be palpable. This is another reason to include two separate nodes.

[LudvikKoutny]

I don’t think this is a good idea. There will be many more nodes with selection input mask. So either it would be inconsistent, or they all would have to get a redundant “invert” checkbox. Such checkbox should not exist, as we should have basic set of boolean math nodes that include “not” operation.

And as already mentioned above, creative mental gymnastics harm the discoverability. When someone will want to delete geometry in GN, they will try to search for “delete” node. If deleting is done using the “Filter” node, then that will be just one additional item in the bag of “all the weird Blender things”.

[RiccardoBancone]

Agree, I would add that the delete node is a pretty obvious and straightforward one to search for IMHO. Whoever will want to delete geometry will probably search for “delete”. Having the delete function under a more general purpose node with another name (like “filter” or others) Is way less discoverable I fear.

[Wannes]

If you were to only use one of the outputs of the separate geometry node, the performance should be identical as the underlying code is identical (nothing is computed for the other output).

[Bobo_The_Imp]

Just another thought, do we know if in the future the delete geometry node might have a drop down with more deletion options such as “only faces” etc? If so that might be a good reason to have both delete and separate, as I don’t feel a dropdown like that would serve the same purpose on separate.

[Wannes]

That is a good idea, I’ll try and see if I can get that working. I’ll add that to the newer patch if I can figure it out, which also has both the delete and separate node.

[Eary]

@Wannes I just saw the comment on the patch about making the delete node delete nothing by default, and you said delete everything is equal to not using it at all, well, I would argue that this is not true.

This is a screenshot taken from the prototype branch, as you can see, even when the mesh (default cube) from group input node is deleted, the vertex group actually stays, and it enables the GN generated mesh to have vertex group. That’s how I usually do it. If you just not use the node, it will end up like this:

So set it to default true is definitely different from not using the node at all

I generally agree with your previous reasoning of adding the delete node should just delete things. Think of it this way, why would anyone add a delete node but don’t want to delete anything? But delete everything is actually a use case. I believe the node should just delete everything by default, and this behavior also feels more intuitive.