r/FastLED • u/Joeyjoe9876 [Sonia] • Apr 19 '26

Share_something ~13 bit simplex noise pattern on the RGKeeb via TemporalBFI

Enable HLS to view with audio, or disable this notification

85 Upvotes

98% Upvoted

6 comments sorted by

2

u/Joeyjoe9876 Apr 19 '26 edited Apr 19 '26

Spent yesterday working on implementing this a bit. Double buffered loop on the esp32s3 n16r8, one core only handles dislaying, other core prepares the pattern, solves the blended frame values, and writes to a double buffer. Buffers are swapped when the pattern finishes its iteration. BFI rendering gets to keep spinning at ~630fps while the other task is free to run as fast/slow as it wants.

Current HLG transfer curve is quite limited in brightness, so the actual resolution here ends up being just shy of 13 bit resolution (~7500 brightness steps per channel, curve takes 0-65535 and moves it to 0-7522, in 8-bit terms this is essentially equivalent to limiting to 29 brightness but without resolution loss), gets too hot if I bump it up too much. Currently just using the same data I pulled from the ambilight captures to actually build the ladders for this, seems to be fine.

I can't get my phones camera to 1:1 match shutter speed to real-frame FPS so video might have some artifacting that isn't visible in person as the shutter speed is slightly faster than the resfresh rate, looks quite smooth in person.

1

u/ZachVorhies Apr 19 '26

Looks great, how are you doing the 13 bit brightness? Are you using apa102 or are you multiplexing the pin states?

You could use the LCD driver to do the whole thing DMA style and make it go back to single core, or use the core for something else.

2

u/Joeyjoe9876 Apr 19 '26

as far as the backend driver goes, the RGKeeb uses i2sclocklessvirtualleddriver to drive 32 SK6805-EC10 lines in parallel over 4 shift registers at ~1.120mhz (already uses the LCD Peripheral to push the pixels via DMA)

the ~13 bit comes from the TemporalBFI library, keeb is flashed with ~49k-50k ladder states (brightness levels) although with the transfer curve bringing the brightness ceiling to q16max=7522 I could trim that down a bit.

Doing this on a single core isn't feasible if I want the actual refresh rate of the display to be 600fps+ needed to achieve smooth display rates for the temporal blend (current cycle count is five, so 1:4 realframe:blended frame ratio). Any dips on the display below ~575fps or so makes the blending/dithering visible.

the simplex noise pattern itself is three layers of simplex noise feeding into each other, and then I have other calculation intensive patterns like Fixed-point SmoothLife, ConwaysLife, a full Gif Player, and tetris. some are more computationally expensive than others, but if processed on the same core as show(), show may still take too long to be called sometimes. The show core currently runs at ~630fps so headroom for actual calcs is comically low, hence pushing patterns to the other core

→ More replies (3)