Are disjoint meshlet chunks expected?

[bc-nine]

I've noticed that the meshlets generated from my models are mostly great, nicely localized, etc. But I am seeing some meshlets built from meshopt_buildMeshlets() that aren't contiguous, i.e. parts are separated in space. In my first screenshot, I am rendering a (subdivided) cube, and you can get an idea of the typical meshlet radius here. The second screenshot shows a single (disjoint) meshlet, and the resulting (large) bounding sphere. Due to the size of the sphere, frustum culling isn't removing meshlet chunks that are well outside the frustum, and I'm just wondering if ending up with some meshlets like this is to be expected.

The microsoft meshlet cull demo has nice clean culling outside the view frustum. It's still somewhat jaggy looking of course because we're culling at the level of meshlets, but there aren't any meshlet chunks clearly outside the frustum. I'm wondering if there's some additional processing I need to do to the models, if this is normal behavior for the meshlet builder? Thanks,

[zeux]

These should be rare but yeah it's expected that sometimes you get these. The basic example is that when you start from a not-fully-connected mesh then unless each connected region of the mesh fits neatly into an integer number of meshlets, the builder will be forced to either generate partial meshlets, or merge meshlets from multiple locations into one, even though that results in larger bounds. Right now it always prefers the former.

When the source mesh is fully connected, because the meshlet builder doesn't use graph partitioning, there are cases where the greedy algorithm leaves chunks that are smaller than max meshlet size and they need to be put into some meshlet - again, right now the builder always prioritizes fully packed meshlets if possible so this can happen as well. It might be possible to adjust the greedy prioritization heuristic to reduce the chance that this can happen, but I don't think it's feasible to eliminate it as a possibility.

[zeux]

P.S. I should mention that the picture you shared looks as if this is the last meshlet in the entire mesh, assuming you are using meshopt_buildMeshlets and not meshopt_buildMeshletsScan. When looking for the extra triangles to put in a meshlet when the builder runs out of adjacent triangles, it looks at the proximity of vertices and merges triangles in the distance order. For the algorithm to merge triangles this far away, the meshlet builder must have completely ran out of options and this usually means that it's the last few triangles that need to be added.

[bc-nine]

Interesting ok. I'm trying to reconcile what you've said here to what I'm seeing. Starting fresh with a slightly different subdivided cube this time (testcube.txt, an OBJ model centered at origin, -1 to 1 along each axis), I call meshopt_buildMeshlets() using 64 verts/124 tris as recommended (I have RTX2080 NVIDIA card), and cone angle 0. This generates 333 meshlets, 7 of which have a bounding sphere radius of 0.5 or more (so pretty large given cube dimensions). From that set of 7, I picked the top 3 largest, and color those red, green, and blue:

Red: id 326, radius 1.2, 61 tris, 64 verts
Green: id 329, radius 1.0, 75 tris, 64 verts
Blue: id 331, radius 0.95, 79 tris, 64 verts

Everything else is grayscale. For this test, I zeroed out all attributes in my vertex structure except for position x/y/z (3 floats) before passing buffers to meshoptimizer. The only thing I can think of is that somehow the mesh isn't fully connected (maybe round-off errors in position?), so there end up being multiple disconnected regions or something. If this looks expected based on everything I've said, I'm happy to mark as answered, just want to verify first.


testcube.txt

[zeux]

This is a little worse than I expected, but I'll need to take another look at the algorithm to see what the best/worst case scenario is and whether this can be improved. I've created #489 for tracking.