https://futureofcoding.org/ logo
Title
l

Lu Wilson

02/03/2023, 7:32 AM
Hi everyone I did a talk at the Peckham Digital festival yesterday! It's about spatial programming! I come in at 42:59 :) https://www.youtube.com/live/L2U_Sd1qMJ4?feature=share&t=2579
j

Jared Forsyth

02/03/2023, 8:34 PM
brilliant talk/demo! it seems like those rules work really well on the GPU (although the cell splitting would take some gymnastics) -- is that what you're doing / have you tried that?
l

Lu Wilson

02/03/2023, 11:04 PM
Thank you very much! Yes I reckon there's some scope to run them on the GPU, but it might be harder than expected. So, just for context - the engine's main bottleneck currently is rendering, because it's just using javascript canvas. The renderer could be sped up loads by using webgl instead, and then the bottleneck would become the computation behind it. At that point, GPU would be a consideration! Cellular automatons are usually great for GPU optimisations, because all the classic (like game of life) involve rules where only the 'middle' of an 'event window' gets edited. Which is perfect for shaders. One of the challenges of an engine like CellPond (which stems from Dave Ackley's Moveable Feast Machine engine) is this: When a rule gets applied, it can affect any cell in the event window. This doesn't work so well with shaders. However, with the rise of GPU compute, eg: webgpu, it might become easier to leverage the GPU for this kind of thing! I need to look into it more! Another challenge is this: Most cellular automatons are deterministic. But CellPond (and the Moveable Feast Machine) are non-deterministic. So parallelising 'events' involves having to make sure that any randomly-picked locations don't overlap with each other. You can't just get away with a classic block cellular automata approach. I did manage to do a dodgy solution to that once on the GPU with this experiment though. And I made two videos about it: 1.

The initial idea of using GPU to speed up one of these engines

. 2.

Taking the idea to its logical conclusion

. Big answer but it's an interesting topic, thanks for asking :)
j

Jared Forsyth

02/04/2023, 1:05 PM
Oh fascinating, thanks for the details response! So these nondeterministic event windows; do they pick a single rule to evaluate at random? Or do they evaluate all available rules? And is it critical that the window be a fixed size, or could it adapt to the size of the largest rule?
(I see movable feast has some papers written,I can just go read those as well)
In the London creative coding video, say at one point that cell splitting was a big leap forward, because it allowed you to encode direction, which was difficult before. How is it different from encoding direction as a color (blue goes up, red goes down) or pairs of colors in a non-split grid? (For that matter, I bet split grids make event windows quite complicated 😅)
l

Lu Wilson

02/04/2023, 1:58 PM
So, in CellPond, I was hoping to do this: 1. Pick a random position (within the 0.0 -> 1.0 range of x and y) 2. Apply a random rule (if it matches). However, for some performance reasons, it actually does this: 1. Pick a random position. 2. Shuffle all rules. 3. Apply the first rule that matches. The 'variable event window size' was a key new thing for the engine to do! The Moveable Feast Machine (MFM) has a fixed diamond-shaped window. SandPond has a square shaped one. CellPond needs to be flexible. The way it gets around this is... When you make a rule with the drag-and-drop interface, it actually gets compiled down into multiple rules -- one for each cell in the diagram silhouette. The classic sand rule... :large_yellow_square:➡️ ➡️:large_yellow_square: ... would produce two rules on the virtual machine. One where the top cell (yellow) is the 'center/origin' of the event window. And one where the bottom cell (black) is the origin.
Regarding the encoded direction... You certainly could encode direction as colour! And I did it a lot in

this video

! However, this isn't a very useful abstraction when it comes to writing rules. You'd need a rule for moving up, a rule for moving down, and so on. By encoding direction as a spatial relationship, we can just make one rule: Move 'forward'. Other examples of this include: Using a split cell where one cell indicates an element type, and the other cell indicates its temperature. You could make water that heats up and does something (eg: freeze/evaporate) when it hits a certain temperaure. Cold water :large_blue_square: Hot water :large_blue_square: Tepid water :large_blue_square: (grey) It's nice that it lets you 'quote' extra data in a way! We can use the black colour to mean temperature when attached with a blue cell, but it might mean different things in other places. You could use a similar thing to make the 'demon horde sort' that Dave Ackley uses to exemplify the MFM too by the way!
j

Jared Forsyth

02/04/2023, 2:10 PM
hmm yeah that's neat! I wonder how it would be to have one (or several!) "hidden" or "background" layers for metadata, and rules that could take them into account, but the fore-most layer is the one that gets rendered 🤔
l

Lu Wilson

02/04/2023, 2:11 PM
Yes that would be great to try out! I was originally planning for every cell to be controlled by its own mini 9x9 cellular automata world, and the middle cell was the only one that got rendered when zoomed out. But when I started trying it out, I got tempted by the dynamic splitting/merging idea 🙂
k

Kartik Agaram

02/04/2023, 4:41 PM
Very interesting. I had no idea how large the influence of Dave Ackley and his MFM was here.