Inspired by the GeoTrees thread, I’ve decided to document an attempt to make a better boids simulation.
Who?
This thread is collaborative- anyone is welcome to contribute, I’ll be acting more as a curator.
Why?
Frankly, the boids system in Blender isn’t very good. It works fine for simplistic situations, it doesn’t work well with large rule sets or rule sets that change through a simulation. The two evaluation choices for rule sets are fuzziness (which in practice seems to ignore rules) or average (which creates glitches and bugginess).
Interestingly, this isn’t a standard implementation of boids simulation. Most systems instead use a metric distance system, where which rule is followed in the moment by a member is determined by concentric distances. I’m personally also partial to a weighted system, which should allow for abrupt rule changes (such as a flock being startled by a predator)- I believe the optimal evaluation system will be a weighed distances system, rather than a simplistic average or fuzziness calculation.
How?
With the new simulation branch of geometry nodes, this should be possible to implement exclusively with nodes. My first tests will be very simple, establishing the feasibility of this, and adding complexity in layers as I go.
It seems that we don’t yet have the needed nodes to do this exclusively in geometry nodes, although I welcome any and all attempts to show that I’m wrong about this
My goal in one sentence: Large, fast, boid flocks with realistic rule following, flexible rule weights, and sudden rule changes.
I’m not great at geometry nodes, so I’m going to shamelessly tag all of you in hopes that when I run into issues, you might have a quick contribution to steer things in the right direction
This will be useful, along with the original SIGGRAPH paper from 1987, which is freely available online
@AlphaChannel I watched this video and it is super cool, but I think it might be overkill. The original boid implementation uses super simple math with no real intelligence at all. That is to say, there’s no learning- each “bird” knows where it is, and what rules it should follow, and other than that it’s ignorant of where it’s been. My goal is to remain simple with the basic math and get fancy with the bells and whistles
Something I did in the Sim branch about a month ago you can use as a starting point… Sim - Boids.1.blend (102.2 KB)
… Its a bunch of boid particles following an empty. Its using a noise texture to keep the boid particles separate as a cheat… I don’t think you can really do much better in GN because tracking collision groups and distances within those groups isn’t something GN is very good at ATM and you need that for effective boid sims.
Also, the Sim branch is currently languishing in the Archive builds section which isn’t a very encouraging sign
@Renzatic link for boid pseudo-code is a delight to read, it sound fun to try it out at least.
But for me I’ll wait until simulation branch is a bit closer to master to start using it
It’s a fair point, probably one limitation that would make things simpler is to make one flock rather than allowing multiple flocks able to interact within each others.
Even if it’s not 100 related, in this tutorial they compare each point of a mesh against each other without using loops. This would probably comes handy since we don’t have proper loops yet.
Do you think that would be enough or some basic building blocks are still missing ?
Not sure if this is what you are talking about, but the recent entagma tutorial seems to be doing just that (it detects when two points are intersecting and push them apart until there are no intersections).
That helps, but not a true solution… That algorithm requires many frames to perform the “collisions” - for boids you’d need to recursively perform that operation in one frame (i.e. a loop node with threshold is required… check the linked pseudo-code for explanation)… but it is a good hack for pushing particles away from each other but won’t guarantee that they don’t overlap.
While “simple” boids is definitely achievable and has been done, there’s also more complicated applications for the system that aren’t even really doable in blender’s current particle system as of now. I think that’s the kind of thing @joseph is aiming for with this project.
Despite the name, boids isn’t just for making flocks of birds – it’s supposed to be a simulation of any kind of crowd, from ants to armies of spaceships. The thing is, blender’s particle system is too limited to make spaceship battles and such. For instance, you can setup a battle between two sets of particles, but you can’t trace laser shots between them or replace the animation with an explosion when the particle dies. This is where geometry nodes will cone in handy. You’ll not only have a way to simulate boids, but you’ll also be able to output various values from the nodetree, using them to drive complex effects further down the chain.
Oh, I didn’t even consider that issue. It looks like we’ll have to wait for generic loops. Although there’s probably a hack or two in the mean time.
Sure, but it’s always the same balance between how many time you want to wait before having a working solution, because of the needed complexity to make the best tool possible. Especially given that key features like loops and simulation aren’t there yet.
Having what blender can actually do but in GN is already a great step forward since we’ll probably have much more flexibility and access to many more data to chain events.
If things can be improved simply even at this stage that’s even better !
Eventually dev focus will be to bring back remaining particles features and implementing a more advanced boid system in GN will be much easier.
In the meantime if I really need advanced boids for the cases you mention I’d probably use animation nodes. If the goal is to build something useful in a short period of time, keeping things simple at first makes much more sense to me !
You definitely know more about this than me, so I’m inclined to take it as absolute truth when you say this isn’t possible. That being said… I feel like it should be quite simple to maintain a minimum distance between objects without cheats, either using Geometry Proximity or Raycast, right? Again, a boids simulation at its core doesn’t have group complexity- it just has each individual element following the rules, which creates the illusion of complexity.
If this really isn’t possible, I may rename this thread to PyBoids
No, careful. Recursion and Loops have some fundamental differences. But its true that simple recursion branching types can be transformed into an iterative version.
The problem with GeoProximity is that you inevitably end up comparing the point to its own position.
That’s why there’s need for a fake loop as in the video sozap attached (I think), where you have to duplicate all the points, exclude the ones that represent the “current index” and compare the attributes (like position). Than transfer results back to original geo.
… if done inside one Object, that is…
True, recursion is a lot more general and one could argue more powerful, but in some LISP-like languages it is your only looping mechanism and like you say, things like tail-recursion can be transformed into a imperative equivalent… but not to confuse things, in the context I was talking about I did mean the more transformable version thereof.
Currently you cannot have a copy of a node-group inside of itself - if we did, that would be amazing but dangerous - could be a nice general solution if Blender could detect that and expose a “maximum depth” attribute or something like that.
Interesting. It’s mind-boggling to me that we don’t have a clean way to implement an algorithm from 1987 in Blender.
I wonder if a hybrid geonodes/Python solution would allow for Python to fill the gaps? That’s probably the approach I’m going to take in my own testing. My one worry is performance, but the existing boids system isn’t that performative anyway, so I suppose I shouldn’t stress it
