How to handle meshlet.triangle_count % 3 != 0?

[cone-forest]

Hi there!

I am testing mesh optimization using polyscope library which expects classical vbuf+ibuf pair (in CPU memory). To convert from meshopt_Meshlet array to an array of vbuf+ibuf pairs I do this:

struct TemporaryMesh {
    std::vector<std::array<float, 3>> positions;
    std::vector<std::array<uint32_t, 3>> indices;
};

TemporaryMesh extractMeshlet(const mr::Mesh& mesh, const mr::Mesh::LOD& lod, size_t meshlet_index) {
    TemporaryMesh result;
    
    const auto& meshlet = lod.meshlet_array.meshlets[meshlet_index];
    const auto& meshlet_vertices = lod.meshlet_array.meshlet_vertices;
    const auto& meshlet_triangles = lod.meshlet_array.meshlet_triangles;
    
    result.positions.reserve(meshlet.vertex_count);
    for (uint32_t i = 0; i < meshlet.vertex_count; ++i) {
        uint32_t vertex_index = meshlet_vertices[meshlet.vertex_offset + i];
        result.positions.push_back(mesh.positions[vertex_index]);
    }
    
    result.indices.reserve(meshlet.triangle_count);
    printf("Triangle count: %d\n", meshlet.triangle_count);
    for (uint32_t i = 0; i < meshlet.triangle_count; i += 3) {
        uint32_t triangle_index = meshlet.triangle_offset + i;

        uint8_t v0 = meshlet_triangles[triangle_index + 0];
        uint8_t v1 = meshlet_triangles[triangle_index + 1];
        uint8_t v2 = meshlet_triangles[triangle_index + 2];
        
        result.indices.push_back({v0, v1, v2});
    }
    
    return result;
}

However the rendered mesh looks patchy to say the least:

I believe this is caused by meshlets local index buffer (meshlet_triangels) not having size aligned to 3, am I wrong?

I'd say ~10% of meshlets have a this "issue". Here are constants I used to generate meshlets:

constexpr float cone_weight = 0.25;
constexpr float split_factor = 2.0;
constexpr size_t max_vertices = 96;
constexpr size_t min_triangles = 4;
constexpr size_t max_triangles = 96;

Another question:
The tiny min_triangles is caused by meshopt_buildMeshletsFlex regularly returning 0 if it wasn't able to construct a single meshlet (due to min_triangles requirement being not satisfied I suppose?). Is this normal behavior? I haven't seen any renderer handle this case - it would cause meshlets.resize(meshlet_count /* == 0*/) and later an assertion in meshlets[meshlet_count-1].
Note that meshopt_buildMeshletsBound returns value over 100.
Am I missing something here?

[zeux]

for (uint32_t i = 0; i < meshlet.triangle_count; i += 3) {

This is incorrect: the triangle_count refers to the number of triangles, and for each triangle three 8-bit indices are stored. You should use i++ and adjust the code that reads from the meshlet_triangles array to meshlet_triangles[i * 3 + 0] (and +1/+2)

meshopt_buildMeshletsFlex regularly returning 0 if it wasn't able to construct a single meshlet

This should only happen if you pass zero indices as an input I believe. Can you show the code that calls meshopt_buildMeshletsFlex?

[cone-forest]

This is incorrect: the triangle_count refers to the number of triangles, and for each triangle three 8-bit indices are stored. You should use i++ and adjust the code that reads from the meshlet_triangles array to meshlet_triangles[i * 3 + 0] (and +1/+2)

Doing this:

    for (uint32_t i = 0; i < meshlet.triangle_count; i++) {
        uint32_t triangle_index = (meshlet.triangle_offset + i) * 3;

        uint8_t v0 = meshlet_triangles[triangle_index + 0];
        uint8_t v1 = meshlet_triangles[triangle_index + 1];
        uint8_t v2 = meshlet_triangles[triangle_index + 2];
        
        result.indices.push_back({v0, v1, v2});
    }

Resulted in many degenerate triangles and ultimately a SEGFAULT due to out of bounds index value. Doing the same thing but assuming meshlet.triangle_offset is in indices, not in triangles by removing brackets around triangle_index did the same thing.

This should only happen if you pass zero indices as an input I believe. Can you show the code that calls meshopt_buildMeshletsFlex?

So I run the mesh through classic meshopt pipeline, then generate a couple of discrete LODs (everything works fine up until now) and then feed each (vbuf, ibuf[lodnumber])pair into meshopt_buildMeshletsFlex. Here's how the later part is done:

[[nodiscard]] std::pair<MeshletArray, MeshletBoundsArray> generate_meshlets(
    const PositionArray &positions, IndexSpan indices)
{
  ZoneScoped;
  ZoneValue(positions.size());
  ZoneValue(indices.size());

  constexpr float cone_weight = 0.25;
  constexpr float split_factor = 2.0;
  constexpr size_t max_vertices = 96;
  constexpr size_t min_triangles = 4;
  constexpr size_t max_triangles = 96; // up to 126, but divisible by 4

  size_t max_meshlets =
      meshopt_buildMeshletsBound(indices.size(), max_vertices, min_triangles);

  MeshletArray meshlet_array;
  meshlet_array.meshlets.resize(max_meshlets);
  meshlet_array.meshlet_vertices.resize(indices.size());
  meshlet_array.meshlet_triangles.resize(indices.size() + max_meshlets * 3);

  size_t meshlet_count = meshopt_buildMeshletsFlex((meshopt_Meshlet *)meshlet_array.meshlets.data(),
      meshlet_array.meshlet_vertices.data(), meshlet_array.meshlet_triangles.data(),
      indices.data(), indices.size(),
      (float *)positions.data(), positions.size(), sizeof(Position),
      max_vertices, min_triangles, max_triangles, cone_weight, split_factor);

  // At this point `meshlet_count` might be 0
}

I looked into what's happening inside and it seems that this if statement at clusterizer.cpp:1291 doesn't ever fire up. Is it because an input mesh doesn't actually contain < min_triangles triangles?

		// add meshlet to the output; when the current meshlet is full we reset the accumulated bounds
		if (appendMeshlet(meshlet, a, b, c, used, meshlets, meshlet_vertices, meshlet_triangles, meshlet_offset, max_vertices, max_triangles, split))
		{
			meshlet_offset++;
			memset(&meshlet_cone_acc, 0, sizeof(meshlet_cone_acc));
		}

[cone-forest]

So I just added a verification step that rejects meshlets with out of bounds indices and other problems and the mesh doesn't seem to contain many empty patches (notice the one on right back wheel)

Doing so with a higher LOD didn't do the trick though...

[zeux]

The offset should not be multiplied by 3; this is how the code should look like:

    for (uint32_t i = 0; i < meshlet.triangle_count; i++) {
        uint32_t triangle_offset = meshlet.triangle_offset + i * 3;

        uint8_t v0 = meshlet_triangles[triangle_index + 0];
        uint8_t v1 = meshlet_triangles[triangle_index + 1];
        uint8_t v2 = meshlet_triangles[triangle_index + 2];
        
        result.indices.push_back({v0, v1, v2});
    }

Is it because an input mesh doesn't actually contain < min_triangles triangles?

What are the input parameters here for the case that returns 0 - what's indices.size() and positions.size()? If the mesh has < min_triangles triangles, one meshlet will be returned; in general, up to one meshlet in the output sequence will have < min_triangles triangles.

[zeux]

Looking at your full source code, this line is also incorrect as it needs to multiply triangle_count (but not offset) by 3:

size_t meshlet_triangle_count =
meshlet_array.meshlets.back().triangle_offset +
meshlet_array.meshlets.back().triangle_count;

The rest seems fine upon initial inspection, except extractMeshlet which is not quite the code we've been discussing but presumably some later updates haven't been pushed.

Also just noting that the verification step should not be necessary: generated meshlets should never contain out of bounds indices.

[cone-forest]

Looking at your full source code, this line is also incorrect as it needs to multiply triangle_count (but not offset) by 3:

Oh yeah, that fixed the rendering issue! Thanks for looking into it!

Going to come back with more buildMeshlets failure stats in an hour or so

[cone-forest]

So the problem is gone... Dont know what caused it, dont know what fixed it, happy

Closing this as answered