Handling of duplicate/unused vertices in SimpleMesh

[mfsch]

When loading an STL file with MeshIO.jl and converting it to a SimpleMesh with the code in MeshBridge.jl, I ended up with a mesh that has duplicate vertices, only some of which are referenced in the connectivity list. While it is probably best to avoid creating such meshes, it might be worth improving the way topologies handle this case:

julia> elements = connect.([(1,2,3),(3,2,4,6)]) # 5 is unused
2-element Vector{Connectivity}:
 Triangle(1, 2, 3)
 Quadrangle(3, 2, 4, 6)

julia> vertices(SimpleTopology(elements))
1:6

julia> vertices(HalfEdgeTopology(elements))
1:5

julia> Coboundary{0,2}(HalfEdgeTopology(elements))(5)
ERROR: KeyError: key 5 not found
Stacktrace:
 [1] getindex
   @ ./dict.jl:498 [inlined]
 [2] half4vert
   @ ~/.julia/packages/Meshes/pXd16/src/topologies/halfedge.jl:189 [inlined]
 [3] (::Coboundary{0, 2, 2, HalfEdgeTopology})(vert::Int64)
   @ Meshes ~/.julia/packages/Meshes/pXd16/src/toporelations/coboundary.jl:35
 [4] top-level scope
   @ REPL[6]:1

Maybe the HalfEdgeTopology could also base vertices on the maximum value, and Coboundary could give an empty vector instead?

[juliohm]

Throughout the entire source code we assume that the vertices are numbered from 1 to N without missing integers in between. I don't think it is worth moving towards a design where we allow arbitrary enumerations of vertices. These algorithms are really hard to implement already assuming that the indices are 1:N.

I suggest that you fix your IO pipeline to make sure that all vertices are numbered consecutively without gaps.

[juliohm]

Wait a minute. You are saying that the topology itself is not doing the right thing, correct? That HalfEdgeTopology should have identified the maximum number of vertices 6 and assume that this is the number of vertices?

The issue is probably somewhere else. I think if you can share the overall goal, we can track down what needs to be fixed, if anything needs to be fixed on the Meshes.jl side.

[mfsch]

The issue arises when you construct a SimpleMesh for which the connections do not reference all indices from 1 to length(points), or similarly just construct a topology that does not reference all indices from 1 to the maximum index. You could argue that these are invalid topologies/connectivities, but since it’s relatively easy to end up with such a case, I thought it might be worth handling it in a more robust way, as the current implementation fails in unexpected ways.

What I was suggesting, is to make halfedge.jl#L225 similar to simple.jl#L50, i.e. return the maximum, and to have Coboundary return an empty list for unconnected vertices instead of raising an error.

[juliohm]

Yes, it makes total sense. Thanks for looking into it. Can you help with these two PRs? :)

[mfsch]

I’ll look into it 👍

[juliohm]

@mfsch now we have the Repair{1} transform implemented by @stla to fix the unreferenced vertices in a mesh. See #354 for further details.

I will close this issue as a particular instance that has been addressed already, but feel free to restart the discussion if you feel something is still missing.