** MANY more examples in the Gallery (in the blog post cited above)
Rules can use topological properties of cells and neighborhoods, such as number of connections, neighbor degree, and other metrics.
The added topological dimension enables rules that can have more interesting behavior than traditional "cells-only" CA rules, opening up a fascinating new computational world of new species of stable patterns - oscillators - gliders, puffers, and more.
For details on how these rules work, get the repo and open various rules in the rule editor, where all their parameters are explained. There are many new classes of rules to experiment with.
This is really cool, I wish they explained what the rules were; for example, the "Amazing Dragons" seems to self-organize very neatly, but I'm not really sure why it has that behavior.
This is pretty cool. I have several points to make.
1. We all know that Cellular automata or more generally any dynamical system of sufficient complexity (and maybe not too much complexity) will be Turing complete, will have complicated "uncomputable" behavior, will have perhaps pattern formation, or gliders, solitons etc.
So what is a valuable addition to this these computational investigations? I think when studying emergent computational behavior we really care about dynamics complexity / rules complexity. It's not impressive to get complicated dynamics out of a complicated system but the simplicity of game of life made it really impressive.
I think in that regard LACE is pretty nice: the rule still feels very simple/natural and you can get much more structured/complex behavior with fewer cells.
2. Nevertheless in the end this blog shows mostly pretty pictures of computational, complex, emergent, chaotic behavior, which we've all seen before. And the key features that make the difference go something I would call physics-like are still missing.
And I guess that would be complex stable patterns that can have complex stable interactions. Who knows maybe there are 10^16-celled patterns that have this but we don't know.
3. If I were you I would cut the whole preamble. It will make people take you less seriously than they should. You don't want to look like a crank.
So what actually is it? None of the rules in the videos look particularly striking compared to other Life-like cellular automata and 2d cellular automata in general. As you say, their behaviour includes oscillators, spaceships, patterns that grow endlessly... all things that are well-known from other cellular automata. So the videos didn't really show off why they're interesting.
I don't mind the rambling about "planets, galaxies, galaxy clusters, superclusters… and beyond …." but some technical detail would be nice too!
Have they proven their computational model is inequivalent to cellular automata? It is possible that the link rules could be translated into cell rules in regular cellular automata.
That said a different representation can always reveal new phenomena about an old model.
Depending what domain of cellular automata you're talking about this might be trivial -- just redefine the state space of the cell to also include which cells it is connected to, then all that information is available to use in update rules.
Can you make a deep CA such that layer 1 evolves the rules itself that apply to layer 2? Visualize the outputs of layer 1 and 2 in tandem then. Following this, apply this update logic to n layers. There are some papers on this that exist that can LLM can help find.
How is this different from a CA with dynamic neighbourhoods? Other than the visualisation of course. It appears at first read to be isomorphic to what's shown, unless I'm overlooking something (quite possible I am). CA with neighbourhoods dependent on cell states and/or agents were what made later versions of SimCity etc work.
I was working on GACA with dynamic neighbourhoods in 1997.
The difference is that it is not merely using dynamic neighborhoods - it's using topological properties of neighbors and neighborhoods as metrics that rules use. For example, sum of degrees of neighbors, or betweenness, or other measures of networks. It's not, for example, simply using the links as virtual neighborhoods and modulating states over them.
Hard to tell what is actually novel here compared to the game of life. There are ways to demonstrate these differences, if they exist. For example, by showing how these links rules modify simple game of life setups, like gliders or oscillators.
As far as I can tell, this isn't adding any meaningful topology. The various notions of graph-connectedness basically amount to a standard finite-state CA with a slightly complex update rule.
The per-cell update mechanism, using "amazing dragons" as an example:
1. Calculate a metric for every cell based on its neighbours
eg: metric = sum(1/degree if degree > 0)
2. Calculate whether each cell is eligible based on its metric
Since the "edges" just represent eligibility of neighbours, which depends on their neighbours, you can replace them with a larger neighbourhood (ie 5x5 instead of 3x3). And since state is just degree or 0, you effectively have 1 more state than degrees.
You're right that Realm of Lace edges are derived from node eligibility, making it theoretically equivalent to a complex multi-state CA. I've updated the documentation to reflect this honestly.
However, your Shadertoy port doesn't produce equivalent behavior to the original rule—I've tried several corrections in your shader and none match.
While you've demonstrated the theoretical point, this actually highlights why the abstraction matters: implementing these dynamics correctly is non-trivial even when the algorithm seems straightforward. The three-phase execution, metric calculations, and mutual eligibility create subtle interactions that are easy to get wrong.
Why the shader port doesn't work:
I've successfully implemented this same rule in Taichi (also GPU-based), and comparing the two reveals the issue.
The three-phase execution model requires intermediate storage between phases that Shadertoy's ping-pong buffer architecture can't provide.
In my Taichi implementation, each phase has its own buffer:
- Phase 1 reads node_degree (previous state) and writes to node_next_eligible
- Phase 2 reads node_next_eligible and writes to node_next_degree
- Phase 3 reads node_next_degree and writes back to node_degree
Shadertoy only has two buffers (previous frame read-only, current frame write-only), so the shader tries to collapse all three phases into one pass. But this breaks the execution model: when Phase 2 checks if a neighbor is eligible, it needs the neighbor's just-computed eligibility from Phase 1 of the current step, not the previous frame's data.
To properly implement this in a shader, you'd need either:
- A multi-pass setup with three separate render passes and intermediate textures
- Clever state packing to encode multiple values (eligibility + degree) in one buffer
The fact that the algorithm works correctly in Taichi but requires careful buffer management even on GPU demonstrates that "theoretical equivalence to traditional CA" doesn't mean "trivial to implement."
The three-phase execution model with intermediate states is a real architectural requirement, not just an abstraction.
Regarding edge rule tables: LACE has complete UI infrastructure for true edge-to-edge dynamics (edge states evolving based on connection patterns, independent of node eligibility).
The Rule Editor even has a full tab for it (which appears if a rule implements rule tables). But no rule implements the execution logic yet—it's a dormant feature that would provide the dynamic topology you're suggesting.
Thanks for pushing me to be more precise about all this though :)
20 comments
[ 332 ms ] story [ 1943 ms ] thread(written in python, with optional taichi GPU-powered mode for large-scale simulations)
LACE is a new kind of cellular automata where rules operate on cell states and their links to other cells.
Check out the Gallery in https://www.novaspivack.com/science/introducing-lace-a-new-k... to see the familiar Game of Life rule, but with links.
* Quick Examples **
Game of Life, with links: https://videopress.com/v/lTZ8e4hD
Amazing Dragons (LACE rules): https://videopress.com/v/lQ5Bghsj
** MANY more examples in the Gallery (in the blog post cited above)
Rules can use topological properties of cells and neighborhoods, such as number of connections, neighbor degree, and other metrics.
The added topological dimension enables rules that can have more interesting behavior than traditional "cells-only" CA rules, opening up a fascinating new computational world of new species of stable patterns - oscillators - gliders, puffers, and more.
For details on how these rules work, get the repo and open various rules in the rule editor, where all their parameters are explained. There are many new classes of rules to experiment with.
** You can get the repo and learn more at: https://github.com/novaspivack/lace
How might you increase the overall order and decrease the chaos?
2. Nevertheless in the end this blog shows mostly pretty pictures of computational, complex, emergent, chaotic behavior, which we've all seen before. And the key features that make the difference go something I would call physics-like are still missing. And I guess that would be complex stable patterns that can have complex stable interactions. Who knows maybe there are 10^16-celled patterns that have this but we don't know.
3. If I were you I would cut the whole preamble. It will make people take you less seriously than they should. You don't want to look like a crank.
I don't mind the rambling about "planets, galaxies, galaxy clusters, superclusters… and beyond …." but some technical detail would be nice too!
Although I guess if we play with this too much there is a risk of inventing something like… Bloch's Game of Life or something.
That said a different representation can always reveal new phenomena about an old model.
I was working on GACA with dynamic neighbourhoods in 1997.
The per-cell update mechanism, using "amazing dragons" as an example:
1. Calculate a metric for every cell based on its neighbours
2. Calculate whether each cell is eligible based on its metric 3. Calculate new state based on degree (degree = eligible ? number of eligible neighbours : 0) Since the "edges" just represent eligibility of neighbours, which depends on their neighbours, you can replace them with a larger neighbourhood (ie 5x5 instead of 3x3). And since state is just degree or 0, you effectively have 1 more state than degrees.Here's an example of that approach: https://www.shadertoy.com/view/wXSyRw
I think for this to live up to the name it would need one or both of the following:
1. edges that mask or gate cells in some way (ie a dynamic neighbourhood) 2. rules that turn edges into other edges without going via cell states
However, your Shadertoy port doesn't produce equivalent behavior to the original rule—I've tried several corrections in your shader and none match.
While you've demonstrated the theoretical point, this actually highlights why the abstraction matters: implementing these dynamics correctly is non-trivial even when the algorithm seems straightforward. The three-phase execution, metric calculations, and mutual eligibility create subtle interactions that are easy to get wrong.
Why the shader port doesn't work:
I've successfully implemented this same rule in Taichi (also GPU-based), and comparing the two reveals the issue.
The three-phase execution model requires intermediate storage between phases that Shadertoy's ping-pong buffer architecture can't provide.
In my Taichi implementation, each phase has its own buffer:
- Phase 1 reads node_degree (previous state) and writes to node_next_eligible
- Phase 2 reads node_next_eligible and writes to node_next_degree
- Phase 3 reads node_next_degree and writes back to node_degree
Shadertoy only has two buffers (previous frame read-only, current frame write-only), so the shader tries to collapse all three phases into one pass. But this breaks the execution model: when Phase 2 checks if a neighbor is eligible, it needs the neighbor's just-computed eligibility from Phase 1 of the current step, not the previous frame's data.
To properly implement this in a shader, you'd need either:
- A multi-pass setup with three separate render passes and intermediate textures
- Clever state packing to encode multiple values (eligibility + degree) in one buffer
The fact that the algorithm works correctly in Taichi but requires careful buffer management even on GPU demonstrates that "theoretical equivalence to traditional CA" doesn't mean "trivial to implement."
The three-phase execution model with intermediate states is a real architectural requirement, not just an abstraction.
Regarding edge rule tables: LACE has complete UI infrastructure for true edge-to-edge dynamics (edge states evolving based on connection patterns, independent of node eligibility).
The Rule Editor even has a full tab for it (which appears if a rule implements rule tables). But no rule implements the execution logic yet—it's a dormant feature that would provide the dynamic topology you're suggesting.
Thanks for pushing me to be more precise about all this though :)