Geometry: split geometry class into static and mutable geometry
- Dominant language
- C++
- Stars
- 107
- Forks
- 42
- PR merge metrics
- No merged PRs in 30d
Description
Current geometry (and tri_mesh) support appending new vertices/attributes, etc.
This is useful when building a mesh on the fly, or when parsing some stream.
- Current geometry API supports both linear, or interleaved data layout, and provide multiple functions to append new attributes (doesn't support deletion, appending is limited to linear layout for some function).
- Current Geometry::Buffer allow mutation through "append".
If https://github.com/google/bigwheels/issues/28 is accepted, buffer will be decoupled from the allocated memory block.
Allowing import of GLTF meshes with multiple buffers using the same underlying allocation block, while still supporting those mutable geometry/buffers APIs could become complex as appending to a buffer will imply changing neighbor buffer offsets, and underlying allocation size.
For this reason, I'd suggest having 2 kind of buffer/geometry:
- mutable geometry/buffers (as we have today). Using a 1:1 mapping for buffer/geometry.
- static geometry, allowing a single memory allocation for multiple buffers.
An alternative solution would be to keep the current geometry class, and handle it like the interleaved vs linear layout: return a failure in some cases. But it might be harder to maintain, and also become harder to use as we would need to know the layout, and how an object was created to use it correctly.
Contributor guide
Assessment
This issue has not been assessed yet.