Jeff’s MergLife page also has more info and examples you can run online.

MergeLife is now included with Visions of Chaos. I haven’t added the genetic mutations yet, but you can repeatedly click the random and mutate buttons and see what new patterns emerge.

Jason.

]]>If you look at some online definitions of CAs you will see explanations like this and this. You can try and understand them, but probably be still left confused.

__1D Cellular Automata__

OK, let’s start at the simplest form of cellular automata, the one dimensional cellular automata.

A one dimensional CA consists of a line of row of cells. Each cell can be alive (on) or dead (off).

The first row of the image above is how this cellular automaton begins. It has 1 single centered alive (black) cell surrounded by dead (white) cells.

__1D CA Rules__

Cellular automata change states and evolve based on simple rules. The rules apply to every cell in the CA at the same time each step.

For the above image, the rules are as follows;

This shows the 8 possible rules for this CA. Each new cell state depends on itself and it’s 2 neighbors in the previous state.

The first rule (with the 3 black squares above a single white square) means that if the current cell and its two neighbors are black that cell will become a white cell the next step of the CA.

The second rule means that if a cell and its left neighbor are black but its right neighbor is white, the cell will be white in the next step.

The rest of the 6 rules are the same principal and cover all possible combinations of white and black cells.

You apply these rules to every cell in the CA each step. Here is a nice animation courtesy of Wikipedia showing how the rules are applied to a row of cells and the next step of the CA resulting from the rules.

Once the rules have been applied to all the cells, that step is completed. For 1D CA the easiest way to display them is to show each of the steps under the last in a 2D grid. The first 15 steps are shown in the grid above.

__1D CA Rule Numbers__

Looking again at the rule for this CA

you will notice that there are a series of 1’s and 0’s under the rules. 0 for if the rule creates a dead (white) cell and 1 if the rule creates an alive (black) cell. This series of 1’s and 0’s can be converted into a binary string that can then be converted into a number. For 8 digit binary numbers the numbers will range from 0 (for 00000000) to 255 (for 11111111).

These 1D CA’s have 256 possible combinations of rules. Rule 30 (shown above) is the conversion of 00011110 binary into digital 30. Being able to refer to each rule as a single number makes it easier to state which rule you are talking about.

__More steps__

If you follow the above rule repeatedly for more steps it evolves like this

From such simple rules some interesting structures arise within in. This specific rule has been used to generate random numbers (you can keep track of the center pixel going down the image and use it to create random numbers). You can see more info about Rule 30 here.

So what about the other 255 1D CA rules?

You can see the results of all 256 rules here.

An interesting result is rule 22.

Rule 22 results in a structure of triangles within triangles. This is a famous fractal pattern called the Sierpinski Triangle and it tends to pop up all over the place in cellular automata and fractals.

__The End – for now__

Hopefully by now you have a basic understanding of cellular automata. The main points to know are;

1. CAs are based on a grid of cells that are alive or dead.

2. The CA runs/updates/steps by running a set of rules on all the cells at the same time.

3. The same rules are then applied to the new cells and the process repeats itself.

The one dimensional cellular automata are kind of bland and once you seen the possible 256 rules there isn’t much excitement, but understanding 1D first makes the transition into higher dimensions and more complex rules easier to grasp.

If you want to experiment with these 1D CAs yourself, you can download Visions of Chaos. Open the 1D CA mode dialog and suddenly the options should be more clear to you now.

There is even an option that takes the CA steps and maps them into music. You can also print a catalog of all the 256 rules with more details.

If any of the above is not clear, please comment and let me know.

Jason.

]]>The Mandelbrot Foam formula was from this forum post.

Shaders to create these fractals are now included in the Custom Formula Editor mode of Visions of Chaos.

Jason.

]]>Jeffrey Ventrella explains his Clusters here.

Here is another particle based life model

I learned about Clusters when Code Parade posted the following video explaining his version of Clusters he calls Particle Life.

The source code to Particle Life was generously shared here so I had a go at converting the code and playing with these myself.

__Results__

Here are some of my results.

__Extension Into 3D__

Once I had the 2D version working, extending into 3D was the next step. These movie parts use the same settings as in the 2D movie above.

__Availability__

Both the 2D and 3D Particle Life are now included with Visions of Chaos.

Jason.

]]>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.

]]>