In pipeline with meshlet, why bevy use the draw_triangle_buffer?

[clockmh]

This buffer is big because it is per triangle. A more conventional approach seems to be writing a buffer which holds per cluster data and draw instance(one instance one cluster). I would like to know the reason, thanks.

[JMS55]

Hi, I'm the author of meshlets. The reason I'm using a triangle buffer is that it's the fastest possible option that I've found.

• Using one indirect draw args per cluster with multi draw indirect is extremely slow, as the GPU gets bottlenecked by command processing, as it's many indirect draws each doing a tiny amount of work
• Using an indirect draw with a hard coded 64 vertices per cluster, and then writing out a list of clusters IDs, so that cluster and triangle ID can be derived from the vertex id, is not too bad and saves a lot of memory, but tends to be slower. Clusters have a maximum of 64 vertices, and the extra vertex invocations that get spun up only to immediately exit when the thread looks up the meshlet triangle count and realize it doesn't need to run costs a decent amount of time.
• Something that just occured to me would be doing the above, but 64 vertices total and just setting the instance count to be the cluster count. I assume this would perform basically the same.
• Mesh shaders would be the best option, but wgpu lacks support for them.

When I eventually add software raster (waiting on some wgpu changes), hopefully we can software raster the majority of clusters and gain a large speed boost. At that point, it may be worth going with a more memory efficient option for hardware rasterized clusters and eating the speed loss until we get mesh shaders. Meshlets is still a large WIP, and will change over time.

If you know of a better idea, I'd be very interested to know.

Happy to answer any other questions on the meshlet renderer that you may have.

[clockmh]

I understand now, thank you for providing such a detailed explanation.