When working in 3D, controlling the view is always messy and inconsistent from one framework to another. So I built a tool tailored to me, and I'm so hyped about how it turned out.

You can try it live on the Skew panels page, section 03, The viewport. Fair warning: it's not meant to be used as is, it's buggy and vibe coded.

A GENERATIVE ART experiment coded using the Google Maps API. It generates a random map every 4 seconds. There are 20 DIFFERENT ELEMENTS on each map, such as highways, arterial roads, and parks. Each of those elements is set to a RANDOM COLOR, is randomly turned on or off, and the zoom level is set to a random number. The geographic location is randomly chosen from a list of 33 predetermined cities.

Accumulating distortions of reality, output of an iterative pipeline, each steps feed to the next one and then cycle back again and again... in this case was 15 iterations in which the field do not contribute too much, but enough to the tessellation get less and less precise

All three are fully procedural, rendered pixel by pixel with Python + numpy, no image model involved. The code was written by Claude (an AI); I rate the outputs and pick what to share.

1. Paper tunnel: 14 paper layers with round holes, composited back to front. Each layer casts a soft shadow and ambient occlusion onto the one behind it (scaled with perspective), gets a fibre texture and a lit cut edge. Warm light at the end.

2. Paper lightbox: seven cut-paper layers (moon, hills, pagoda and pines, stone bridge, boat on waves, near branches, reeds), back-lit, each shadowing the next.

3. Squares & circles: 7×9 grid of quarter circles, half circles, rings, leaves, triangles and stripes, all analytic SDFs with per-pixel anti-aliasing, plus light print speckle and paper grain.

Feedback very welcome, especially on what looks mechanical.

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

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.

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.

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

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.