# Instances API Polishing

~~I've finished the distribute node and moved on to the make instances real utility. So far it's all made sense to me, but I'm having a reservation right now.~~

~~The code gets much more complicated when it has to support more than one transform per geometry set. The issue is that the iteration over instances might have to _create_ geometry sets, and they have to be owned somewhere. So simply returning an array of geometry set pointers matched each matched with a single transform won't work.~~

~~I have a couple ideas to simpify this, but I'm not sure it's better, and they have a higher cost in come situations (a large number of small instances). Though the callback approach should be preferred when we want to optimize for many instances and a lower cost operation on each of them.~~

1. ~~Return one vector of "owned" geometry sets (`Vector<const GeometrySet>`), and another vector of geometry set references matched to transforms (`Vector<std::pair<const GeometrySet, const float4x4>>`). This has a higher cost of an extra pointer for each transform, but it only requires one loop when iterating over each instance.~~
2. ~~Use a similar solution, but instead of returning two separate vectors, extend the `GeometryInstanceGroup` struct to have the ability to own its geometry set. With polymorphism I guess. This seems just like how we want to store geometry set instances created in the node tree, so this seems like a logical solution to me.~~

~~I'm not sure either of these is better than what I have currently, but I do like the second option. The time cost of trying out an option is high enough that I wanted to get another opinion first.~~

# Instances Component Storage
~~If we choose the second option, or even if we don't,~~ I think the instances component should be refactored to be stored with some method like that. Each unique instance data would become a group, and the group would contain every transform where the data is instanced. Some groups would own a geometry set, others would just point to a collection or an object. It would mean something like an array node becomes very simple:
- Create `GeometryInstanceGroup`, and give it ownership of the input geometry set.
- Add the list of transforms to the group's vector.

More optimizations would be possible while storing instances this way too. The point instance node in object or "whole collection" mode would only need to create one group, then simply fill the transform array.