Change Details

Subj, it reduces number of state changes and cache flushes. Because same material uses less vertex buffers. VertexBufferManager now has a coupling about VB types, it's not really good. But a more proper way requires a much more rewriting. The current solution can be improved in future without rewriting, one might use some kind of custom allocators. The change might add few MB overhead (more precise `Group::COUNT * std::min(MAX_VB_SIZE, MAX_VERTEX_SIZE * 65536)`), but it's ok since we already use hundreds of VRAM for textures.

Subj, it reduces number of state changes and cache flushes. Because same material uses less vertex buffers. VertexBufferManager now has a coupling about VB types, it's not really good. But a more proper way requires a much more rewriting. The current solution can be improved in future without rewriting, one might use some kind of custom allocators. The change might add few MB overhead (more precise `3 * Group::COUNT * std::min(MAX_VB_SIZE, MAX_VERTEX_SIZE * 65536)`), but it's ok since we already use hundreds of VRAM for textures.

Subj, it reduces number of state changes and cache flushes. Because same material uses less vertex buffers. VertexBufferManager now has a coupling about VB types, it's not really good. But a more proper way requires a much more rewriting. The current solution can be improved in future without rewriting, one might use some kind of custom allocators. The change might add few MB overhead (more precise `3 * Group::COUNT * std::min(MAX_VB_SIZE, MAX_VERTEX_SIZE * 65536)`), but it's ok since we already use hundreds of VRAM for textures.