When I first saw this type of cellular automata described by Gugubo on Reddit I was sure I must have implemented it and included it in Visions of Chaos before, but a quick check showed it wasn’t a CA I had covered. There is enough info in the Reddit thread for me to code it up and put it into Visions of Chaos.

This is a 1D Cellular Automaton that uses 5 cells from the previous generation (2 either side and the central cell) to update the new cell state. The larger neighborhood with 2 cells either side is why I called these “Extended Neighborhood” in Visions of Chaos.

There are 4,294,967,296 (2^32) possible “rules” or types in this CA. Each of the rule numbers can be converted into a 32 digit binary number. For example, rule 260 becomes;

00000000000000000000000100000100

To update a cell, use the following steps;

1. Convert the previous step’s left 2 cells, current cell, and right 2 cells into a binary value.

i.e LLCRR may have states 11010 which can be converted into decimal 26

2. Counting from right to left on the binary representation of the rule above, the 26th digit is a 0, so the new cell state is a 0.

The process is repeated for all cells and then repeated for all rows as long as the CA runs.

I also added the option for more than 2 states (alive or dead) per cell. This way, when a cell dies it does not turn instantly into a dead cell, but has a delayed dying period. If there are 4 states per cell then a living cell (state 1) that dies will first go to state 2, then state 3, then finally die (state 0). Only newly born state 1 cells are used in the rule. All other non state 1 cells are considered state 0 when updating the cell based on the binary string rule.

Jason.

]]>For the 3D code I extended the 2D SPH code I had into the third dimension. In the end it wasn’t too difficult (everything seems simple once you work out how to do it). After a week or so of hacking away I had multiphase fluids flowing in 3D space.

The code is based on Tom Madam’s SPH Code in this blog post. For 3D you just need to add in a Z dimension for particle positions etc.

3D is slower than 2D with the extra dimension and even with a decent multi-core CPU the simulation starts to crawl as the particle count increases. Using the awesome Mitsuba to render some nicely lit spheres got me the following movie.

Jason.

]]>For example, rather than the usual Mandelbrot Fractal iteration, you can modify the inside loop to alternate between the Mandelbrot, then the Burning Ship, then the Mandelbrot, and the Mandelbrot again. You then repeat the sequence for as many iterations as that pixel needs.

This gives a result like the following

The code to create this (and other hybrid formulas) is included with Visions of Chaos, but you can also see the OpenGL shader code for it here.

I have also used the same hybrid technique for 3D Mandelbulb Fractals as shown here.

Jason.

]]>At that time I made some mistakes with my code that resulted in not all of the objects being compared to all of the objects in the gravity calculations. For the purists this is not acceptable “How can you call it a gravity simulation if you are not using all objects in the calculations?!” The other opinion raised at the time was if it looks good enough, use the speed ups. None of the comments to my YouTube gravity videos were (in typical YouTube speak) “haha lol! looks fake! u no do gud gravity!”. So, if you are struggling with getting gravity working fast, try reducing the number of actual particle interactions.

Here is the latest updated CL kernel code….

```
__kernel void Gravity3DKernel(__global float4* pos, __global float4* vel, __global float4* acc, __global float4* mass, float mingravdist, float forcescalefactor, int startindex, int stopindex, int gridsize)
{
int index=get_global_id(0)+startindex;
float dx,dy,dz,distance,force;
float positionx=pos[index].x;
float positiony=pos[index].y;
float positionz=pos[index].z;
acc[index].x=0;
acc[index].y=0;
acc[index].z=0;
for(int a=0; a<get_local_size(0); a++) {
if (a!=index) {
dx=pos[a].x-positionx;
dy=pos[a].y-positiony;
dz=pos[a].z-positionz;
distance=sqrt(dx*dx+dy*dy+dz*dz);
dx=dx/distance;
dy=dy/distance;
dz=dz/distance;
force=1/(distance*distance+mingravdist*mingravdist)*forcescalefactor;
acc[index].x+=dx*force;
acc[index].y+=dy*force;
acc[index].z+=dz*force;
}
}
vel[index].x+=acc[index].x;
vel[index].y+=acc[index].y;
vel[index].z+=acc[index].z;
}
```

The kernel processes all of the 3d objects once using 1 of the other objects (passed as startindex).

You can call the kernel multiple times each frame/step of the simulation. If you want strictly accurate (and slow) gravity simulation results you call it inside a loop that sets startindex from 1 to the number of objects. In my experiments this is not necessary. If you want “good enough” nice looking gravity simulations then calling the kernel with as little as 10 different startindexes (use a set of objects spread out among all of them or just use a random set of 10 objects each frame).

Here is a recent 4K resolution example movie. This one used 1,000 objects out of 5,000,000 objects for the gravity calculations. The objects start by being randomly placed within an oblate spheroid. Their velocities are initialized so they are rotating around the center axis.

Jason.

]]>The idea for these came from a comment Tsui Kagura left on one of my YouTube videos.

*Can you make a CA that is 4D ( or 5D etc ) in a sense, that you use 2 (or more) different regular CA rules, run them in the same space (same coordinates), same time (same steps), but then, based on some kind of rule also have them interact with each other?As if they were neighborhoods from another dimension. I assume we could only be ‘seeing’ one of them, the rest would be in a hidden dimension, but affecting the one we’re looking at. If there are more than one hidden dimensions, they could affect each other too, maybe using a different rule between them…*

Using multiple rules on the same CA is something I have not experimented with before, so I had to give it a go.

To start off I used the simplest 2 state 2D CAs. The extension from a usual 2D CA is simple enough. You run 2 rules over the same grid. Store the results of each rule (either 0 or 1 for dead or alive) and then you use the results of the rules to set the new cell state.

How the 2 rule results are converted into a new cell state is the tricky part.

For two 2D CA rules there are 4 possible outcomes (dead dead, dead alive, alive dead, alive alive). So depending on the result states I have 4 options for alive or dead. This gives the following options.

Here are a few sample results after trying hundreds of random rules.

I will update this post if I find any more interesting results. There are many more extensions to try like 3D, 4D, 5D, larger neighborhoods, more than 2 rules, etc.

I did try the 3D version of multiple rules. Nothing worth posting as yet. I used both the result1 and result2 method above and also tried feeding the result of rule1 into rule2. Neither has given any unique looking results yet.

Jason.

]]>Flame Fractals were originally developed by Scott Draves as an extended version of Iterated Function Systems.

See this PDF for a more thorough explanation.

Visions of Chaos has supported flames for years now, but something I recently revisited was detecting interesting looking flame fractals.

The flame fractals appearance are controlled by the coefficients, probabilities, transformations and multiplier values (the lower table floating point values in the above dialog), but 99% of the time if you just set random values it will lead to boring images. Boring here means an image that is just a few straight lines, a circle, or only a few pixels.

Searching for an interesting flame fractal means repeatedly randomizing the controlling parameters and testing the resulting plotted points. Here is a snippet of code I use to test each random set of parameters.

```
xp:=0.05;
yp:=0.05;
//skip first 1000 iterations to allow it to settle down
for loop:=1 to 1000 do iterate_point;
repeat
thisxp:=xp;
thisyp:=yp;
//iterate the next point
iterate_point;
//test if tending to a point
if (abs(thisxp-xp)<1e-10) and (abs(thisyp-yp)<1e-10) then
begin
TestFlameParameters:=false;
exit;
end;
//check if unbounded, ie values are getting too large
if (abs(xp)>10000) or (abs(yp)>10000) then
begin
TestFlameParameters:=false;
exit;
end;
//check for NAN
if (isnan(xp)) or (isnan(yp)) then
begin
TestFlameParameters:=false;
exit;
end;
//check for INF
if (isinfinite(xp)) or (isinfinite(yp)) then
begin
TestFlameParameters:=false;
exit;
end;
//count pixels that fall within the image area
if (xp<xmax) then
if (xp>xmin) then
if (yp<ymax) then
if (yp>ymin) then
begin
xplot:=trunc((xp-xmin)/abs(xmin-xmax)*width);
yplot:=trunc((yp-ymin)/abs(ymin-ymax)*height);
hitpixelscount[xplot,yplot]:=hitpixelscount[xplot,yplot]+1;
end;
inc(pointcount);
until (pointcount=250000);
//count pixels hit
hits:=0;
for y:=0 to height-1 do
for x:=0 to width-1 do
if hitpixelscount[x,y]>5 then inc(hits);
if hits<trunc(width*1.5+height*1.5) then
begin
TestFlameParameters:=false;
exit;
end;
//if it got to here then the tests all passed
```

The tests included in the code and the ones I found most useful are;

1. Detect tending to a single point. A lot of flames result in the iterations being attracted to a single point/pixel.

2. Unbounded. Points continue to grow outwards to infinity.

3. NAN and INF. If the floating point math returns a NAN or INF.

4. Count pixels hit. If the resulting image has too few pixels the flame picture will be boring. Counting the pixels helps detect and avoid these flames.

Using those 4 checks will skip hundreds (at least in my case) of parameters that fail one or more of the above tests. The result is when looking for new random flame fractals you skip the boring point-like and line-like displays.

The following screen shot of the flame mutator in Visions of Chaos shows a series of flames that all passed the tests. They may not all be interesting aesthetically, but there are no minimal results with just a small number of pixels.

I did also experiment with lyapunov values, ie

http://technocosm.org/chaos/attr-part2.html

http://sprott.physics.wisc.edu/software.htm

but in my tests they are too unreliable to detect good vs boring flames.

If you know of any other reliable ways to detect good vs bad/boring flame fractals, let me know by email or reply to this post.

Jason.

]]>For example, the usual Game Of Life CA uses the rule 23/3. If a live cell has 2 or 3 neighboring live cells it survives. If a dead cell has exactly 3 live neighbors a new cell is born at that location. This sort of rule is called deterministic as there is no random chance involved. To make the rule stochastic we can introduce a probability for the rules. The 3 for a cell to be born could have a 90% probability applied. Now if an empty cell has 3 living neighbors it will only be born if a random value is less than the 90% probability.

When implementing the interface for stochastic CA, rather than the usual 3D Cellular Automata settings;

the probabilities are added;

Finding interesting stochastic results seems even more difficult than in deterministic CA. For the 2D variation lichen like growths seem common. For 3D I have been able to tweak some amoeba like growth structures. Here is a sample movie of a few 3D rules.

2D and 3D variations of Stochastic Cellular Automata are now included with the latest version of Visions of Chaos.

Seeing as these are new modes there are very little sample files included with them. If you download Visions of Chaos and find any interesting rules, please email them to me for inclusion in future releases.

Jason.

]]>Thanks to Étienne Jacob‘s twitter post here and the source code he generously shared I was able to have a go at spring pendulums.

Spring pendulums are similar to the previous double, triple and quadruple pendulums, but the fixed length pendulum arms are replaced with springs. This leads to more complex plots.

Here are some examples of a double, triple and quadruple spring pendulum.

To make the plots a little clearer, here they are again with only the pendulum end points being traced.

Spring pendulums are now included with the latest version of Visions of Chaos.

Jason.

]]>Since my last post explaining Multiple Neighborhoods Cellular Automata (MNCA) /u/slackermanz released his source code to hundreds of his shaders based on the same principals. Some using different neighborhoods, but all based on the same idea of multiple neighborhoods with rules for each neighborhood working together each step of the CA.

In the past you may have seen Kellie Evans’ Larger Than Life CA variations that use larger circular neighborhoods to make unique bug shaped gliders. In my opinion /u/slackermanz MNCA varieties are vastly more interesting with much more complex results compared to the bugs in Larger Than Life. Seeing new results like this not come from the depths of academia is also refreshing.

Some of these results are simply fascinating. Shapes and structures including blobs, amoeba like creatures with cell walls, cells that undergo mitosis and split into 2 smaller cells, worms, snakes, multi cellular worms that travel across the grid, circular cells that behave like they are hunting other cells, blobs grow and split, fluid like ripples and chains of cells that resemble algae. I have stared at some of these like they were a virtual lava lamp.

MNCA are a superb example of complexity from simple rules. The way some of the results seem to have almost intelligence in their behavior. Of course this is all a side effect of how the CA rules work and no real AI, intelligence or otherwise is involved. But, as with all CAs the emergence of interesting patterns from the simplest of rules occurs.

I have trimmed his original set of 470 shaders down to 45 which are now included with Visions of Chaos. If you are in any way interested in cellular automata I encourage you to download Visions of Chaos or /u/slackermanz’s source code and have a play with the MNCA shaders yourself.

Here is a 4K movie with some examples of how the MNCA work.

My next idea was to try extending MNCA to 3D. Rather than the 2D circular neighborhoods, use 3D shells like the following. The shells have 1/8th cut away to show the concentric rings.

7824 neighbor cells to count.

3337 neighbor cells to count.

2718 neighbor cells to count.

6188 neighbor cells to count.

So far I haven’t found any interesting 3D results worth posting, but some interesting structures.

MNCA need to be run on larger sized grids to allow their larger neighborhoods room to grow and evolve. That means in 3D you need to use large dimensions 3D grids. Using a large sized grid, and having to count all those thousands of neighbor cells for every 3D location really takes its toll on calculation times. I have now added 3D MNCA to the latest version of Visions of Chaos so if you have a grunty machine and patience you can try finding some 3D MNCA rules yourself. If you find any interesting results please send the M3D paramter file(s) to me.

To be continued…

Jason.

]]>Rock paper scissors is a simple game that dates back to around 200 BC.

The game is played between two or more players who make a rock, paper or scissors shape with their hand at the same time. Rock breaks scissors, scissors cut paper and paper wraps rock. See this Wikipedia article for loads of info on the game.

__Rock Paper Scissors Cellular Automata__

Converting the game principals to a cellular automaton is simple enough. This is how I implemented it;

Every pixel color is calculated by playing a virtual 9 player game of rock paper scissors. The current cell vs its immediate 8 moore neighbors. If the neighbor count is greater than a threshold value in the result that beats the current cell then the current cell becomes the winner (what a terrible sentence). For example, if the current cell is scissors, the threshold is 3, and there are 4 rocks surrounding it, then it becomes a rock.

Using the above algorithm leads to very stable exact spiral shapes. The initial grid in this case was the screen divided into 3 “pie wedges”. One for each of the 3 states.

Adding some randomness helps break up the exactness of the spirals. Rather than checking if the winning neighbor count is greater than a specified threshold, check if it is greater than a threshold + a small random amount. This gives more variety in the spirals. This next image used a threshold of 3 and between 0 and 2 added randomly.

__Rock Paper Scissors Lizard Spock Cellular Automata__

I first saw this variation on The Big Bang Theory.

It was invented by Sam Kass. Lizard and Spock are added in as 2 more possible moves. This results in the play logic..

Scissors cuts Paper, Paper covers Rock, Rock crushes Lizard, Lizard poisons Spock, Spock smashes Scissors, Scissors decapitates Lizard, Lizard eats Paper, Paper disproves Spock, Spock vaporizes Rock, Rock crushes Scissors.

For the cellular automata you add 2 more cell states for Lizard and Spock. Otherwise the rest of the CA uses the same logic as the 3 state Rock Paper Scissors version.

It is interesting that the 5 states do not fully intermingle. Island blobs with 3 of the 5 states seem to form. In the above image there are clearly areas with only red, yellow and orange cells, and then other areas with only red, green and blue cells.

The following is an animated GIF of 45,000 steps (updated 1,000 steps per frame) that shows how these blobs fight for dominance and in this case RGB wins in the end.

__RPS 15__

RPS 15 includes Rock Gun Fire Lightning Devil Scissors Dragon Snake Water Human Tree Air Wolf Paper Sponge.

Threshold 2

Threshold 2 Random 2

Threshold 3

Threshold 3 Random 3

__RPS 25__

RPS 25 pushes it to 25 possible moves.

Threshold 2

Threshold 2 Random 8

Threshold 3

Threshold 1 Random 4

__RPS 101__

There is even the insane RPS 101. See the RPS 101 moves here.

I didn’t code RPS 101 as yet.

__Image Based RPS__

This idea came from *NoSocks* on YouTube. To use an image as RPS;

Find which of the RGB values is highest for the current pixel. Choose a neighbor at random and find which of its RGB values is higher. R is Rock, G is Paper and B is Scissors. So if the current pixel has the highest G value from its RGB values and the neighbor has the highest B value from its RGB values then the neighbor cell color is copied into the current cell (because B=Scissors beats G=Paper).

You can also use the smallest RGB values.

Here is an example animated GIF of Van Gogh’s Starry Night put through the process (click to open). Source RPS is determined by largest RGB. Opponent RPS determined by smallest RGB value.

__Availability__

Rock Paper Scissors CA and the above variations are now included in the latest version of Visions of Chaos

Jason.

]]>