google / google/bigwheels

Geometry: split geometry class into static and mutable geometry

Open
#31 3 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.