This online webapp solves most of your 1D 2D (and some 3D) mapping head aches, and exports to various formats, including FastLED arrays.
Check it out r/FreeLED or go directly to the tool which is permanently host at freeled.org
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:
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:
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:
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.
Hey all! Ive been working on an update for the ESP32-based Artnet node, and I am proud to show off the results! It now supports 3,4, and 5-channel LED colour types, as well as SPI-based LEDs! This basically means support for every LED strip available!
Check out the project and changes here; https://github.com/mdethmers/ESP32-Artnet-Node-receiver
Next to that, a new hardware revision is coming, supporting;
Let me know what you think and if you have any questions!
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
working on a LED matrix thingy and made a mistake, my panel ended up vertical instead of horizontal.
basically:
this is what its like right now - its running left to right vertical.
but i need my code to treat it as horizontal, so like this:
is there a software way to do this or is my only solution just changing it physically?
I love pussywillows. So, I made some FastLED pussywillows from 150 – 5-volt WS2811 bullet leds, a Lolin D32 MCU with a level shifter and the FastLED library with power injected at both ends. Also, a 470-ohm resister is in the data line.
The matrix is setup as a special circular mapped 10X15 matrix as seen in this YouTube Video:
The code for this project including build information is located here:
https://github.com/chemdoc77/CD77_FastLED_2026/tree/main/CD77%20FastLED%20Pussywillows
The wiring and mapping for the bullet WS2811 LEDs used in this project were inspired by Mike Katchmar’s FastLED Snowflake project as seen here:
https://www.youtube.com/watch?v=kHvcf89McvU
Enjoy!
Best Regards,
Chemdoc77
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!
I've been having fun with the FastLED fluid type stuff u/StefanPetrick and u/mindful_stone have been coding. It's fascinating that this little chip is handling such smooth motion and detail. A real fluidy simulation!
Anyways, you aim the nozzle and try to put out the fireball as fast as you can. The score comes up giving you how many seconds it took.
I built a nice enclosure for my teensy control box which has the potentiometers, switches and buttons so that it's pretty much a standalone matrix mixer type thing. I have it going through the different pattern sets and I'm trying to control as many variables as I can with 8 pots, 4 encoders, 4 buttons and 5 switches. The only thing in the game I'm doing is changing the angle with a potentiometer.
I don't know but using a knob and watching the reaction of the animation on the matrix is prety neat! You get visual feedback.
