Replies: 1 comment 1 reply
-
Going to convert to a discussion, as there isn't any associated code changes that are actionable here. I haven't looked into glTF storage for meshlet data specifically. I think Bevy folks might have at some point. But my general observation is that the meshlet data layout seems to be rather specific to a given rendering pipeline / engine, and I don't know to what extent there's a lot of unification possible. Baseline meshopt algorithm expectation is that a meshlet is identified by a subset of 8-bit local indices and an indirection table that remaps vertex indices from local meshlet space to global vertex buffer. However, applications are free to process this data arbitrarily for actual storage, for example:
Many renderers would want some type of extra meshlet data for culling: could be just a bounding volume (e.g. sphere), could be an additional cone for normal culling, all of this might be bitpacked. Some renderers may decide to quantize the vertex data in meshlet local space, which further breaks the "vertex buffer" model as there's no concept of "vertex data" in isolation from a meshlet that embeds it. And of course some renderers may want to use hierarchical cluster storage which requires even more data per meshlet and gets even more nuanced. |
Beta Was this translation helpful? Give feedback.
-
Is there any research in defining a meshlet format for gltf?
I'm thinking a gltf scene where each chunk of 126 triangles is a mesh.
Beta Was this translation helpful? Give feedback.
All reactions