Generative visual interaction
Real-time particle interaction
A reactive particle field running as a GPU simulation, where the whole engineering problem is holding hundreds of thousands of points at a stable frame rate.
Interface built in code for this case study — not a client screen capture.
01Business problem
A visual piece that has to feel alive and respond to the person looking at it, which rules out video and rules out most of what a canvas library can do.
Who feels it
Pre-rendered video is the cheap answer to "make it feel alive", and it is immediately identifiable as one. It plays the same way for everybody, it does not respond, and on a phone it is a large download that starts before anyone has decided whether they care.
The alternative most people reach for is a canvas particle library driving a few thousand points from JavaScript. That works, and it caps out early: the position update for every particle runs on the main thread, so the frame rate falls linearly with the particle count, and a few thousand points does not read as a field. It reads as dots.
The interesting count starts around a hundred thousand, and at that point the per-frame arithmetic has to leave the CPU entirely. That is a different kind of build — the simulation state lives on the GPU, the main thread only sends the pointer position, and every decision afterwards is bounded by texture memory and fill rate instead of by JavaScript speed.
02Product overview
Simulation state stored in floating-point textures and advanced entirely on the GPU, with the CPU doing nothing per frame except handing over the pointer.
Engineering notes
Positions and velocities live in textures, not in arrays. Each frame, a fragment shader reads the current state, applies the forces, and writes the next state into a second pair of textures, which are then swapped. The particle count becomes a texture dimension, so going from ten thousand points to two hundred thousand is a resolution change and not a rewrite, and the main thread cost stays flat either way.
Rendering the result uses a single instanced draw call. Every point reads its own position from the state texture in the vertex shader, so there is one geometry upload for the whole field and no per-particle work in JavaScript at any stage.
The forces are deliberately few: a gentle curl noise field for ambient drift, an attraction toward each point’s home position so the field recovers its shape, and a radial force at the pointer. Three forces was not the starting point — earlier versions had six, and the motion read as busy, not alive. Taking forces away improved it; adding more was the instinct I had to argue myself out of.
The additive glow is where the frame budget actually goes. Overlapping translucent points cost fill rate, not arithmetic, so the cost scales with screen area and not with particle count. That meant a resolution ceiling on high-density displays: the simulation renders below native and upscales, which is invisible on a soft glow and is the single change that made it viable on a phone.
Reduced motion is handled by rendering one settled frame of the field; the piece is never removed. The composition is intact and static. Someone who asked not to be moved gets the image, not an empty container.
03Key features
8 capabilities, described by what they let someone do rather than by the technology underneath.
Positions and velocities live in floating-point textures, advanced by a shader and swapped each frame. The particle count is a texture dimension, so scaling it costs nothing on the main thread.
Every point reads its position from the state texture in the vertex shader. There is no per-particle JavaScript at any point in the frame.
Ambient curl noise, attraction to a home position, and a radial force at the pointer. Earlier versions had twice as many and the motion read as noise.
The field is displaced around the pointer and settles back over roughly a second. Without that recovery it would read as a mask following the cursor.
The simulation renders below native resolution and upscales. Imperceptible on a soft additive glow, and the difference between running and not running on a phone.
Sustained slow frames reduce particle count and resolution in steps; the piece never drops to a static image. Degradation is gradual and does not oscillate.
One resolved frame of the field, static. The preference removes the motion, not the composition.
The loop stops when the canvas leaves the viewport or the tab is hidden. A background simulation draining a battery is a bug regardless of how it looks.
04Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Home positions generated once into a texture. Every particle keeps its origin, so the field can recover a recognisable shape after being disturbed.
A fragment shader reads current position and velocity, applies the three forces, and writes to the back buffer. Textures swap; nothing is read back to the CPU.
One instanced draw call. The vertex shader samples the state texture for each instance and the fragment shader applies the additive falloff.
Additive blending at reduced resolution, upscaled. Fill rate is the binding constraint here, not arithmetic.
Frame time sampled over a rolling window. Sustained overruns step quality down; sustained headroom steps it back up, with hysteresis so it cannot flip between levels.
Layers
Why it is shaped this way
05Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
It moves the per-frame arithmetic off the main thread entirely and makes the particle count a resolution parameter. A CPU implementation caps out roughly two orders of magnitude lower.
Trade-off
Debugging is genuinely harder — the state is only inspectable by rendering it — and it depends on float texture support, which needs a capability check and a path for devices without it.
Why
On a soft additive glow the difference is imperceptible, and fill rate at native resolution on a high-density phone display is what makes the piece unrunnable.
Trade-off
Any sharp element in the same canvas would be visibly soft, so this composition cannot carry crisp detail. That was accepted before the visual direction was settled, not after.
Why
A weaker version of the piece is much better than an abrupt fallback, and it keeps the site coherent on a wide range of hardware.
Trade-off
The lowest quality level is noticeably thinner than the intended look. Worth checking that it still reads as deliberate, which took a couple of passes.
Why
More forces produced more motion and less legible motion. Cutting to three made the field read as a coherent substance.
Trade-off
Less variety over time, so a visitor who watches for a minute has seen the range of it. Acceptable for a piece nobody watches for a minute.
06Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Measured passes separately and found the cost in the blend, not the simulation. Introduced a render-scale factor and tuned it against the display density.
Outcome
A stable frame rate at the full particle count. I had spent time optimising the simulation shader, which was never the bottleneck.
Approach
Added velocity-dependent displacement and a slow return toward home positions, so the field carries momentum and recovers gradually instead of snapping back.
Outcome
The interaction reads as physical. The recovery time matters more than the displacement strength, which was the opposite of my initial assumption.
Approach
Widened the measurement window and separated the step-down and step-up thresholds so a device cannot satisfy both.
Outcome
Quality settles at a level and stays there. Visible switching had been worse than simply running at the lower setting.
07Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
08Interface
Built as a coded interface for this write-up rather than a screen capture, so it stays sharp at any zoom and no client content is republished.
Simulation pipeline
State textures, the swap each frame, and where the pointer uniform enters.
Forces
The three that survived, with the weight each one carries.
Quality ladder
The levels, their thresholds, and the gap between stepping down and stepping back up.
Render scale
Why the lever is screen area rather than particle count.
A diagram I drew from the implementation, showing the components that exist and how they call each other. It is evidence of how the system is put together. It is not a capture of a running system, and it does not by itself establish that the system shipped or was used by anyone.
09Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
10Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.