Currently it's only possible to call SetArchetype on a single entity at a time. It'd be good if there was an overload that took a NativeArray<Entity>
#SetArchetype is missing NativeArray<Entity> overload
ashen hazel
May I ask what your use case is for bulk SetArchetype() calls?
shell widget
May I ask what your use case is for bulk `SetArchetype()` calls?
Let's say for example I want to add 16+ components to a series of entities, in this case I'd need to call AddComponent(NativeArray<Entity> entities, in ComponentTypeSet componentTypeSet) multiple times (to work around the component limit) but this would create more chunks in the process, with SetArchetype I could add all the components without creating extra archetypes.
I guess it could also be solved by adding an AddComponent that doesn't have a component limit
And maybe also AddAndRemoveComponents for adding/removing with a single structural change
ashen hazel
My general concern with using SetArchetype() as a bulk component add/remove operation is that it's alarmingly easy to accidently add/strip components you don't know about.
AFAIK there's no particular reason for the current limit of 15 components per ComponentTypeSet; we just need a reasonable finite limit, as we need to pack them into a struct and pass them around (sometimes by value) without worrying about deallocating an array of type indices. 15 components in 64 bytes seemed like a "good enough" upper bound, but if it's something people routinely run into that causes unnecessary structural changes, maybe we should bump it to 31 components in 128 bytes?
shell widget
My general concern with using `SetArchetype()` as a bulk component add/remove op...
I think bumping the limit to 31 components would be a nice upgrade, though given that's now part of 1.0 it seems like it would be hard to change?
Though adding/removing components with a single structual change would still be an issue
ashen hazel
Yes, adding and removing any number of components would still require at least two structural changes, even with better batching within the add & remove steps.
Since we're chatting here across multiple threads with a common theme, let me take a step back and ask for more details about your application. What's the use case for adding/removing dozens of components at a time, on a large number of entities, on a worker thread? My gut says the best way to make that sort of operation fast is to avoid the need to do it at all, as much as possible.
shell widget
Since we're chatting here across multiple threads with a common theme, let me ta...
Basically the idea would be for my game to be able to run simulation code behind the scenes without completely freezing the rendering part.
And then when the simulation is done I can synchronize the rendering with the simulation
That's why I'm using EET so much 👀
ashen hazel
So the idea is to use EETs for simulation on worker threads while the main thread is rendering from the same World?
shell widget
So the idea is to use EETs for simulation on worker threads while the main threa...
Yeah essentially, though it's two worlds, the simulation and rendering, then they get synchronized when each simulation step ends
ashen hazel
And the simulation steps are long, multi-frame jobs?