What makes this three.js implementation of the boids algorithm so performant exactly?

Questions
1

Greetings, beautiful community.

I am currently dabbling in the boids flocking algorithms examples and research papers available online, trying to make sense of how I should implement it for my game.

My aim is to give my player the ability to control the flock using virtual or physical gamepad axis, and so as always, I am aiming for performance since the project is mobile-oriented and controlling the flock is one of the many things which will happen in the game…

While searching for WebGL examples, I stumbled across this example, try it, it runs butter smooth on mobile. Furthermore, there is a modified version using an imported gltf. Heck, this scene contains 4096 animated meshes and still manages to be above 30 FPS on my OG 2016 google pixel xl.

Quite impressive in comparison to the vast majority of other examples I’ve found, even 2D.

The whole thing is coded in GLSL, with which I am almost completely illiterate still…So I fail at seeing what exactly is going on. (Would be ready to learn, but the ressources online are not helping me to go further than a red triangle)

…And so this is why I am reaching out to the community, in case someone would know a little more about why this example performs so well and how one would go about making a similar thing in Babylon, perhaps by assembling it in the Node Material Editor…? Idea for a future tutorial video?

Here is a link to the HTML containing the whole code, so that you can have a look yourself at what black magic is going on exactly: three.js/webgl_gpgpu_birds.html at dev · mrdoob/three.js · GitHub

In hope to gain some insights and trigger a conversation that might help current & future boids-explorers…!

1 Like
2

I think the key is off-loading the heavy work :slight_smile:

Here’s 64000 Thin Instances of a box, each is being moved separately by updating its position matrix.

This is of course much simpler scene and movement, thus why it can handle many more.

https://playground.babylonjs.com/#V1JE4Z#3

1 Like
3

The heavy duty is done on going. Hence the perf

You can do the same (and literally copy paste the glsl code) with our ShaderMaterial

5

Good morning.
Thank you for your replies.
It sure sounds like you guys are talking about the same thing…! :no_mouth:

I am just coming back from rewatching @Deltakosh’s recent video on thin instances and it truly excites me to see the same playground moving; thanks for the link @aWeirdo!

Yet I am puzzled:

-Could this be brought further and be used to implement a boids algorithm successfully?
-Are these playgrounds and the GLSL code in the three.js example reaching the same end, but one in is in javascript and the other strictly in GLSL? Meaning I could avoid GLSL and reach similar performance? My aim sure not is to copy-paste and call it a day. This will only bite me later.

I am also hearing from Delta’s video that this is “only a rendering”, thus this makes me concerned about how this would then interact with the rest of the game world… If there is only one scene node for the whole boids flock, is it thinkable that they could have interesting behaviours such as obstacle avoidance and collision detection? Do I dare asking, ammo.js physics?

This is the super power of my avatar, to transform in a million pieces, and so I have a million questions.

Hehe.
Cheers.

6

Thin instances are really powerful but each update is expensive. And you are right about purely doing the work on the GPU, it could become a problem later when you will need to add more interactions (unless you keep a local simplified model maybe?)

1 Like