Perlin/simplex noise on my L3D Cube.

Perlin/simplex noise on my L3D Cube.

I used the FastLED Perlin/simplex noise generator plus the color palette lookup function and combined it with my accelerometer demo code (layer animation) to build a 3D noise demo.

Basically the code generates noise into one of the layers (8x8) and then copies it to the next layer and repeats so that the layers are noise over time. The code is written to allow you to animate in either direction on any axis (X, Y or Z). The video is using the Y axis and filling from the back to the front. The code allows you to change various parameters such as the speed of the animation and the scale (zoom) as well as the palette. The demo video is using the built-in lava colors palette.

Running on an Arduino Mega
http://www.youtube.com/watch?v=hhcRnUWRC9s

@Mark_Kriegsman & @Daniel_Garcia , I’d love your thoughts on how to make it better/smoother.

It’s very cool looking!
And the approach of generating just one plane of new noise each frame is a good one for keeping CPU load down; generating 512 noise points each time through would be … slow. Slow enough to be visually less good anyway I think.

As for making it “smoother” or “better”, there are basically two ways I can think of. Ok, three. Here they are:

  1. apply some/more data smoothing to the noise data before rendering it (more on that in a sec)

2a. switch to the 16-bit version of the noise functions, which produce smoother results themselves (at a cost of high CPU usage, and thus, annoyingly, lower frame rates)

2b. switch to the 16-bit version of the noise functions AND switch to an ARM-based microcontroller. With native 32-bit operations, they can do much better noise much faster.

  1. Use 2a above, but don’t recalculate every noise point every frame: recalculate alternating points in alternating frames. This can help cut CPU usage by almost half, and thus almost double frame rates – at a very small cost in model accuracy.

Basically, calculating noise points it pretty expensive, and calculating more of them, better, is more expensive. So that’s the operation you want to minimize.

As for data smoothing, how much/ what are you doing, the PalettePlusNoise example has some in there. Are you using something like that already?

All your posts with this cube make me kinda want one, just to play with!

I was going to ask “who would drive a 3d setup from an AVR?”, but i realized, that the cube is basically designed for an Arduino.
So I don´t say that but agree instead with everything Mark said.
Just adding that with a Teensy 3.1 + SmartMatrix with 1k noise points and some other minor calculations I get arround 108 fps, with 2k points 74 fps and with 3k 54 fps.
So I think with 8 (or even16) pin parallel output ±100 fps should be reachable while calculating every point for every frame. Also on a Teensy the 16 bit noise calculation seems to need as much time as the 8 bit version, but - as mentioned - is looking much better.
And I´m also tempted again to get such a cube or at least build a basic 3d setup to play with.

@Mark_Kriegsman , I knew you were going to steer me to the Teensy eventually. I built it from PalettePlusNoise so it is using the same smoothing.

So for what it’s worth, I’ve achieved pretty smooth palette + noise at 16x16 (256 pixels) at more than 30FPS on a regular AVR chip. The key to happiness was recalculating only every other noise data cell in each frame. Basically odd pixels updated in odd frame numbers, and even pixels updates in even frames.

That, plus noise smoothing, plus (I think?) video smoothing made it look pretty much OK.

512 pixels? I don’t think you want to try to recalculate 512 noise data points 30 times per second on AVR.

You could also just calculate noise on a 4x4x4 cube (64 points) and do linear interpolation for the in-between cells.

But basically, I don’t think there are enough clock cycles on a 16MHz 8-bit AVR to recalculate 512 noise data points at 30 FPS. That’d be just over a thousand clock cycles per data point to do everything. I dunno. Maybe it’s doable, but you’d have to rewrite a lot of it in AVR assembly … and have it come out 50% faster than what’s there now.

So: basically: do less software work in each unit of time, or switch to a CPU that can do more hardware work in each unit of time.

I bet you can be clever on the software side.

The Spark Core it came with would be about as fast as a Teensy, right? It just doesn’t work with FastLED yet.

Correct on both counts, Jason.
Dan and I discussed the SparkCore again last week, and we’re optimistic about what it’ll take to port FastLED to it – but also have a backlog of other work. So, it’s coming, just not here yet.