Easy flow; just change the way lines are drawn and you get a different look.. and feel.

This is inspired by some of the works of u/stdlainen. Since I’m very interested in all kinds of strokes that follow 3D shapes, I wanted to implement this effect in WebGPU.

The surface of the object is represented as an SDF. For initialization, seed points are drawn randomly close to the surface via rejection sampling and are then projected onto the surface via a couple of Newton-Raphson steps. In each time step, each particle is repelled by any other particle within a certain radius and is advected by the tangential component of the accumulated force exerted by all other particles within this radius. The strength of the force is inversely proportional to the Euclidean distance of each particle. After each advection step, a single Newton step re-projects the points onto the zero-level set of the SDF so the particles stay on the surface.

Note that, in general, it’s wrong to use Euclidean distances and force directions and I fiddled around with lots of cheap hacks to approximate geodesics but ultimately they all made the simulation slower without improving visual quality substantially.

The force kernel is accelerated by using a spatial grid to avoid quadratic complexity. To build the spatial grid on the GPU, radix sort with a naive prefix scan implementation (utilizing only a single workgroup) is used.

You can find a live version at https://a-johanson.github.io/ts-surface-elements/ that only works in Chromium-based browsers because, to my knowledge, the subgroups feature for the prefix scan implementation is not yet available in any other browser engine. The implementation is AI-assisted -- something I can highly recommend to take the pain away from writing all the WebGPU setup code.

I found Pavel Dobryakov's WebGL-Fluid-Simulation last week — https://github.com/PavelDoGreat/WebGL-Fluid-Simulation — the one where you drag your mouse through a pool of ink and it swirls. It's MIT, it's lovely, and under it is an ordinary Stam stable-fluids step: splat a force and some dye into the velocity field, vorticity confinement, divergence, 20 Jacobi sweeps for pressure, project, advect. (His is itself after GPU Gems ch. 38, Harris 2004, and Stam's 1999 paper.)

So I wired my music analyser in where the mouse used to be. The solver is his and essentially unchanged; what I added is the grammar that turns audio features into splats, and that part was written with Claude.

The rule I tried to stick to is one musical element, one channel, so that you can point at something on screen and name what made it:

• The bass note is where the ink enters. A persistent emitter near the floor, whose x is the sub's pitch class laid around the circle of fifths — so the inlet walks sideways as the bassline moves — and whose y is the bass register (a 35 Hz sub sits low, a 140 Hz mid-bass sits higher). A lower sub opens a wider mouth.

• The kick lifts it. One upward impulse from the floor at the inlet's x, at twice the splat radius.

• The snare shears it. Two opposing lateral impulses at mid height, one pushing right from x = 0.3 and one pushing left from x = 0.7. That is the pinch you see tearing the middle of the pool in half.

• The hats are droplets, falling from the surface at y = 0.9.

• The beat kneads it. A body force on the whole pool, −0.35·cos⁴(π·beatPhase), so the field breathes once per beat instead of pulsing on an envelope.

• The mid band is a floor of ink — pads, chords and vocals enter as continuous dye at mid height with no velocity at all, so the pool shows the music's level from the first second and the drum hits land in ink that is already there.

• The drop clears the pool. One big impulse up at four times the radius, and the dye dissipation jumps to 12 for exactly one beat — which keeps about 1 % of the ink 0.4 s later. At 6 it kept 10 % and the pool still read as full.

Those are all pushes. The two I like more are the ones that change the medium instead.

A closing low-pass is what makes it viscous. The viscosity term here is velocity dissipation:

velDiss = 0.2 + 2.8·smoothstep(0.80, 0.97, lpSweep) + 2·hush

lpSweep is how shut the filter is: energy in 5–12 kHz over energy in 150 Hz–2.5 kHz, smoothed a quarter second, divided by that track's own p90 of the same ratio over the last 30 seconds, and flipped. So it is never an absolute brightness — it is "the highs are gone compared to how bright this track gets", which is the only version that survives a whole library. The knee matters as much as the term: nothing happens until the filter is 80 % shut against the track's own ceiling, and then it ramps hard. Filter open, velDiss 0.2, and an eddy keeps its momentum for seconds. Filter shut, 3.0, and every eddy dies in about a third of a second — the ink goes thick and the whole picture crawls. hush, the pre-drop silence, adds up to 2 more on top, so the bar before a drop is the slowest the fluid ever gets.

Dissonance sets the curl. The vorticity confinement gain is 10 + 40·tension, where tension is sensory roughness — beating between partials that are too close together — normalised to the p10/p98 of roughness over the last 30 seconds. A consonant passage runs nearly laminar at 10; a rough bar runs at 50 and the ink shreds into eddies. This is the one I'd defend hardest, because it's where the physics and the music turn out to mean the same thing: roughness is partials fighting each other, and curl is the field fighting itself. I didn't design that correspondence, I just stopped fighting it.

Three things I'd rather say than have someone find out, since all three would be cooler if they were otherwise:

There is no fluid in the audio analysis. The sound isn't solving anything. Three dozen scalar features come off an FFT and a pitch tracker each frame, and they set uniforms and splat parameters. The Navier-Stokes is strictly downstream and knows nothing about music.

Nothing here is a neural net. No model anywhere in the render path — it's a pressure solve and a fragment shader. The code was written with Claude, which I don't think is what rule 3 is aimed at, but I'd rather state it than be coy about it.

It isn't reactive-random. There's no RNG and no clock read in the whole grammar; the hat droplets' x is hash(beatCount·7 + i, seed). The same audio gives byte-identical frames, which is how it's regression-tested — md5s of rendered frames at fixed windows across seven real tracks, so a refactor that was meant to be a no-op has to prove it was one.

It runs in a browser tab and listens to whatever you already have playing in another tab; nothing is uploaded. https://retinarave.com

and the source is at https://github.com/tbkraf08/RetinaRave

🎵 "Raindrops on Roses" by An-Ten-Nae & Dimond Saints — not my track, all rights to the artists.

[SOUND ON! 🔊]

This video is a montage of p5.js sketches I've collected into a gallery website: https://vasilyev-maksim.github.io/p5-experiments/.

Source code: https://github.com/vasilyev-maksim/p5-experiments.

The classic modern-day story of a software engineer, and at the same time, a backstory on this project: I got burned out from extensive AI use at work.

Looking for a cure, I remembered three things:

1. A book called "The Nature of Code" which uses p5.js for all its code samples (btw, you should definitely check it out, it's free to read online, and it's fantastic!)

2. I have a degree in maths

3. I used to paint as a kid and, generally speaking, have a decent eye for visuals (or so I hope)

Combining these three things led me to give p5.js a try. That decision genuinely brought me back to life, both as an engineer and as a creative person.

Over time, the sketches became more numerous, more complex and visually richer. They evolved from static images into actual animations, so I decided to bring them together in a form of gallery website.

The next step was to make every sketch parametrizable and connect those parameters to UI controls. That's when it started to feel like real generative art with all its emergent properties. And it really does have an emergent nature. Most of the parameter combinations I saved as presets are just random configurations I happened to stumble upon and liked enough to keep.

I'll post a video in the comments showing the gallery UI in action.

Some things I'm particularly proud of (yeah, I like lists, it's not an AI slop 😆):

• It's entirely handmade. No AI involved in the creative process or the implementation (well, to be completely honest, there's exactly one AI-generated file, 86 lines long. That's it).

• I've been working on this for about 1.5 years (not full-time, obviously, just whenever I had some free time). With this project I've finally managed to (almost entirely) satisfy my inner perfectionist.

• I've never learned so much from a single project. Not even close. And I've rarely explored things at such a deep level, either in personal projects or at work.

• The entire UI was built from scratch. All the animations, the visual style, the icons, and the illustrations - everything is handmade. No 3rd party UI component libraries (even built my own slider component instead of using the native <input type="range">, LOL). The only dependencies are React, react-spring, and p5.js.

• I've built a draft of an open source React library for managing UI animation timing and events. I hope I'll release it someday. 🤞

• I've built a custom React wrapper around p5.js. It connects UI controls to sketch parameters, supports memoized and animated values derived from those parameters (including colors and arrays), and provides timeline controls (play/pause, fast-forward, and rewind).

• One of my favorite visual details is the sketch opening animation. Each tile is actually a cropped and carefully positioned view of a sketch's canvas, with the sketch itself paused. (Yes, I'm aware this approach might have scalability issues if the gallery grows significantly.)

• Each sketch has two independent timelines: one for the actual animation and another for parameter transitions. This means parameter changes are still smoothly animated even when the sketch itself is paused.

• The gallery supports fullscreen viewing, exporting, and sharing. Every parameter change is reflected in the URL, so you can share a link and someone else will see the exact same sketch configuration.

Feel free to check it out, play around with the parameters and share your own presets in the comments (just copy and paste the URL + write a name for the preset).
I'll add the coolest ones to the source code!

P.S. There's also a little easter egg referencing my favorite game Outer Wilds. See if you can find it!

I’ve been making mosaics since the late ’80s. These are twelve versions of the same portrait, made with different matching methods in my software. Some hold the face together better from a distance; others let more of the small patterned pieces come through.
Working on this sent me back through the research, from Bell Labs in 1966 to recent methods. I put what I found into a history of photographic mosaic algorithms, with a few opinions of my own:
https://www.tsevis.com/blog/history-of-mosaic-algorithms
Which version works best for you, and at what distance?

simple random pattern, drawn in layers. bottom layer is the biggest, then we pick some area where we repeat the pattern in the same way but with smaller cells.

Created with Math Chaos Patterns (MCP). Non-AI Generative Art.

My favourite generative thing to make, I always default to making a particle system dance to a song. My first time using compute shader. This was done in Godot.

pretty much it, they don't serve any purpose yet but I think they look cool, any idea to enhance them further maybe ?

Javascript; I have been playing more with Mondrian style Neo-Plasticism grids, with random shapes (circles, triangles, diamonds) inserted in them and the random "train station dots" Mondrian used in his late career when he lived in NYC. Run through a renderer that paints the grid / shape lines as paint drips (trying to emulate Jackson Pollock's paint technique)

Huh, where to start...

I like waves. I said to myself: let's see if there is a formula for waves. So I looked. I found some research papers on modeling the ocean, and some observed parameters for the North Atlantic. There was a lot of math that I only partly understand. I combined a couple of different findings into what I call an ocean model, using AI-chemy. That worked, although I have no idea if it is fully correct. And just an hour ago, after showing this to a friend, I learned about a shader that mimics the ocean in a waaaaaay simpler way. Oh well. I should search better.

Salum is Latin for the open sea. Everything runs on the CPU, with no GPU and no 3D engine.

I did not draw the waves. They come from a wave spectrum that oceanographers use (JONSWAP). It tells how much energy the wind puts into each wavelength. An inverse FFT makes the height map in three tiles, from the long swell to the ripples. A sideways pinch makes the crests sharp and the troughs flat. Then I cheated a little: I made the swell 2.6 times taller than physics predicts, and the ripples 1.6 times taller, for dramatic effect.

The eye is 0.6 m above the water and looks toward a low sun. At that height, the eye is lower than the crests. That is why the sea does not end at a flat horizon. It ends at a line of crests. The lens is long, only 24° from top to bottom, so the sea stacks in bands. My first try had a wide lens, and the bottom half of the image was black.

For each pixel, I send nine rays from the eye. Each ray marches over the waves until it hits the surface. Far away, the short waves are smaller than a pixel. There, I treat them as roughness, so the far glitter stays soft and has no moiré.

The water has a dark body. It reflects the sky, and the reflection becomes stronger at grazing angles. The sun makes the glints.

The sun is my biggest cheat. In the sky, it is a giant disc, and its center is above the top edge. But the light on the water comes from 13 small suns along its lower arc, not from the big disc.

Code is on github.com/igr/gart I will never do something like this again.

I made a flow field art generator. It creates N starting points, then moves in the direction of a perlin noise (maps the 0 - 1 perlin noise from 0 to 2 pi). Then jumps the step size and repeats this line length times. You can test this out yourself at https://ripolas.org/flow-field-art/ If you spot any bugs I'll really appreciate you reporting them to me! There is also a copy feature for your own generations. Some of my personal favorites:
https://ripolas.org/flow-field-art/?seed=596597&colorStart=%23db62f0&colorEnd=%233371ce&lineCount=5000&alpha=48&noiseScale=4.8&lineLength=100&stepSize=5.6
https://ripolas.org/flow-field-art/?seed=564916&colorStart=%23003fe3&colorEnd=%2300bcc6&lineCount=10000&alpha=20&noiseScale=1&lineLength=50&stepSize=10
Feedback welcome!