Core Mesh indices as triangles, strips, fans...

[nmellado]

In some situations it might be need to triangulate a PolyMesh. The current implementation is hidden in Engine::Mesh: https://github.com/STORM-IRIT/Radium-Engine/blob/443e471981a7c39fc857b07f70a577640529141e/src/Engine/Renderer/Mesh/Mesh.inl#L507

It would be more convenient to move it to Core, for instance as a method of Core::PolyMesh:` https://github.com/STORM-IRIT/Radium-Engine/blob/443e471981a7c39fc857b07f70a577640529141e/src/Core/Geometry/TriangleMesh.hpp#L280

[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'm thinking about Core Geometry classes. Do we need to have Strips and Fan as core geometry ? Do we need to handle PolyMesh as TriangleMesh with the help of a triangulate method ? If so it make me think we can envision Core Mesh with multiples indices sets. For instance one can view a TriangleMesh as a plain triangle mesh OR a triangle strip, same set of attributes, different set of indices. One solution could be to have "view" of the mesh by a new index set, and some converters. The "view" could be within the classe, with a set of indices with different semantics, or a view object, build with a plain Mesh as viewed data, and a new set of indices. Something like

triMesh = TriangleMeshView(polyMesh);
triStrip = TriangleStripView(triangleMesh);

The first option would be

polyMesh.triangulate(); //-> add a new indices set "triangles"
//or
polyMesh.addIncides("triangle", triangulator(polyMesh));
triangleMesh.addIndices("strip", strippifier(triangleMesh));

[nmellado]

I like the idea of views. From my understanding, they could implement a concept named IndexView.

Something is however not totally clear to me: usually views do not modify the input objects, but rather build a new object giving access to a given information. In our case, the indices need to be created each time we create a view. Also, the view need to be destroyed/invalidated if the mesh is.

Another option would be to have a collection of IndexViews stored in Polymesh, for instance in a map where the keys are defined by enum values: TRI_STRIP, TRI, LINE, etc.. The construction of these view can/should be lazy.

[dlyr]

A view will be a displayable object, owning a CoreMesh and managing indices. The second option you propose is, as I understand, exactly the first option I propose (leaving the semantic out of the mesh, since enum will be limited to a fixed set, and one may want to extend the index sematic for tessellation patches for instance).

[nmellado]

Ok, in my mind all of this is implemented in Core, as it could be interesting to have different index sets for processing as well. Instead of the enum, the key could be the instance of any object implementing this interface:

struct IndexViewType {
  void compute(Polymesh& in, IndexContainer& out);
};

[dlyr]

Let's list the use cases:

• triangulate a polymesh
• create a triangle strip from scratch
• stripify a trianglemesh
• compute triangle adjacency indices

At some point we need to give the semantic, and also that one may want to create a strip without the plain indices.

For PolyMesh triangulation, we may just have it as a class method, and have a converter:

 AlignedStdVector<IndexType> PolyMesh::computeTrianglesIndices();
TriangleMesh m = polyMesh; // store trianglesIndices as m.m_indices;
//or
polyMesh.toTriangleMesh();

So on the renderer side one can generate triangle indices on the fly (as needed by vao), or in core create a TriangleMesh from PolyMesh.

Afterall, I think the strip things is more like the "view" and the View Classes may hold the semantic. Such view class could be initialized with the indices directly (and manually updated) or automatically (and then notified if plain indices changes to recompute view indices).

The view approach prevent from having string only mesh, or only with invalid indices in the TriangleMesh.

TriangleStripView strip {mesh}; // autocompute, and observe indices
TriangleStripView strip {mesh, stripIndices}; //user provided indices, no autocompute, maybe some "dirty bit" if mesh.m_indices are modified, mesh.m_indices may be empty without error.
//same for 
TriangleAdjacencyView;

But do we need QuadStrip ? how to deal with Patches ? are they also some kind of "CoreGeometry"

The render indices modes are

  enum MeshRenderMode : uint {
        RM_POINTS                   = 0x0000,
        RM_LINES                    = 0x0001, // decimal value: 1
        RM_LINE_LOOP                = 0x0002, // decimal value: 2
        RM_LINE_STRIP               = 0x0003, // decimal value: 3
        RM_TRIANGLES                = 0x0004, // decimal value: 4
        RM_TRIANGLE_STRIP           = 0x0005, // decimal value: 5
        RM_TRIANGLE_FAN             = 0x0006, // decimal value: 6
        RM_QUADS                    = 0x0007, // decimal value: 7
        RM_QUAD_STRIP               = 0x0008, // decimal value: 8
        RM_POLYGON                  = 0x0009, // decimal value: 9
        RM_LINES_ADJACENCY          = 0x000A, // decimal value: 10
        RM_LINE_STRIP_ADJACENCY     = 0x000B, // decimal value: 11
        RM_TRIANGLES_ADJACENCY      = 0x000C, // decimal value: 12
        RM_TRIANGLE_STRIP_ADJACENCY = 0x000D, // decimal value: 13
        RM_PATCHES                  = 0x000E, // decimal value: 14
    };

[dlyr]

This issue include issue #74