Help with physarum simulation

Hello everyone! Recently, physarum simulations have become quite popular. Check out Sage Jenson’s simulations for some beautiful visuals (

I tried to simulate physarum as well using the procedure Sage described in the article. I have the simulation up and running with no errors, but it isn’t behaving the way I would imagine. My particles are jittery and seem to move randomly. Here’s the repo to my code:

Does anyone want to have a go at checking it out? I hope posting this here will open up discussion about physarum simulation in processing!



Interesting. Gives me the impression of a fluid version of Conway’s game of life.

I have made some changes to your sense function. (comments added)
Perhaps not exactly your vision, but will hopefully get you heading in the right direction. :wink:

void sense(trailmap tm){
    float nextIntensity = 0;
    float maxIntensity = 0;
    float maxHeading = 0;
    for(int i = -1; i<2; i++){
      //get radians angle from heading direction

      // Change the view relative to our current heading
      float look = heading + i;
      float angle = radians(look*45);

      // increased how far we can see, mostly for diagonals
      PVector offset = PVector.fromAngle(angle).mult(1.41);

      // Removed rounding steps till the end of calculations
      //offset.x = floor(offset.x);
      //offset.y = floor(offset.y);

      int currentX, currentY;
      //currentX = int(floor(pos.x) + offset.x);
      //currentY = int(floor(pos.y) + offset.y);
      currentX = int(pos.x + offset.x);
      currentY = int(pos.y + offset.y);

      if(currentX > width-1){
        currentX = 0;
      } else if(currentX < 0){
        currentX = width-1;

      if(currentY > height-1){
        currentY = 0;
      } else if(currentY < 0){
        currentY = height-1;

      nextIntensity = tm.grid[currentX][currentY];
      if(maxIntensity < nextIntensity){
        maxIntensity = nextIntensity;
        dir.x = offset.x;
        dir.y = offset.y;
        maxHeading = i;
   //turn particle

Hey @noahbuddy , yeah, it’s a kind of cellular automata and there’s a whole genre called cyber fungi dedicated to simulating this.

I just implemented your changes and the simulation now works! I can’t believe I forgot to adjust the heading when sensing the trailmap. Also, the sensing distance is also a great idea. Thank you!

@musiciantriescoding – Sorry for the late comment, I am just discovering this thread now.

I remember trying my hands at this algorithm about a year ago, hoping like you to generate similar outputs, and quickly came to the conclusion that Sage Jenson was not telling the whole story about his implementations. The animations are much more fluid, material transportation and deposit looks incredibly more organic. So far, I have not seen anyone getting even close to his outputs based solely on the paper mentioned in his article.
Some believe there is some sort of fluid simulation at play, other think it is a combination of different growth algorithms… the magic recipe has still to be found.

It is worth mentioning that Jeff Jones (author of the original paper in 2010) has published an another document a couple of years later entitled Emergence of Self-Organized Amoeboid Movement in a Multi-Agent Approximation of Physarum polycephalum. I didn’t give it much time yet but it might worth checking.

In a nutshell he introduces the difference between oscillatory and non-oscillatory behaviors and suggests to adjust the strength of the inertial effect probabilistically.

Some old unsatisfactory outputs:

(non-osciallatory behavior)

(osciallatory behavior)


Hey @solub, thanks for the reply! No worries, this thread is not that old and I’m still thinking about this topic.

Here’s an output I got


I initially suspected the same thing as you did. However, Sage Jenson mentioned that all he did was played with the parameters he listed in his article. I’ve thought of a few ways one could play with the parameters. Here are a few:

  1. Scaling the deposition amount by the particle’s velocity
  2. Scaling the particle’s velocity by the intensity of the trailmap
  3. Scaling the turning angle by the particle’s velocity
  4. Scaling particle velocity by distance to center of screen

and so on…

I’m quite sure by playing with the parameters like this in a creative way and in creative combinations, we could arrive at similar outputs as Sage did. After all, this is the part of creative coding that’s for the artist to play with!

The animations are much more fluid, material transportation and deposit looks incredibly more organic.

I believe this has to do with how he implemented it: fully on the gpu. The sheer amount of particles (5-10 million) will definitely make the simulation look more refined. My simulation had only 5,000 particles because I implemented it on the CPU.

Thanks for the link to the new document! I will check it out.

Interesting, thank you for sharing your thoughts and the outcome.

Have you tried increasing the amount of particles ? Your code indicates a default number of 20000 and I was able to run your sketch with up to about 100000 particles. On my side I didn’t notice any improvement in the overall behavior even though it is still far from the 5 millions indicated in the article.

Have you seen him saying this explicitly somewhere ? In the article he mentions Jones’s paper then talks about his implementation and how it differs from the original rules (no collision detection) but nowhere he says having restricted the algorithm to the initial parameters. Again, I wouldn’t be surprised if the whole thing was a combination of more complex behaviors.

That said, like you I do think there is some sort of dynamic scaling at play and I am suspecting the angle of rotation (turning angle) to be somehow depending on the amount of chemo-attractant detected by the sensors. In his article Sage J. also mentions a “contagion behavior” that seems to affect the shape of the trails. The more “contaminated” a particle is, the more diffuse and widespread its displacement. At least that’s how I understand it.

Some notes:

1 Like

Hi @solub
I don’t know how to reach you, so I’ll try it this way.
In one of your posts you recommended the “hemeshgui” tool.
I installed it, but it gave an error that came from the HE_Mesh lib.
The “Ref_HEC_ConvexHull” example also gives the same type of error “The function setN(int) does not exist.” @wblut is not a subscribed member, so I already posted an issue on Github, but I’m afraid that it will take a long time to receive an answer. because another issue is waiting for months.
Do you have a working version?