Optimize an Index Buffer created at run-time #722
-
Hi, I'm developing a LOD algorithm that performs per-meshlet LOD selection. Each frame, I create a different Index Buffer by concatenating the local index buffers of the selected meshlets. Can I use remap algorithms ( Many thanks |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
While the direct answer to your question is yes - all meshoptimizer algorithms can in principle be used at runtime, many of them are well optimized for procedural geometry use cases - in this specific case, I don't think it makes sense and it would be detrimental for performance. The cases where the algorithms are suited for runtime use are generally such that the geometry is generated once, optimized once and then rendered many times - that way, the extra cost of optimization is paid for by many subsequent render attempts. Additionally, if the generation itself is somewhat expensive, the extra cost of running optimization may be reasonable in context. In this case, I would expect that even if you concatenate meshlet index buffers in memory, that happens on GPU, runs at GPU memory bandwidth speed, and is impractical to do anything but simple concatenation before rendering. Typically, making sure individual meshlets are well optimized (eg using newly added in v0.21 meshopt_optimizeMeshlet, or other optimization algorithms) is sufficient, and concatenation does not disrupt the order much. When multiple meshlets use the same vertices on the boundary, ideally these would refer to the same index in the original vertex buffer (so that no remapping is necessary); optimizing for vertex cache could make locality a little better but the extra gains will not justify the cost if done every frame. |
Beta Was this translation helpful? Give feedback.
While the direct answer to your question is yes - all meshoptimizer algorithms can in principle be used at runtime, many of them are well optimized for procedural geometry use cases - in this specific case, I don't think it makes sense and it would be detrimental for performance.
The cases where the algorithms are suited for runtime use are generally such that the geometry is generated once, optimized once and then rendered many times - that way, the extra cost of optimization is paid for by many subsequent render attempts. Additionally, if the generation itself is somewhat expensive, the extra cost of running optimization may be reasonable in context.
In this case, I would expect that ev…