Most 3D engines have a notion of a `Scene` which represents every object in a single hierarchical model. This seems intuitive because it seems like the job of a 3D engine is to show a consistent "world".
But in practice that isn't really true. You can have visual overlays and 3D widgets, which don't represent 'real' objects. You might have low-resolution proxies for reflections. Not everything needs to cast a shadow, etc. Some objects are static, others are highly dynamic. Some are pickable and clickable, some are not.
Even lighting is often subject to shenanigans, e.g. adding additional lights that only hit playable characters, to make them stand-out (Baldur's Gate 3 does this).
So in practice, a `Scene` object has to have some kind of filtering, with layers, flags, bitfields, etc, to allow it to do double or triple-duty depending on the specific context. e.g. Three.js has both standard and custom flags you can use for this.
I've always avoided this in Use.GPU, because in a reactive model, it's more natural to just assemble the world from disparate components à la carte. But this had the downside that you can't really share content at all, and instead have to repeat it in every place it is used, leading to deep, repeated component trees.
Luckily, this can be fixed, as Live behaves like an effect system. So I've added a `Batch` helper to do the gathering ahead of time. It gives you a proxy effect (a `LiveElement`, i.e. JSX) that you can drop in wherever you want.
Instead of a single scene that you pull apart with various ad-hoc tricks, you can just create batches and re-use them as appropriate. You can still mix them with one-off content too.
Data flow and reactivity is still respected, and the trees where it is used remain extremely shallow. The API surface area is tiny: one element, no props.