u/StefanPetrick

Artistically Tuned Fluid Simulation — Hypnotic Eye Candy

A self-modulating realtime visualizer I build over the last weeks.

u/StefanPetrick — 6 days ago
▲ 37 r/esp32projects+6 crossposts

Coming soon: run FastFluid on your own LED setup

Something strange is emerging from the solver.

What started as “just some colorful smoke” slowly turned into a deep dive into numerical instability, fluid dynamics, pressure projection, divergence control and the weird art of balancing equations exactly at the edge of total chaos.

Every swirl on screen is real simulated motion.
No keyframes. No prebaked animation.
Just velocity fields, advection, pressure solves and controlled chaos.

And sometimes uncontrolled chaos.

Coming soon:

A highly stylized real-time fluid simulation system built from scratch — designed for LED visuals, generative motion and beautiful mathematical instability.

P.S. Unmute for a nice soundtrack.

P.P.S. I asked my AI crew for a little write up, what I actually did in the last weeks. Here is what they came up with, entirely based on real events:

He originally just wanted to make “some colorful smoke-like fluid motion” for LED visuals.
How hard could it possibly be?

A few days later he found himself at 6 AM still staring at several hundred megabytes of solver array dumps, trying to understand why a single velocity cell near the boundary had suddenly decided to turn the entire simulation into pixel salad.

He was naive enough to even start investigating it, and autistic enough to actually follow the problem all the way down to the point where he truly understood why the solver kept exploding.

At first everything was innocent.
A grid.
Some arrays.
A little dye.
A bit of motion.

Then came the moment he realized:
A fluid simulation is not animation at all.

It is controlled numerical instability.
Suddenly he had to learn, in depth, about:

  • divergence
  • pressure projection
  • semi-Lagrangian advection
  • Gauss-Seidel relaxation
  • incompressibility
  • timestep stability
  • floating point precision
  • why “stable fluids” are not actually stable if you keep injecting energy into the system

Very quickly he learned: if you simply move velocity through the grid, everything explodes.
So he learned projection.
Pressure fields.
Divergence removal.
And for the first time the simulation actually started looking like fluid.
First Eureka moment.

Then he implemented vorticity confinement.
And suddenly the fluid had character.
Swirls. Energy. Motion. That organic “life” inside the flowfield.

For about 30 seconds.
Then everything exploded again.

That was the next lesson: Numerical solvers rarely fail instantly.
They accumulate error slowly. Invisibly. Frame by frame.
One tiny divergence error survives projection.
Advection transports it.
Vorticity confinement amplifies it.
Pressure correction overcompensates.
Energy starts feeding back into itself.
And ten seconds later the entire simulation just explodes.

So he started building debugging tools:

  • velocity maps
  • divergence visualizers
  • pressure displays
  • vorticity heatmaps
  • energy monitors
  • instability detectors
  • statistical entropy spike detection

Not because it looked cool.
Because without them you are completely blind.

At some point he finally understood why real fluid solvers become so insanely complicated.
Because every new feature quietly destabilizes three other systems.

More swirl?
 → unstable curl amplification.
Less dissipation?
 → energy accumulation.
Larger timestep?
 → projection can’t converge fast enough.
Too few solver iterations?
 → divergence survives.
Too many iterations?
 → performance dies.
Float32 precision?
 → tiny drift accumulates forever.

And still, there were these magical moments.
Like when the three emitters interacted for the first time and suddenly formed these huge rotating structures entirely on their own. No animation. No keyframes. Just equations interacting with equations.

Or the moment he realized:
The most beautiful fluid motion exists exactly at the edge of instability.
Too stable = dead.
Too unstable = explosion.

The sweet spot in between?
That’s the actual solver.

And eventually you stop feeling like you are programming graphics.

You are dancing with differential equations.

youtube.com
u/StefanPetrick — 6 days ago
▲ 44 r/FastLED+1 crossposts

A short narrated clip showing the current development progress, along with some of the debug views I regularly use throughout the process.

Questions, feedback, ideas, feature wishes — all welcome 🙂l

u/StefanPetrick — 8 days ago
▲ 13 r/FastLED+4 crossposts

Today I made a short commented video explaining the idea behind flow maps in an artistic fluid simulation.

Think of it as an easy way to guide the direction of advection more precisely than with just global forces like gravity and wind.

Technically, it’s a scalar field that applies local forces.

Shout out to u/gokily for bringing this to my attention!

u/StefanPetrick — 9 days ago
▲ 15 r/WLED+1 crossposts

This is my progress on writing a real-time numerical solver that will run on a 240 MHz microcontroller to drive LEDs in the future.

u/StefanPetrick — 10 days ago
▲ 250 r/computergraphics+2 crossposts

The learning curve is wild when collaborating with a bunch of AI instances.

I didn’t sleep for too long, but what I’ve learned about simulation approaches in the last few days blows my mind.

I started 2 months ago with simply applying a procedurally generated (Perlin noise) advection field.

Then I figured out how to actually simulate the advection based on a Newtonian fluid.

And now… I’ve started to simulate fire. For now, only a few of its properties, to get familiar with the architecture of a complex simulation pipeline.

I’m simulating a coupled system of flow, heat, and smoke.

the flow moves heat and smoke

the heat creates flow

cooling heat creates smoke

the renderer maps those fields into a flame appearance

It works as follows:

This simulation uses a visually driven coupled field model on a fixed 64x64 grid.

What is stored per cell:

u, v: the two components of the velocity field

temperature: how hot that cell is

smoke: how much smoke / density is in that cell

What happens each step:

The source injects new temperature, smoke, and upward momentum near the bottom. (source term / forcing)

Gravity and especially Buoyancy modify the velocity field. Hotter cells get extra upward force. (buoyancy force model)

The velocity field is diffused, projected, and advected. This is the classic incompressible fluid core: smooth it, enforce near zero divergence, then move the flow through itself. (Eulerian incompressible fluid solver / Stable Fluids style)

temperature and smoke are transported by that velocity field. So heat and smoke get carried by the flow. (semi-Lagrangian advection on an Eulerian grid)

temperature cools down over time. (simple exponential decay / cooling model)

Part of that lost heat is converted into new smoke. This is an important feedback loop: hot flame gradually produces smoke as it cools. (heuristic reaction / transfer model)

Vorticity confinement artificially boosts small vortices so the flow does not become too smooth and dead-looking. (vorticity confinement)

The key feedback loop:

more temperature creates more buoyancy

more buoyancy changes the velocity field

the velocity field transports temperature and smoke

temperature cools and generates smoke

smoke changes the visible shape and softness of the flame in rendering

vortices in the velocity field tear and fold the heat/smoke fields into richer structures

Why it looks good:

The solver transports everything coherently, so shapes do not break up randomly, they deform like flowing material.

temperature and smoke play different visual roles:

temperature gives the bright active flame core

smoke gives softer, darker, trailing regions

Fire color is not simulated directly as RGB fuel chemistry. Instead, it is rendered from the fields:

hot = bright / yellow / white

cooler = orange / red

smoke-heavy = darker / grayer

Vorticity confinement brings back the small flickering tongues and curls that numerical damping would otherwise wash out.

The system is only a rough physical approximation, but it emphasizes exactly the cues our eyes read as fire:

upward rise

turbulent breakup

bright core

unstable edges

smoke appearing as things cool

Recognitiom & credit: I've learned so much by reading “Stable Fluids” (1999) by Jos Stam which was published at SIGGRAPH 1999.

https://pages.cs.wisc.edu/~chaol/data/cs777/stam-stable_fluids.pdf

Its impact led to major awards for the author:

  • 2005 – ACM SIGGRAPH Computer Graphics Achievement Award Awarded to Stam for his overall contributions (including Stable Fluids).
  • 2005 & 2008 – Academy Scientific and Technical Awards Often called “Technical Oscars,” recognizing contributions to visual effects and simulation techniques.
u/StefanPetrick — 14 days ago

Question to u/ZachVorhies or any other battle-hardened senior devs here: What’s a good way to organize communication and goal setting when aiming for efficient collaboration?

Right now, our conversations are scattered across GitHub discussions and issues, Reddit posts, YouTube comments, Reddit DMs, Reddit groups, Messenger DMs—it’s a mess and nearly impossible to find something we discussed just two days ago. Very inefficient.

How do professionals handle this? Do we need something like a Scrum master, or is it more about having the right structure and discipline? Or should we all just use Clawdbots talking to each other and have them figure it out and keep track of previous discussions?

I’ll admit I sometimes get carried away by new ideas and suck at caring about the nitty-gritty details of existing ones. Instead of fixing something, I tend to reinvent it from scratch—which can be frustrating for whoever is working on the current version.

I’d really appreciate any input or advice on how to balance wild creative freedom with focus and actually shipping a product.

For context, I’m probably a bit on the ADHD/Asperger/high-IQ spectrum.

Also, I do actually enjoy the creative chaos resulting from the mixture of expert feedback and lurker opinions. It can be very inspiring, and since software development is not a job for me, I value having fun while doing it. I just don’t want to risk u/mindful_stone and others getting tired of my current style, so I’m addressing it preemptively. I’m willing to try different approaches and improve if needed.

reddit.com
u/StefanPetrick — 16 days ago

Currently it is a Python prototype but ultimately it is meant to run on a microcontroller driving programmable LEDs.

I love the level of detail this algo produces!

u/StefanPetrick — 19 days ago
▲ 16 r/FastLED

I followed u/sutaburosu’s advice and had a look at the Navier–Stokes equations. I got a little demo working, and I already like the output quality.

I doubt this will ever run on an ESP32 with a reasonable frame rate, but a guesstimate of the required resources indicates that it could be possible on a Teensy 4. We will see if this is true.

edit:
For everyone interested, here is an in depths explanation of the underlying concept https://www.youtube.com/watch?v=Q78wvrQ9xsU

Here the Wiki article: https://en.wikipedia.org/wiki/Navier%E2%80%93Stokes_equations

Fascinating fun fact: This system of partial differential equations was named after Claude-Louis Navier and George Gabriel Stokes, who developed them over a few decades of progressive work, from 1822 (Navier) to 1842–1850 (Stokes).

u/StefanPetrick — 20 days ago
▲ 13 r/FastLED

In case you are aware of a more realistic looking concept or algorithm I'd love to hear about it! I find it surprisingly difficult to model it somehow.

In the video I use the yellow layer to modulate the x coordinates of the noise sampling of layer 1-3. So domain warping actually.

u/StefanPetrick — 24 days ago