Cellular automata on 3D diagonal mesh - help needed

[ilyak]

I can see that 3D cellular automata are unpopular because they're hard to visualize and hard to reason about given massive number of neighbors the cell has.

I figured a way: let's only have cells connected diagonally to each other. Cell only exists if its (x, y, z) coordinates are all even or all odd. Thus, a cell (2, 2, 2) is connected to eight cells: (1, 1, 1), (3, 1, 1), ... (3, 3, 3). Eight cells should allow for life-like rules but with interesting twist.

Plus, you can actually see what's happening because of "holes" in the mesh. It looks like this (UPDATED):

(Yellow is cell; red is its neigbors; white space between them doesn't exist topologically; I use openscad to visualize)

I've wrote some code: https://github.com/alamar/kife

But I have this problem. If my rule includes B2, it grows explosively. If it only has B3, it stabilizes fast. It's not that it can't escape bounding box, it never wants to :-/

Suggestions welcome on rules (or even mechanisms) for chaotic cellular automata in that setting. For experiments, you can check out sources and edit them a bit

[ilyak]

To stir up excitement a bit: oscillator from soup.

[ilyak]

Whoops! I was very stupid, and my ugly oscillator2 turned to be a really beautiful oscillator4 (don't ask... and previous pic is incorrect either)



I think that it alone should persuade you to look into 3D mesh cellular automata.

[Scorbie]

I do not have access to a computer for a few days, so I won't be able to experiment with your program for a while, bur your idea looks interesting. Here are some (not-interrelated) comments...

1)

But I have this problem. If my rule includes B2, it grows explosively. If it only has B3, it stabilizes fast. It's not that it can't escape bounding box, it never wants to :-/

Hmm... Have you tried B34? Or B345678? Or B3.../S1234...? Playing with some birth counts **may** make the rule more fun...

2)
Your oscillators are visualized well(and kina cool to watch), but the "mesh" thing in the first post is still kinda hard to visualize, in my opinion. Is it better with other angles?

3) how can I compile (or execute) the source? With javac? Do I need other dependencies to run the program?

4) Just don't feel disappointed even if there aren't as much attention as you expected... Most people concentrate on their own interests... (I think I saw a post that said the same thing before...)

[ilyak]

Thank you for response!

To execute program, you need Maven and jdk7.
If you're on Linux, they're installable from your package manager. On OS X, I don't know. On windows, there are probably ways.

Then, just execute
mvn compile
mvn exec:java

Then you need openscad, preferably newer one, from their site. Try examples from lifes/ directory, and create your own from dumps that mvn exec:java produces. For something more advanced, I guess you'll have to edit sources for now :-/

Regarding the mesh:

Yellow is cell. Red are its neighbors. There's just 8 of them for every cell. White space between them is not cells, topologically it doesn't exist.

WRT rules, B34567 doesn't seem to help, I'll experiment with non-orthogonal rules now.

[Scorbie]

Regarding the mesh:

Yellow is cell. Red are its neighbors. There's just 8 of them for every cell. White space between them is not cells, topologically it doesn't exist.

Yep. I got that before:) What I tried to say was: In The picture in your first post, I wasn't able to locate those boxes. In your other pictures (oscillators), I was able to locate them and draw them in my head. So I wondered if it was a matter of angle/colors/etc or maybe the lump in the first post was just too hard to visualize. Pardon my English explanation. Not good at English nor explanation.
If anything is not clear, feel free to postreply.

WRT rules, B34567 doesn't seem to help, I'll experiment with non-orthogonal rules now.

Maybe you could loosen the surviving conditions, like s1234567, but I guess you already tried that.

[ilyak]

I've figured out the limitation - mesh cells are limited by cube, but it's not coordinate cube rather it's diagonal cube.



As you can see, red cells can only become populated if rules have B0,1,2. B3 never cuts it since they can only touch this surface with two neighbors.
Naturally, any initial pattern is confined by such surfaces.

And here is the confining space:

I bet it has some cool greek name.

And B2 is very explosive always, I've tried quite a few additional rules - nope. It either explodes or stays inside

So I'm really in the need of brain storm.

[BlinkerSpawn]

You may have to resort to either a non-totalistic rule or some properly engineered multistate rule (e.g. similar to B1x2/S23V) to get the complexity you want, and both of those options are going to make the code for the required applet a lot more complex (and definitely slower).

[ilyak]

Thank you, I'll definitely try B2x2.

I've already tried a number of ways:
Allow opposite corners to populate cell.
Allow diagonal corners to populate cell.
Allow three diagonal cells to populate middle cell's neighborhood.
Sadly, they all universally explode quadratically.

Speed and complexity are not much of a concern so if you happen to know more ideas, I'll be happy to try.

[Sphenocorona]

The shape those cubes are filling is a rhombic dodecahedron.

I've previously had thoughts about 3D cellular automata with distance 1 neighborhoods other than the von Neumann and Moore neighborhoods - ones missing only the corners, ones missing only the edges, and ones only missing their von Neumann neighbors might also be worth investigating.

There is Generations, where each cell cannot be repopulated for a certain amount of time after it dies, which could also possibly tame the rule.

[Tropylium]

This neighborhood seems to have a similar problem as range-1 von Neumann neighborhoods: the minimal birth condition necessary for patterns to escape their bounding box (or, in this case, bounding dodecahedron) is also sufficient for lightspeed expansion. I.e. if two adjacent corners of a cube will suffice for birth, then we get the following runaway engine:

Code: Select all

o . .   - . .   - o .   - - .
 . .  >  ʘ .  >  - .  >  - ʘ
o . .   - . .   - o .   - - .

(Here one plane is pictured; "o" are cells in this plane; "ʘ" is one cell above & one cell below the plane; periods are empty cells that can be populated either on this plane or directly above & below; dashes are cells of unspecified population)

Or, conflating the time and z-axes, head-on the approaching "nose" of an explosion would look as follows:

Code: Select all

 .     o     .
o o > . . > o o
 .     o     .

---

A 12-cell neighborhood where only cubes meeting edgewise "exist" might work slightly better, I suspect. Working with this neighborhood, a bounding octahedron can be escaped already with B3; but this will not necessarily lead to an explosion.