I'm tinkering on a little <sand experiment> with <...
# devlog-together
i
I'm tinkering on a little sand experiment with @Elliot. Without dipping too far into spoilers, you have a small selection of tools you can use to fill the screen with grains of sand and then move them around, with brushes (of a sort) that each have a bit of logic (eg: scatter the sand randomly, push the sand downwards, merge sand grains together). What's fun about these brushes (of a sort) is that they apply some behaviour that feels like a computation. So you sort of brush your computation over some data (sand). One possibility I've been mulling, that I'd love to hear some ideas for, is a brush that does cellular automata. The brush might use some global grid (discrete) or sense of proximity (continuous), and apply some CA-esq rules depending on the density of the sand. Then you'd just brush that computation onto the sand to advance the state of the CA. Maybe each brush stroke advances the CA one step wherever you apply it, or maybe the CA runs continuously but only where you're brushing. The thing I'm presently brainstorming is… how might one specify the CA-esq rules just using sand and brushes?
k
I can't immediately think of anything. I assume the obvious approach is one brush per rule set, but yeah in that case how might you create a new brush? 🤔
i
Yeah exactly. Or parameterize a brush, where the relevant parameter here is, like, a graphical rewrite rule.
j
I like this space of materializing the presence or action of CA execution as paint. Like you say – imagining that each “coat” of paint you lay down advances the CA one step, or imagining that the presence of “CA paint” persistently makes a CA run in a given place – but if you can push the paint around it will make the CA run in different places? Or even continuous gradients – the CA runs “more” in some places than others? (Does that mean faster? Or that behavior is interpolated between being stationary and being CA-driven?)
i
Yes Josh, that's precisely the good shit I came here for! Full size! I've heard people say "rules should be defined in the same place they're executed", but I don't think I've seen anyone do it yet. Like, @Lu Wilson talked about something this with respect to CellPond, for insty. Rather than paddles down the left of the screen, you'd… uh… not have them there. I'm not sure about CA rules, but simple replacement rules seem do-able, perhaps. Maybe a pair of brushes that let you capture a "before" and "after" that recognize some changing qualities of the captured sand, and a brush to apply that change. I wonder if there's something about little grains of sand that might make this all more feasible. Sand is basically 1-bit graphics without the pixel grid. It's like the second most constrained kind of graphics possible, surely. Maybe some

Viewpoint

vibes here.
a
If the paint controls time, then you could keep your “before” and “after” swatches in a safe (or unsafe) corner as a persistent rule set, AgentSheets-style.
(I haven’t used CellPond 🫣, so I don’t know if that’s what paddles do.)
i
I do like the idea that the before and after are just, like, the bottom left and right corner of the screen. If you mess those up while applying the rule, welp… _like sands through the hourglass_…
e
I wonder how the before/after scheme could be adapted to free floating particles... here's a sketch off the top
l
agentsheets has the rules in a separate layer, same as cellpond. to make them happen in the same layer you need some way of "quoting" areas, lisp-style. i don't think it's that hard, it's just that no one has bothered yet
this is something that dave ackley does for his current brain project in the t2 tile work