Attribute handling for duplicated vertices

[nmellado]

Context

When loading meshes, Radium may merge (or not) duplicated vertices. For instance, a mesh composed by two triangles shared by an edge can be represented either with

1. Duplicate vertices handling: 4 vertices: one edge is implicitely shared between the two triangles. Vertices of that edges are stored once, and referenced twice, one time by connected face.
2. NoDuplicate handling: 2x3 vertices: no connectivity information, the vertices are stored two times.

If there is no problem with the second case, the attribute management is misleading in the first case.

To handle duplicated vertices, a duplicate table of size n stores the indices of the vertices defining the mesh. When a vertex is duplicated, it appears 2 times or more in the duplicate table. Note that the number of vertices m (size of the vertex container) always satisfies m <= n, with n-m being the number of duplications.

Why is this a problem

The main problem is related to the attribute management of duplicated vertices:

• for normal vectors, we have one vector for all the occurrence of a vertex. The size of the normal container is alway m.
• for other attributes (e.g. color, texture coordinates,), we have one attribute per occurrence, so the size of the other attributes containers is n.

Impact on loops

For the sake of clarity, here is an example of two different ways to loop over the Mesh vertices.

First, I want to iterate over the original mesh vertices (assuming I don't care about the loading options), which leads to:

for (uint id : *( component->getDuplicateTableOutput())) {
   auto & v = component->getVerticesRw()[id];
   // do stuff
}

Second, If I want to skip the duplicates, I need to do:

for ( auto & v : *(component->getVerticesRw())) {
   // do stuff
}

This can be ok, however we need to provide access to the attributes whatever the loop is, and in a consistent way. This is not the case today, and only the first loop provide access to the normals of the vertex v in the loop (even if we use index-based loop in the second case).

Suggestions and fixes

• Mandatory: Normal and other attributes must be accessed in the same way, using the same consistent metaphor.
• Advanced: One may be able to chose which attribute is duplicated or not. And this should be handled by the Mesh class, by providing methods to factorize duplicated data or explicitly duplicate them. In that case robust getters need to be provided.
• Suggestions: Iterators can also do the job.

[dlyr]

I see a solution using OpenMesh : Triangle/FancyMesh are meshes for rendering (I mean with "duplicated point", a vertex is a unique combination of point, normal, uv, ...) and TopologicalMeshes are for mesh manipulation. On TopologicalMesh, every attributes (point, normal, uv ...) are stored on halfedge ... it solves the pbs.

The conversion should be quite fast, but maybe not fast enough to do it every frame. If needed we could have a map (like duplicate table) between one TriangleMesh and one TopologicalMesh, then the update will be fast.

This would be easier to achieve by aslo moving FancyMesh from Plugin to Core

[dlyr]

Is anyone use splitEdge function ? The "ASCII scheme" is wrong since OpenMesh splitEdge do not create faces ! (see doc).

[nmellado]

Currently, nobody uses the topological mesh. But when it is stabilized, yes, we would need such a thing.

Can you, either fix it, or at least add a flag, such as [[deprecated("reason")]] ?

[dlyr]

I will fix it ! but it will take some time

[nmellado]

Sure, no problem, that's great :)

[dlyr]

So my current view is :

• one Mesh (formerly TriangleMesh) that stores all the geometric information for a mesh
• one DisplayMesh (formerly Mesh) that maps a Mesh to GPU data structure, no data are stored here except some GPU buffer ids/.
• one TopologicalMesh that maps Mesh to halfedge data structure from OpenMesh with efficient conversion thru a Mesh<->TopologicalMesh wrapper

One solution to get thing controllable and extensible, is to template Mesh with a VertexData struct, with a default one handling point, normals, (tex coords?) And wrapper for DisplayMesh to send the data to the GPU (wrapper are specialized for each VertexData struct we have). One question arise : what is the purpose of VectorArray ?. do I need to use it for VertexData ?

[nmellado]

TopologicalMeshes have been introduced in PRs #305 and are now stable. Part of this issue has been solved by the new attribute management system introduced by merged PRs #345 and #359. WIP PR #350 adds attribute support for subdivision schemes.

[MathiasPaulin]

Seems that this issue is solved now.

[nmellado]

We still have a duplicate table in the Animation package. I'm keeping the issue open to track this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[hoshiryu]

Re-opening since we still have the "duplicate table" for the computation of the mesh normals in the Geometric Skinning pipeline.

[dlyr]

I'm working on wedge to handle vertices attributes instead of storing them on halfedges. One question is do we need to handle attributes add/remove on TopoMesh or could we say that attributes are from CoreMesh, propagated to TopoMesh back and forth, but one could not have attrib managed directly on TopoMesh.

[nmellado]

From my point of view, it is totally fine if we have a first version that does not allow to add/remove attributes in the topomesh. This must be clearly stated in the documentation. Even with this limitation, one can create the attribute with dummy values before generating the topomesh, and use the topomesh to compute the actual values (possible use case would be: curvatures estimation).

If we need this functionality later on, well, we will add it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[nmellado]

Note sure this issue is totally solved, we may still have the duplicate table. Reopen.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[dlyr]

I think this one is fixed, isn't it ?

[dlyr]

at least there isn't any reference to duplicate table in Radium-Engine src.

[dlyr]

I close the issue due ton inactivities, feel free to reopen with a reference to problematic source code.

[MathiasPaulin]

I close the issue due ton inactivities, feel free to reopen with a reference to problematic source code.

There is still duplicate table management in the skinning plugin ... but I'm fine to close this and, as I planned to integrate the skinning into Radium libs, I will try to use wedges instead of duplicate tables ...

[nmellado]

If I may, I would suggest that you open a PR with the current version of the plugin (the one that use the duplicate table) so we can discuss how to switch to wedges, and we can also contribute (you don't have to do it alone).

[dlyr]

yes, skinning plugin is not part (yet) or radium-engine, so the issue is not relevant here anymore.