Swarm/Mob/Flock/etc megathread

[Ivorforce]

Post discussions for a potential Swarm/Mob/Flock/Crowd simulation system here.

Feel free to post questions or discuss requirements, details like GUI or animation, or even suggest rough ideas for how this system could practically work (such that other contributors can iterate with you).

For details, see the the original Swarm/Mob/Flock/etc. proposal. The Godot developers are already aware that this is a highly requested feature; the goal of this thread is to get more concrete with the details.

If you want to participate in exploring the design and scope of this feature, please see the Swarm/Mob/Flock/etc experiments project.

[ValorZard]

I’ve been thinking about this for a while now, and what this proposal feels like to me is an ECS but with no components. Which makes sense, because Godot doesn’t really do components, it instead considers child nodes to be “components”. (Someone tried adding this, but it didn’t get accepted: godotengine/godot#105663 ) I imagine the swarm to spawn 5000 nodes, but run the same update() and physics() logic in all of them.

also, even though there is a demand to add composition to Godot (see: #12306) I just don’t think it makes much sense to add it to Godot (at least for now).
Godots entire mental model is centered around nodes, and being able to make trees of inheritance around them. Slapping on a way for each node to also have composition would break that mental model for users.

[Ivorforce]

Godot uses an ECS-like mindset (data-driven design) internally in places where it makes sense from a performance standpoint.
A swarm/mob/flock system could theoretically use ECS design to make entity updates fast. There is no reason not to use it just because Object isn't designed this way.

[Saul2022]

Great i guess flecs or Entt can be used or referenced in order to get as máximum performance as possible while still making it easy to use for users, maybe doing something like what Gabriel does https://x.com/gdechichi/status/2009314643425329485 in order to not increase the base godot size to 3.8mb( which is Flecs core file size).

With that being said, i expect if someone wants to add this super cool optimization the animation or skeletal part might be the hardest one to add since it’s not like making a whole simplified skeleton system is easy and even harder to make it multithreaded since the current skeleton , anim player/tree are thread unsafe, and how limited would the animation system functionality theorically be. And it should also be taken into account how to convert a normal skeleton to the simplified version and possibly baking the animation.

[Saul2022]

Also might be worth noting that neither unity DOTS nor unreal Mass entity can’t do animation( unreal can , but only with vertex animated textures ). So yea this is the hardest part of the swarm system.

[ValorZard]

Bevy can do animation:
https://bevy.org/examples/#animation
https://bevy.org/examples/animation/animated-transform/
https://bevy.org/examples/2d-rendering/sprite-animation/

[Saul2022]

True, though bevy was built initially with all that ECS mindset already so it was already easier for them to.add it.

[Saul2022]

In order to elaborate further by what i talked about skeleton, i will try to explain a bit better.

In my current opinion i see 2 ways of doings this making it efficient, where they both have advantages and disadvantates:

1º Use a simplified skinning system as sugested in the proposal: this would require making a simplified system like https://x.com/gdechichi/status/1934323963167178965 which gave him a massive speedup without even starting to optimize it seriously. Moreover as it is using skeleton it might be usable more or less well in anim player/tree (though with a performance drop, and since it a different skinning it could be more reliable that it can support multithreading unlike the base skinning system. Although this might be good , it would be a massive burden having to add a completely new and simplified + optimized skinning system along with making it multithreading friendly when it’s not guaranted to work well with anim player/tree.

2ºThis is where my alternative approach would come in : it is a VAT’s( vertex animated texture) system where the animation get’s baked in a animated texture to use in a vertex shader that will be automatically created after baking . Firstly, it should be on the animation player as a new button called bake. This button will convert the animation into a texture that will be used for a new shader type “vertex animated texture” that comes with the swarm system , where you just have to assign it to your mesh material and in the shader parameters just select the vertex animation you have just baked. Moreover the shader will just have a few parameters for the animation lenght, speed and as i mentioned one which decides what texture will be used for processing the vertex animation. This approach will be far more friendly to multithread + dod and cache friendly and might even be use as a compute shader if you need millions of units(which i think is unnecesary for almost all godot usecases ). On the opposite side of the coin tho, even if this might be far more performant than the 1º approach i mentioned, it will be far more limited and it will be imposible to use the anim player or tree, so no blending or fine grained control, only some parameters and a parameter that changes the vertex animated texture.

Ultimately there could technically be a 3 º approach where it combines both systems, ie when you are close you can use the simplified the skeleton system and far away it will translate to a vat , using the visibility range , although supporting both systems will be a way bigger burden to maintain and support + it will be really complex in code as the swarm code has to be ultra optimized , newbies will have an even harder time to maintain both systems on top of the swarm system.

Anyways my opinion i would choose the 2º approach as it seems simpler to add and would result in far better performance even if we lose a lot of flexibility ( which is kind of normal in a swarm/crowd system ). Hope this helps a bit in deciding how this might work for skeletal animation.

[ValorZard]

I'm not sure how this is relevant to the larger "adding an ECS alternative system to Godot" thing (I don't think its just about optimizing animation for 3D models)

[Saul2022]

Well i said this is in order to discuss ideas for how the animation system for this system would work as ivorforce mentioned at the start of the proposal.