Update a cellular automata using different neighborhoods and rules every second step. The first step uses the 4 neighbor cells north, south, east and west. The second step uses the 4 diagonal neighbors. Then they alternate each step of the CA. Each neighborhood has its own set of rules for birth and survival.

There are a total of 2^20 or 1,048,576 possible rules using this method. 9*2^20 (9,437,184) if you take into account a maximum state value of between 2 and 10 for each cell.

Click the following to open a short GIF animation of each of the rules. The thumbnails are a mess.

Amoebas

Fireworks

Gliders

Life-ish

Traffic

Walkers and Spinners

Extending the possible maximum states of each cell up to 10 shows potential with some more interesting structures.

Expanding Ships

Fireballs

Spirals

Stick Growth

My next idea was to extend the neighborhoods as follows

The settings are extended to handle the larger neighborhood.

This gives 2^52 or 4 quadrillion (4,503,599,627,370,496 to be exact) possible rules (and that is only for 2 state rules). A maximum cell state of 10 gives 9*2^52 or 40 quadrillion (40,532,396,646,334,464) possible rules. Finding those sweet spots of interest between dying out and total chaos becomes even more daunting.

I wasn’t confident that those neighborhoods would give any interesting results beyond chaotic noise, but they are showing potential so far from random searches and mutations of rules.

Amoeba

BZ-ish

Fire Ships

Pulsating

Thick Ripples

The Alternating Neighborhood Cellular Automata are now available as part of the latest version of Visions of Chaos.

Another new cellular automaton. This time inspired by this post by Xiaohan Zhang (@hellocharlien on Twitter). I messaged Xiaohan about his algorithm and he generously provided the source code to his CA processing sketch here.

I called them the “Zhang Cellular Automata” as there was no official name given to these.

How they work

Setup a 2D array of integers for the CA cells. Fill with random values between 0 and numstates-1. I allow up to 9 for the numstates which means a 0 dead state and 1-8 alive states for cells.

Create a rule table which is an array 9×9 integers in size. Fill with random values between 0 and numstates-1.

Now the steps when processing each cell.
1. Count how many of the 8 Moore Neighborhood neighbors there are in each state (between 0 and numstates-1). This gives you an array countStatesOfNeighbors[0..numstates-1].
2. Remember the current cell state value.
3. Loop through the possible state ranges from 0 to numstates-1.
4. If the rule entry matches the loop then assign the loop value to the cell, otherwise the cell remains as is.

Here is my code for updating each cell

mystate:=c[x,y];
for s:=0 to numstates-1 do
begin
if (countStatesOfNeighbors[s]=rule[myState,s]) then
begin
mystate:=s;
break;
end;
end;
t[x,y]:=mystate;

Results

There are interesting cyclic results that tend to go through cycles of life and death. One state will fill out an area of random noise with a new pattern and that pattern allows a new pattern to fill it, before the original random state refills the area.

Since there is no name given for this CA, I called it the “Two Steps Back Cellular Automata”.

How it works

This time it is a more simple 1D CA.

Each cell is updated by counting the neighbors 2 cells either side of it and itself (5 cells) and the same 5 cells in the previous generation. This gives you a possible count of active cells between 0 and 10. The count is used into a rule array for the new cell state.

For example, if your rule array is rule[1,0,0,0,0,1,0,1,1,0,1] and the cell has 5 neighbor cells that are alive, then the new cell would be alive too (the rule counts start at 0, so the 6th entry in the rule array is for 5 active neighbors and that entry is 1).

You can convert the 11 digit rule into a binary string. The above is 10000101101 which converts into the decimal number 1069 (not 1441 as in Charlie’s post – looks like he reversed the binary digits before conversion).

Results

There are 2048 possible rules. Not a big amount compared to some CAs, so it was easy to setup a loop and generate all 2048 rules. These are a few of the interesting results starting from a single centered alive cell. I have included a low res and high detail version of each rule.

Rule 313

Rule 366

Rule 384

Rule 494

Rule 798

Rule 995

Rule 1069

Rule 1072

Rule 1437

Rule 1438

Rule 1623

Rule 1822

Rule 2019

Extending the neighborhood

Once I went through those 2048 possibilities I extended the neighborhood 1 cell either side. So a total of 14 neighbor cells to check. This bumps the total possible rules up to 32768. I called these ones the “Two Steps Back Extended Cellular Automata”.

Extended Results

Again I kicked off a batch run and waited for the 32,768 results to render. Here are some of the more interesting results.

This new form of Cellular Automata (at least they are new to me) came from a Tumblr post from Neil Makes Games (@NKnauth on Twitter). His post refers to @LorenSchmidt on Twitter, but I could not find the original post. There is enough info in Neil’s post to let me implement and experiment with these CAs.

Due to lack of a name and because I made some changes to the implementation I called them “Indexed Totalistic Cellular Automata”. The rule is totalistic in that it uses the total counts of neighbor cells to determine the new cell state, and the state counts act as an index into the rule array.

Define the rule

The rule for these CAs are based on a 2D rule table like the following.

The table is mapped to a 9×9 2D rule array of integers. That covers all possible state 1 and state 2 cell counts. There is no “fade out” or “die off” period where cells that “die” go into a semi-dead state before fully dying. All cell updates are based solely on the rule table.

Filling the grid array

The original used values between 1 and 3 to fill the grid. I use between 0 and 3. The different results of including and excluding the 0 are outlined below.

Processing the grid each step

Count the state 1 and state 2 cells in the immediate 8 cell Moore Neighborhood.

Use the state 1 and state 2 counts as an index into the rule array, ie result=rule[state1count,state2count]

If the result is 3 then the cell remains the same. If the result is 1 or 2 then the cell becomes 1 or 2. In the original CA there is no state 0 in the rule array, but I added it in so that if the result is 0 the cell becomes empty.

Results

From an initial experiment with these I have seen some interesting results. Click the following images to see an animated gif of the CAs.

There are many unique gliders.

And this fireworks doily like display

Extending the neighborhood size

I also played with extending the Moore Neighborhood to all cells within 2 grid distances (total of 24 possible neighbors).

The extended neighborhood tends to give more blobbly amoeba results. Although I have only started to experiment with these CAs so more unique outcomes should hopefully pop up in the future.

Extending to three dimensions

I did some tests with extending into 3D. 26 neighbors per cell. No results worth posting yet. I will update if I find any interesting results in 3D.

Availability

These new CAs are now included with Visions of Chaos. If you do find any new interesting rules, let me know.

I have played with 3D strange attractors in the past (see here and here). Those attractors were formed by plotting millions of points in 3D space.

The points plotted will seem to jump around randomly at first, but after a few million or so points they do start to form the attractor shapes.

The attractors in this post are slightly different. The attractor formula is still iterated in the same way, but in these attractors the points form a series of points along a curve. This curve can be plotted as a line in 3D space. I couldn’t find an official term difference between the attractors plotted by points vs the attractors plotted by lines. If there is one, let me know.

I had to have a go at adding these to Visions of Chaos as a new mode, so off I went.

The attractor formulas involved are fairly simple and the source code for each type really helped me get the attractor math going quickly. In the end I implemented 60 of the attractors on Jürgen’s page.

Displaying the attractors

If you use one of the attractor formulas you will end up with a long list of points in 3D space that need to be displayed.

I used a series of OpenGL cylinders between the points. This is OK but really doesn’t work as you have breaks where the cylinders do not join each other correctly. I need to implement some code to extrude a circle or other shapes along a curve when I get some time, but unless you look very closely at the following movie you won’t notice the breaks.

I have also added a 3D Strange Attractors album to my flickr gallery. If you have a pair of the old anaglyph red and blue glasses you can also see some anaglyph images of the attractors in this gallery.

Some quick programmer tips

If you work from Jürgen Meier’s excellent reference you may (or at least I did) notice some of the attractors do not plot the same as his. The cause of this is most likely (other than a typo in parameters) will be the delta value. The delta is that “small amount” that each iteration of the attractor is multiplied by to stop it “blowing up” and having all the points escape to infinity. If you notice your plot exploding lower the delta by a factor of ten and try again. Similarly some delta values seem too small so the plot takes a long time. Increasing delta will speed up the plot. You just need to tweak the delta until you get that sweet spot between accuracy and speed.

Another point to mention. When you calculate any strange attractor (this applies for 2D and 3D when using points or lines) you need to skip plotting the first thousand points. This allows the attractor to “settle” into the attractor’s basin. Otherwise you get a line or points that are not part of the attractor. An example is this image

That little squiggly tail at the bottom is where the plot started and is not part of the attractor.

Once you have the attractor points they will all tend to fall within different XYZ coordinate ranges. Scaling them all into a fixed range (in my case I used -0.5 to +0.5) allows them all to be centered on the screen when rendering and allows them to be easily shaded by converting XZY to RGB. All it took was a bit of whiteboard scribbling and I had nicely centered attractors.