Would an optional, separate scene/picking helper layer be welcome in the ecosystem?

[dacoldest]

Hi, I really love the philosophy behind BroMetal.

I'm building a game-ish visualization (an ambient DevOps pipeline dashboard rendered as a 16-bit canal, with clickable ships and a follow camera), and I keep finding myself wanting a very thin, optional layer on top of BroMetal for three things:

• lightweight entity tracking (positions/transforms for a few dozen objects)
• click-to-pick (mapping a pointer event back to an entity)
• a simple 2D camera (pan/zoom/follow)

My instinct is to keep it completely separate from the core — a standalone package that never touches the render path and doesn't compromise the minimalism. Purely opt-in, and deliberately unopinionated: a helper, not a framework. If it's useful, I'd share it as-is (low-maintenance, fork-friendly), with my canal project as the demo/proof of concept.

Before I build anything, I wanted to ask: is that the kind of companion tool you'd welcome in the ecosystem, or is this deliberately out of scope for how you see BroMetal being used? Happy to shape it around your vision or to be told: "just use a scene-graph engine for that use case."

Best,
DC

[shadowcodex]

Hey wanted to let you know something similar is already being built. Antiky Framework and Studio.

Builds on top of brometal, provides bits like what you are talking about, and provides a cli with MCP that allows agent to inspect the webgpu, brometal shaders, etc.

I'm planning to release it this weekend and its been in the works for since brometal released. You can DM me on the BroMetal discord for more details.

All the PRs you see opened are from the development of Antiky and things we are contributing back. Antiky is open source fully, so welcome contributions once we get first version out.