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 :)
I've updated the shader – I think the issue was just that I was initialising the states to random values instead of running a proper degree calculation. The behaviour looked pretty similar to me either way, but now it matches exactly and I added colours to make that clear: https://imgur.com/a/4gZKlSg
Looks better... the one thing I am not seeing is the behavior where they expand in two directions at the same time - but it might be that it's too small. Also it would be better if you started from a much lower density initial condition like 15% density. Also note - while Amazing Dragons shows really interesting behavior microscopically it is not the most balanced rule - there are other variants that are sparser and have a more interesting balance (see gallery, see repo to try them out). I found density of initial conditions is very important and different rules need different densities.
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 :)