René's URL Explorer Experiment

Title: Add Geometry API object by tychedelia · Pull Request #48 · processing/libprocessing · GitHub

Open Graph Title: Add Geometry API object by tychedelia · Pull Request #48 · processing/libprocessing

X Title: Add Geometry API object by tychedelia · Pull Request #48 · processing/libprocessing

Description: Closes #23. Adds 3 new API objects: Geometry VertexLayout Attribute This 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 Geometry requires a VertexLayout which describes the physical layout of its vertex buffer. A VertexLayout is comprised of Attribute which 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 Mesh asset. A Mesh is a RenderAsset in 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

Open Graph Description: Closes #23. Adds 3 new API objects: Geometry VertexLayout Attribute This is a lot of code, but for the most part this is really repetitive. Let's walk through the basic flow of defining a geo...

X Description: Closes #23. Adds 3 new API objects: Geometry VertexLayout Attribute This is a lot of code, but for the most part this is really repetitive. Let's walk through the basic flow of defining a...

Opengraph URL: https://github.com/processing/libprocessing/pull/48

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width