3
$\begingroup$

I'm amazed there's not this asked yet.

So, how to delete overlapping vertices?

Related: Geometry Nodes: How to select the result of Merge by Distance node?

$\endgroup$
2
  • $\begingroup$ Careful with tweaking the questions... :) The title says how to delete, and yes, in the original question there already was the "better yet..." part, but I figured it's an XY problem, where you think you can implement your own solution X to the problem Y, as soon as you're helped with the first step of X that you're struggling with. And I answered the actual problem Y as stated in the title. Though in my case modifying the answer is trivial too, so we still can redact the question to just mean the selection if you want. $\endgroup$ Commented Jul 3 at 8:19
  • $\begingroup$ @Gorgious Thanks! Done and done. And I'll make the RightClickSelect post about this also now. $\endgroup$ Commented Jul 3 at 17:36

2 Answers 2

5
$\begingroup$

You don't need to merge overlapping vertices to delete them, just check if the nearest other point is too close:

To get a selection instead, simply replace "Delete Geometry" node with a "Capture Attribute: Boolean" node...

Warning:

  • This won't simulate Merge by Distance in Connected mode!
  • There is a discrepancy between "Index of Nearest" and "Merge By Distance", because the latter works sequentially:

  • There's some discussion in the comments about connections, but I don't see the point as deleting vertices will inevitably remove edges and faces relying on those vertices.
$\endgroup$
6
  • 1
    $\begingroup$ I like the solution, but i think you won't get the same result as in merge by distance, because delete geometry does not built new connections for the double points as merge by distance does. So after that you might have "loose points". $\endgroup$
    – Chris
    Commented Jul 3 at 4:24
  • $\begingroup$ I agree with @Chris here, while merging by distance keeps the mesh connected, deleting them will destroy the mesh. But after reading the question again, "how can I delete both vertices" sounds exactly like destroying the mesh would be acceptable and then merging would indeed not be necessary... I'm just not sure if this is really desired when reading the last sentence of the question. $\endgroup$ Commented Jul 3 at 4:36
  • $\begingroup$ @Chris can you provide an example? $\endgroup$ Commented Jul 3 at 7:03
  • $\begingroup$ yes, just create two cubes with a distance of .1 as one mesh. With merge by distance .2 you get 12 vertices, with your solution you will get 4 vertices (because you delete all "merged" vertices) but merge by distance merges(keeps 1 vertex) at that distance $\endgroup$
    – Chris
    Commented Jul 3 at 7:10
  • $\begingroup$ but as Gordon wrote: Manu seemed to wanted to delete all and not to merge - because he wrote explicitely: So, how can I delete both vertices that have the exact same position? -> but i don't know whether he knows - but that's not that what merge by distance does. So tbh the question is a bit unclear ;) $\endgroup$
    – Chris
    Commented Jul 3 at 7:13
1
$\begingroup$

Pro algorithm

This one takes care of nuances like "Connected" mode (no such mode for "2nd nearest" node), subtleties related to float precision (what if 1 m merging merges a vertex on $<0, 0, 0>$ with a vertex on $<1.00001, 0, 0>$ but the "2nd nearest" correctly doesn't?) and the sequential behavior of merging:

In other words: this one should give you exact, true information on what was merged, regardless of circumstances. and this is because it really merges, but maintains bridges (portals) to old geometry to sample information from it.

Basically, make a copy, extrude vertices from original to copy, merge extrusion with the copy to create portals between the original and the copy, then merge the original and count the portals:

However, when merging the bottom in the above GIF, the verts could also merge horizontally... So a repeat zone is needed to only merge one pair at a time.

Those vertical edges above I call portals. They're the bridges between the universe where geometry was merged, and the universe where it wasn't. At first the relation is 1:1, but after merging, each vertex from merged universe, if not merged with anything, still has 1:1 connection with its copy, but if merged with something, it can use its portals to go to all vertices that in its universe merged, but in the other didn't. And vice-versa, each vertex from non-merged universe can use its portal to visit the one vertex that is exactly the same vertex in the other universe, or an amalgamate of it and some other vertices.

A vertex looking at the amalgamate of self and neighbors in the alternate universe: (though there's a chance on the other side of the portal there will be a guy not merged with anything, so it will look like a mirror):

✨Generated with Bing copilot AI ∙ July 3, 2024 at 7:08 PM - please don't look at the left arm.

Many vertices merged into one (F... Monster) looking through multiple portals at "ordinary" men (the vertices the F... Monster was created from):

✨Generated with Bing copilot AI ∙ July 3, 2024 at 8:47 PM - please don't look too closely at those "ordinary" faces.

At the end of the GIF I marked the amalgamates as "F", and you can see multiple portals going from them to their original vertices:

Also, the displacement while extruding is just for visualization, but if you just extrude by 0, then you don't have to worry about the merge distance (and that's why it's hidden in my node tree) and only select the 2 vertices to merge. This creates additional overlapping geometry, so it's important to keep track of what geometry is what, to know which parts to merge and which to delete later.

After this process, if I move the "Temp Copy" down, I can preview the connections:

But again, that's only for the visualization.

The last step is to count the edges, some of which are portals, remove the temporary geometry, and count the edges again - the difference between the two is the number of portals, meaning the number of original vertices per merged vertex.

Let's reiterate:

Save the original indices, create a copy, mark the copy, extrude by 0, start a Repeat Zone iterating over each original vertex:

For each original vertex, select the copy of that vertex (that's why capturing indices was needed) but only the copy not the original (hence Subtract). Keep in mind the extruded vertex also counts as a copy, and also has the anonymous field with the captured index. This way you can merge the "Temp Copy" with the extruded copy:

Merge the original geometry, count edges for each vertex, delete the "Temp Copy", count the edges again. The difference is the number of edges you just removed, and so the edges leading to the removed geometry - the portals. Each portal leads to to exactly one vertex, so that's the number of original vertices - that's it! Keep in mind you could merge the "Temp Copy" instead, if you only want to predict how many points would be merged, rather than actually merging them. Also, you can do a lot more things then just counting the original vertices, you can read their positions and other attributes using "topology" nodes.

Below is an example of how to display the result:

Just to be clear, it works in 3D.

Oh, and to answer the question: simply delete the points that report a value higher than 1, because it means they come from more than 1 point. In the last GIF it means only the top-most vertex on the image wouldn't be deleted.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .