Meaning of vertex count for optimizeVertexCache/optimizeOverdraw/optimizeVertexFetch with LODS

[JesseRMeyer]

Hi,

Thank you for the excellent library!

I've been studying the demo and documentation for best practices and am confused on the meaning of the vertex count parameter on the listed functions for LOD meshes. For the main mesh, it is obvious, and for an LOD mesh, the vertex count will be reduced. However, the example code provides the main mesh's vertex count when optimizing LOD mesh indices, which is not intuitive, and some of those functions do not even take a vertex buffer.

meshoptimizer/demo/main.cpp

Line 546 in 4a28784

meshopt_optimizeVertexCache(&lod[0], &lod[0], lod.size(), mesh.vertices.size());

My hunch is that in the demo, since the main mesh's vertices are being sourced (thus the LOD indices are somewhat 'sparse'), and to not jeopardize any particular LOD mesh's rendering performance, a "worse case" is being provided. Is this accurate?

In my rendering scheme, each LOD has its own, "dense", vertex mesh to source. I am concerned that, if my understanding of the above is correct, then I will not reap all of the possible benefits of independent LOD vertex meshes by providing a worse case. As opposed to optimizing each independently, as is done with the main mesh.

In the end, since the simplify routines do not also return the new vertex count (only the new number of indices), it's unclear if the intention for my usage case is for the user to start from the beginning and remap to learn the vertex count (or do this manually another way). But this seems like a lot of redundant work for something simplify could possibly provide? Fetch will remove unused vertices anyway in the end. The issue is that optimizeVertexFetch depends upon the final index order, and I want to individually optimize each LOD's index order before using *Fetch.

Thanks

[zeux]

Generally speaking, when a function in meshoptimizer takes an index buffer and a vertex_count, vertex_count is simply an upper bound of the values referenced by the index buffer (+1). You could pass a larger value, which may cause some algorithms to run a little slower, but produce the same output.

Of course when a function only takes an array of vertex data, such as meshopt_optimizeVertexFetch, it's the actual number of vertices that the algorithm will process.

The reason why the demo passes the size of the original vertex buffer in the snippet you quoted is that that code produces an index buffer per level of detail, but shares the vertex buffer. This is optimal from the total memory consumption perspective, assuming different LODs are used at different distances within the same frame, but requires some care wrt order of optimization steps, which is noted in the comments I believe.

If you produce a compact vertex buffer for each LOD level, then that doesn't apply and you should pass the size of the individual LOD vertex buffer when working on the mesh for that LOD. For simplification to produce a compact buffer like this, you need to run meshopt_optimizeVertexFetch after simplification, as noted in the comment https://github.com/zeux/meshoptimizer/blob/master/src/meshoptimizer.h#L331. This isn't necessarily super intuitive due to function naming, but it just happens to be the same algorithm so it's currently reused.

When building an LOD chain, if you're compacting the LOD buffers either way, then you can feed the compacted vertex and index buffer for producing subsequent LOD levels indeed. The demo doesn't do that because it doesn't compact intermediate vertex buffers, as it's just reusing one buffer - there's a little bit of waste associated with that wrt processing performance when building an entire chain but it isn't too bad as the bulk of the cost is usually paid by the first simplification step (that must start with the original mesh) either way.

[JesseRMeyer]

Thank you for the detailed write up!