I’ve uploaded Mandelbrot2D to the pattern library. This is the, “hmmm… let’s just see if we can do this at all”, version – it calculates the fractal in a straightforward, brute force way, through a small number of iterations, and doesn’t give the user a lot of control. It does work though, and is fun to look at, so here it is!
(It is very compute intensive. If you’re running on anything bigger than 16x16, you’ll want to turn down the number of iterations. Optimizations and more features are on the way, but there’s a lot to do, and it’s an interesting internet rabbit hole, so it may be a few weeks.)
I have rescaling treachery in mind for zooming, a bunch of symmetry and region similarity optimizations still to do, and a progressive renderer that spreads the iterations out over multiple frames – there’ll be a bit tradeoff between detail and animation speed, but increasing the iterations won’t bring the Pixelblaze to a standstill that way.
It’ll be fun to see how far we can get with this sort of thing. There’s kind of a limit in that after a point, the low resolution of LED displays makes it way less interesting to compute more detail.
This is so cool. I had fun messing with time, infinity, and iterations in sliders. Also found that 1 - iter/maxIterations made for a pleasing brightness value and helped get a feel how iterations and infinity interacted through the fractal.
weird, this isn’t working for me, downloaded the epe file, and it’s not even doing half of the 16x16 matrix… something’s off. Other matrix code (including my tixy, and the 2d sweeps) all work.
Lots of activity on the first bunch of pixels, not much else.
adjusted pixel timing, and that might have helped a bit (it’s a new matrix, and I’ve noticed some weird glitches, so unsure)… but then I reduced the iterations, including allowing less than 5… and it works right up to 4 iterations, and 5 glitches for sure… never mind any higher…
I even tried skipping every other pixel (index%2), and no go, iteration 6 fails to complete regardless…
I can repro your problem if I set type to plain WS2812/DotStar. Pretty sure I’m just burning up all the time that’d otherwise be used to send data to the LEDs!
So adding sliders for cR and cI defintely helps you explore.
One option to increase speed + usefulness:
save all of the pixel calcs into an X/Y array, so you aren’t recalculating each time at zoom level X
now you can pan around cheaply at zoom level X, just copy the array over (so shifting left by one pixel, now you only have to calc that right most row, etc).
that would allow smooth pans, as you get details worth viewing, rather than only zooming deeper… so zoom in, slide around some, then zoom out or go in deeper, repeat…
All these things are great ideas and are coming! I actually had a bunch of sliders in during testing, but took 'em out because I just wanted to see what folks though of the idea – didn’t want them to wind up stuck out in the far, dark regions of the set. It’s fun to pan around though – definitely in for the production version.
That is really beautiful! I’m looking forward to doing a bunch more playing with fractals – even dug up the source code to Fractint, the old 286/386-era favorite, to see what optimizations they used. If only my pending project queue would start getting shorter instead of longer…
