Hi, any ideas or info on how to model complex particle systems?

The code is relatively easy, but Grasshopper is not a good platform for modelling dynamic systems.

Since the logic behind the particle system is pretty straightforward, Iâd say that this could be pretty easily achieved with the scripting components (e.g. Python, C#, etc.). However, as David mentioned above, it is basically impossible to reproduce with the other vanilla components.

If you are willing to invest some time, here is an excellent tutorial series by Jake Hebbert that explores exactly how to achieve something similar to your example in GHPython.

This is a simple cellular automata simulation, essentially Conways Game of Life. All you need is a grid that contains your cells with all the properties you deem necessary, and a way to loop through all elements and apply the rules you have thought up.

Hi, David, can you expand a little bit on âGrasshopper is not a good platform for modelling dynamic systems.â Why not?

Grasshopper assumes that there is a single solution for a single input state, whereas dynamical systems evolve over time as the current solution state becomes the input state for the next iteration. Youâre going to have to find a way to both (1) remember the previous solution and (2) use output data of iteration n as input data for iteration n+1.

Hey,

As allready mentioned this looks like conways game of life, which is in fact as simple CellularAutomateâŚ

Multidimensional Cellular Automate for Grasshopper, using the gh-internal ExpressionSolver, extended by custom operatorsâŚ

Check out the examplesâŚ

There u can find different ways to run Conways Game of LifeâŚ

Greets

Mark

The crucial difference though is that the algorithm posted above is *not* a cellular anything. It has particles with floating-point coordinates and neighbours are defined using a distance metric rather than an adjacency matrix. Itâs not a difficult algorithm, but you cannot implement it using a cellular automata.

This is more like Kangaroo than Conwayâs life game. A particle system, not a cellular automata.

You can understand a particle as a point to which to add a vector (velocity) at each step, using anemone or C#. It is very easy to implement a system of particles reducing it to the Euler method:

```
ParticleList pts
while not converged
foreach pt in pts
ApplyBehavior(pt)
foreach pt in pts
Update(pt)
ApplyBehaviour(particle){
// Swarm behaviour, not like video
ForceCohesion(particle)
ForceSeparation(particle)
ForceAlign(particle)
}
Particle class
Position
Velocity
Acceleration
Mass
ApplyForce(Vector){
Acceleration += Vector / Mass
}
Update(deltaTime){
Velocity += Acceleration
Position += Velocity * deltaTime
Acceleration *= 0
}
```

This is the basic scheme, from here we are only interested in the forces you apply to achieve different behaviors (swarms, traffic, ants, growth (see below)).

But getting that kind of behavior is not easy, but itâs not too complex either. Actually they are simple rules, but the bad thing about this type of systems, is that they are highly delicate, not only work by the rules, they also need to be parameterized within very specific domains. A set of forces will only give you acceptable behavior if you give it the right weights. The same happens with Kangaroo. The same happens with real life.

If you want to learn how to model these systems regardless of the environment, I recommend you 100% to do it in Processing, plus you will have a thousand examples. Use GH-RH if you take it to 3d.

This is also a particle system, but as a mesh instead of free particles. That means there are forces that simulate membrane behavior. As in the video, there are forces that make each particle interact with its neighboring particles/vertices.

In short, learns how to model particle systems, and then investigates how to simulate different mechanical behaviors.

Hereâs a file which has two components which could serve as the start of a framework for this.

The first component sets up an area and random population, the second component applies some rule to this population. In this case the rule is simply `"move away from the nearest neighbour"`

.

The setup is such that the particle space is reflected left-right and top-bottom, so the ânearestâ particle may well be on the opposite side of the field.

PositionalAutomata.gh (9.8 KB)

Hi Antonio,

Have you seen my post about the Game of Life?

Itâs cool that your posting all these interesting reference videos!

@MateuszZwierzycki has one the more simple elegant conditions for GOL I have seen.

*IF(stat = 0,if(nei=3,1,0),if(nei=2,1,if(nei=3,1,0)))*

You can see it in this definition (requires Anemone).

Cellular Automata Tower.gh (13.1 KB)

Thanks! Good to see people adding great content to this thread. For me this algorithm should be study with a little more depth, it just has a lot of potential.

**Scale Problem** : an individual could be describe as a set of nested âgames of lifeâ at different scales.

**Optimization** : How to implement this type of algorithm to achieve a specific goal.

**Systematization** : How to describe a game of life using network and graph theory

**Death&Reproductive Conditions** : In a nested game of life, âdeathâ could have multiple interpretations according to scale. So the death conditions for a cell are different from the death conditions of an human.

It would be interesting to know your opinion on these issues and which topics could be added?

Thanks Again!

If I understand you correctly, you are after a chimera between the **Game of Life** and an **agent-based system** (i.e. particles)?

OK, I get that, but first youâd want to get a **simpler one-dimensional system** going!

Implementing multiple dimensions or fractal states might be quite challenging and Grasshopper might not be the right app for this.

Youâd really want to have every last bit of code optimised and strip away each piece of superfluous computational ballast, since the simulation would devour every bit of computation power you through at it.

Thatâs not to say that you couldnât get similar effects in a simpler simulation!

Well, what are the tools at your disposition? And how much time are you willing to invest into this?

I think by now weâve established that you absolutely need to program this yourself. Thereâs no GH plugin that can give you the needed amount of freedom and customisation, nor will there ever be.

Achieving **specific goals** is also pretty hard! You see the Game of Life and particle systems are interesting because a complex, unpredictable behaviour emerges from a set of simple rules. Emergence is the key word here! You can change the rules and dial-in the parameters (i.e. velocity, friction) beforehand but you probably wonât be able to exactly predict the outcome.

Describing the Game of Life with **graph theory** would be more or less straightforward, and needed if you want to integrate it into a particle system.

The individual cells in Conwayâs CA are not really aware of their position in three-dimensional space. They just know their position (i.e. column, row) in the finite, two-dimensional grid of the game board. Thatâs also how each cell is aware of its neighbours. The left neighbour of a cell is simply the cell column minus 1 in the same row. This is a rather efficient and smart way to do things, since not much computation is involved, except simple integer calculations.

Now in an agent-based system, each agent or particle is at each frame of the simulation at least aware of its position and velocity in two- or three-dimensional space.

Thatâs already far more information that you need to store in your computerâs memory and update at each frame, and you havenât even added the attributes for the integration of the Game of Life principles (i.e. dead/alive, neighbours).

Like in the Game of Life, each agent needs to be aware of its neighbourhood in order to evaluate its own state (dead or alive). For this you need to measure its distance to all other system agents, to find an x-amount of closest neighbours.

In a system of thousands of agents, this would be detrimental to the performance of the simulation. Fortunately, there are optimised **spacial access models**, like the R-tree algorithm (available in rhinocommon).

OK, one method to do nested simulations could be to do them separately.

You could do all âlow-levelâ simulations, the games that somehow compose the cells/agents - and export the results (i.e. text file, CSV, YAML, JSON). In the âhigher-levelâ game, youâd import and parse the information to form your initial cell setup.

Of course, there would be no communication or dynamism between the low- and high-level simulation, since the lower ones have already concluded.

Iâd recommend looking at * âcontinuous cellular automataâ,* which the Lenia project you linked above is an example of.

They work similarly to Game-of-Life or standard Cellular Automata, where at each iteration each cell updates its own state based on the states of a small number of its neighbours, but instead of just switching between on or off, each cell has one or more floating point values which it increases or decreases using some equation taking the values of its neighbours as inputs.

Playing around with these in Processing as a student was one of the things that first got me excited about programming. I started out from a Game-of-Life example, and modified it to use continuous values. You can see some of these old experiments here.

The Processing applets donât work in the browser any more, but you can still view the code here, where you see it only needs a few dozen lines of code. All the different variations in the videos above were basically just changing that equation for NeighbourMix.

It should be fairly simple to port something like this into Grasshopper (or indeed modify one of the Python scripts or Anemone definitions posted above to use continuous values).

I think Lenia is heavily influenced by SmoothLife, by Stephan Rafler - see: 1, 2

edit - for another very interesting approach which combines continuum values on a fixed grid like the examples above with particles as free roaming agents, see this Physarum work by Sage Jenson.

On 8 April 2020, Conway, who had been struggling with health problems for years, developed a fever from COVID-19. On 11 April 2020, Conway died at age 82.

Rest in peace, John Conway.