Simulating 100K Boids with Compute Shaders in Godot - Part 1

[@rob-not-bob]

This is great! Thanks so much for putting this out!

[@huraqan3761]

Thank you sooo much for sharing, this is what I need to do as well. Same for me, I've been experimenting with boids for years but I'm not that comfortable with compute shaders yet.

[@jRsqILVOY]

Thanks! Using textures like this definitely looks much more ergonomic than passing uniform storage buffers.

[@niceeffort1]

I did try that at one point in the process and found that they are limited to 4096.

[@AntsanParcher]

I think this code for generating the velocity is better: ``` boid_vel.append(Vector2.from_angle(randf() * 2 * PI) * sqrt(randf()) * max_vel) ``` since it gives a uniformly distributed random vector in the closed ball of radius `max_vel`. The `squrt` here makes sure that the velocities are not specifically concentrated around 0. If we want a vector of size `max_vel` exactly, we can just remove the `sqrt(randf())`. The code in the video is also uniformly distributed, but in a square where the maximum velocity is actually `sqrt(2)*max_vel`. The normalization in the simulation ameliorates this, but it means that at the beginning of the simulation more boids will be moving diagonally. One thing for the shader itself: It's unnecessary to divide by the number of friends/avoids there for the velocity/separation, since that value will be normalized after the fact either way. We only need the number of friends/avoids to realize whether we have encountered any. One problem I don't immediately have an idea for is that the world is a torus, but distance and thus the closest environment of the boids is calculated as on a plane, meaning that the swarm “tears” at the edges of the screen. I guess it should be simple enough… Ah, all differences between vectors should be replaced with calls to this function: ```glsl vec2 cdiff (vec2 a, vec2 b) { float mx = params.viewport_x; float hx = mx / 2; float my = params.viewport_y; float hy = my / 2; return vec2(mod(a.x - b.x + hx, mx) - hx, mod(a.y - b.y + hy, my) - hy); } ``` and instead of `distance` use ```glsl float cdist (vec2 a, vec2 b) { return length(cdiff(a, b)); //vec2 diff = cdiff(a, b); //return sqrt(diff.x * diff.x + diff.y * diff.y); } ``` Thank you for the video! I may be able to do the math for boid simulation, but I am really not versed with compute shaders.

[@wolcamophone4783]

This is cool, I wanna make a zen-like aquarium simulator now like you'd see in flash games from the mid 2000's where you feed them pellets to get coins or whatever.

[@ericalfaro3318]

Awesome quality content, very helpful in navigating compute shaders!!

[@niceeffort1]

Glad it was helpful! Thanks for watching.

[@dfunited1]

This was exactly what I've been looking for! You've more than earned a sub.

[@niceeffort1]

I’m glad it helped!

[@wukerplank]

Extremely interesting series! Compute shaders are such different way to approach algos and how to deal with data.

[@keepeetron]

Cool. I followed along and at the end modified it to be a gravity simulator and it worked, and was thousands of times faster than my cpu version. For a lot of the tutorial I felt like I was copying and only barely understanding, but I guess the vid would be extremely long if you explained it all. Compute shader boilerplate seems really excessive. Looking forward to future parts.

[@niceeffort1]

Yeah, the video is already longer than I had hoped and I’m not sure I could explain everything in detail. I learned what I needed to get things working. I hope to have part 2 out this week. The spatial binning that I will cover adds another huge performance increase over this.

[@TheJamesM]

An idea I had while watching the end was trying to come up with some way to colour by affinity. I'm not sure what the best way to achieve it would be. The simplest implementation I can think of is to have some arbitrary proportion of boids be "hero" boids with a fixed colour value, then have their flockmates' colours shift in that direction, but this doesn't seem like a good solution, as it makes no guarantees that a local area will have one "hero", rather than none or many. It would be better to have local flocks settle on a colour in some decentralised emergent fashion. I suppose it could use similar separation and cohesion mechanics to the movement of the boids: "steer" colour towards local neighbours with a similar heading, and away from mid-range neighbours and those with a different heading. I guess it might just turn out looking fairly similar to the direction colouring. This seems like the sort of thing I assume I can quickly throw together, then proceed to spend hours and hours struggling with.

[@niceeffort1]

I will add some info about coloring them in part 2. And yes, this is the sort of thing you can just mess around with forever. Making these tutorials is my way of calling this experiment done and moving on to the next thing. :)

[@jamessalafatinos426]

Amazing!

[@KyrickYoung]

this is WILD man!

[@ahmadrazek377]

Very cool can you please make a video for compute shaders but with slime mould that would be very cool and also a good video for compute shaders and textures.

[@niceeffort1]

Check out this link I put in the description for a slime mold simulation in Godot: github.com/erlingpaulsen/godot-physarum. I used this to learn how to connect the compute shaders and leverage textures for passing data.

[@ahmadrazek377]

@@niceeffort1 thanks man

[@chegusta]

hello! thank you so much for creating this. I've just started learning about compute shaders and I'm using this video as a starting point to step-by-step decompose different aspects of the engine and using shaders, particle shaders, etc. I'm trying to understand the transformation matrix at the moment. at 3:40 in your video, the first column states: RotZ * ScaleX RotZ * ScaleX. 've used a matrix calculator and assumed that the scaling in X and Y are not uniform (e.g, 1 and 2), the result for the first column is, if represented the way you did it: RotZ * ScaleX RotZ * ScaleY Is there something I'm missing or is it a mistake in your table? I'm just trying to wrap my head around it as it seems very useful for implementing custom particle systems. Thanks again for the amazing video (that forced me to think about this stuff :) ) and keep up the good work!

[@niceeffort1]

I added non-uniform scaling for you to look at with this changelist. Let me know if it helps answer your question. gitlab.com/niceeffort/boids_compute_example/-/commit/3a9be3374637abe127361c95d996eb6fe19faaf8

[@098765432qwertyuiop]

This kills the youtube compression :D

[@niceeffort1]

I know. Do you have any suggestions on how to improve that?

[@TheJamesM]

@@niceeffort1 Just recently I saw a video with an "enhanced bitrate" 1080p option available only to those with KZbin Premium (in addition to the standard 1080p option). I have no idea what you have to do to enable that on a new or existing video, but presumably it would help at least somewhat. Other than that I guess you could try upscaling to 4k.

[@nullvoid3545]

@@niceeffort1 If you upload your 1080p footage upscaled to 4k, then the additional bandwidth will give the footage far less compression artifacts. I saw this recently with A channel showing off comparisons of different aliasing and and GI approaches.

[@jeremiahmcelroy2726]

I've been working on a compute shader project, and I was wondering if you might know how to get mouse position use that in a compute shader. I got it working in a normal shader but I think I'm doing something wrong. I seen you mention that in the end and I desperately need the answer for that to continue on my project. I've been stuck for over a week

[@niceeffort1]

I know the feeling. Take a look at this, gitlab.com/niceeffort/boids_compute_shader/-/blob/main/Main/main.gd?ref_type=heads. Line 326, 327. Just pass it in through a buffer every frame. Let me know if this helps.

[@jeremiahmcelroy2726]

@@niceeffort1 actually I seen your github link and wondered if you had the mouse implementation on there. I got it working already! You code made me realize I didn't initialize the buffer correctly, it needs the daga passed as a byte array, I was passing it a normal float array. I found that in the docs as well after looking through your code. Idk how I missed that! Thanks for your help! I hope you continue to make videos, Godot seriously lacks resources especially with recently released features.

[@-lunte.]

really nice stuff ! do you think this could work with y sorted sprites too?

[@niceeffort1]

Do you mean you would like to control the depth of the boids as they are rendered? That is, some are always in front of or behind others?

[@-lunte.]

yes exactly! so that the lower ones on the screen are always above the others. this way i could render birds in a topdown game :D@@niceeffort1

[@-lunte.]

i found this kzbin.info/www/bejne/moXMmWSir714l8U. guess i would have to do something like that. drawing everything into one texture y sort the array and projecting that on the screen. cause particles dont support ysort i think sadly

[@niceeffort1]

I think the challenge is that for GPU 2D Particles all of the particles are at the same depth. So you may need multiple particle systems with different depths on each, or you could use a 3D particle system. I was starting to experiment with the 2D path a bit, but it might take some time for me to get back to it.

[@simplycodee]

May I know the glsl extension on vscode

[@niceeffort1]

marketplace.visualstudio.com/items?itemName=slevesque.shader

[@simplycodee]

@@niceeffort1 Thank you for the reply.

[@mbg4681]

Godoids

[@revimfadli4666]

Does this mean I can make a Huegene-esque predator prey boids ecosystem with coevolving colors vs preferences?

[@niceeffort1]

Yes. You could do something like that.

[@revimfadli4666]

@@niceeffort1 awesome! I wonder how feasible that would be by modifying this project

[@niceeffort1]

@@revimfadli4666 in part 2 I will show how to connect colors to the boids to illustrate different information. I think it woudl just be a matter of having some additional parameters on the boids. i.e. I am a boid of this type, and I am looking for boids of this other type. Then you can color the boids based on what type they are. You can get the source for this and give it a try if you want. gitlab.com/niceeffort/boids_compute_example