Add Geometry API object #48
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #23.
Adds 3 new API objects:
GeometryVertexLayoutAttributeThis is a lot of code, but for the most part this is really repetitive. Let's walk through the basic flow of defining a geometry mesh:
A
Geometryrequires aVertexLayoutwhich describes the physical layout of its vertex buffer. AVertexLayoutis comprised ofAttributewhich are a unique identifier and a format (how many components, float vs int, etc). A user can build a mesh by pushing vertex by vertex. When building a mesh, we track a "current" value for all attributes but position. This allows the user to only change attributes like colors or normals when necessary rather than requiring them to repeatedly define those attrs.By default, there are four special attributes: position, normals, uv, and color. These are the attrs that most users will interact with. However, we also allow users to add custom attributes that represent whatever property of a mesh they want. This is currently not very useful without the ability to define custom shaders, but will be more important later.
Consequently, for most operations we have a "special" pos/normal/color/uv method and then a generic custom attribute method.
Implementation
For the most part, this is just a wrapper around a Bevy
Meshasset. AMeshis aRenderAssetin Bevy terms, which means that it has a CPU representation that is extracted and uploaded to the GPU. Typically, for large meshes, we would "unload" them from being resident in CPU memory and just keep them in VRAM. However, Processing allows doing manual vertex animation on the CPU. As such, we currently provide get/set operations that modify the CPU mesh. We'll want to consider this as we add support for shaders, particularly compute, as this will introduce possible "source of truth" problems, e.g. if a compute shader modifies vertices that are stored in a storage buffer.Future work
Bevy by default will interleave vertex data in a single vertex buffer. This is an optimal representation for most typical modern GPU pipelines and allows packing multiple meshes into a single buffer. However, there are still some compelling reasons that one might want to split out attributes into their own buffers, for example in order to run a compute shader over a particular attribute. I've done some preliminary work to enable this on Bevy's side. It's not super urgent and probably pretty niche but is worth bringing up.
Screen.Recording.2025-12-25.at.12.32.11.PM.mov