Versions of the meshlet building functions that output primitive indices

[ds84182]

Hi, I'm integrating meshoptimizer into a project that uses per-face corner (rather than per-vertex) normals (and other attributes, because of fbx things). I need to have a mapping between the meshlet triangles and the original triangles so I can lookup other attributes. Right now my only good option is to modify the code to write this out to a given buffer.

[zeux]

The absence of the algorithm versions that retain the primitive mapping is known. I have been quite reluctant to add this - mechanically, the code change is usually not difficult, but this expands the API surface. What’s more, different algorithms (apart from just meshlet construction) may have a similar need and this doesn’t always result in a uniform interface, since it’s not always the case that the primitive id relationship is 1-1.

Two other things on that note.

One, you can work around this, today, by recording the original relationship between index triples and whatever per-primitive information you’d like to store in a hash table. This is not necessarily very pretty, but with a good hash table it’s decently fast and can be used as a stop gap. (roughly speaking, std::unordered_map<std::tuple<unsigned, unsigned, unsigned>, unsigned>, although std::unordered_map is not a good hash map and tuple doesn’t have a builtin hash function, but you get the idea). This approach would not require maintaining patches.

Two, in your particular case, I can’t help but wonder if having this functionality would have made sense. Which is to say: if the meshlets are going to be used in a mesh shader, face vertex model is not a first class or an efficient model. You can record the extra data, bind the streams, fetch the data three times per triangle in a mesh shader and transform and output it - but it requires specifying a max vertex limit to be three times that of a max triangle limit, and transforming many vertices redundantly. On some hardware this is substantially less efficient than actually deduplicating vertices. The reason why meshlet builders take an index buffer and care about the values of indices in that index buffer, and don’t just partition primitives, is that they keep each meshlet under the specified vertex limit that can be set for the hardware buffers to be sized well.

If you input is face-vertex data, that’s fine - it should just be reindexed to follow a single-vertex-index model (using meshoptimizer’s reindexing functions for example). Then you will get the vertex correspondence that uniquely captures the face-vertex permutations that do matter, with appropriate sharing between the neighboring corners when possible, and the existing meshlet builders will give you the vertex indices in each meshlet that can be used to extract the vertex data. You could even extract it from the original buffers on the fly if that’s needed for some reason - but unique face-vertex combinations within the meshlet will be properly deduplicated.