I have a LPD8806 32 LED strip. I want to do some POV on.
I have it all woking with a Teensy 3.1 with some example code.
My question is is there any example code for POV anyone could point me to?
Interested in generated patterns rather than images, maybe also some Perlin noise. Had a bit of a search around and can’t find any FastLED POV examples.
Thanks for any pointers.
There are countless of examples of how to display text, or bitmaps on a set of LEDs on Google - just search for ‘arduino pov’. Since you said you want to generate patterns, you’re in the mathematical calculation realm. You still have to think in terms of a “sliver” of a bigger picture. For example, let’s say you’re looking at a Sine wave. As far as POV is concerned, it’s not seeing the whole wave, it’s merely seeing one single point along the wave. So for each time you flash the strip, you’re displaying one single dot along that sine wave, a dot that constantly moves.
Almost everything I do is images so I don’t think any of my code will help you.
I´m looking fot the same…when I find something I´ll write you… I´m still working with arduino mini & micro, is impossible to find tweensy here in Brazil…
I’m spending some time working on a perlin noise generator - if/when I get something that’s efficient/works/etc… i’ll post it to here!
@Daniel_Garcia @Daniel_Rowe I’ve also experimented with noise in the past. I recently (a few months ago) ported the Improved Noise (fixed point example) from Ken Perlin to Arduino: http://mrl.nyu.edu/~perlin/noise/INoise.java
It runs at about 12ms for 50 “lights”, however a lot of memory is used for lookup tables. I don’t know if it helps in some way, since you and Mark are way more skilled in making low-level and fast implementations:
Ah, I didn’t realize that he had done a fixed point version of it. I this’ll be a nice jump start on my own implementation. There are a bunch of ways that I can already see to improve the performance of the code that you posted up - if I get anywhere with it this week, I’ll post it up 
(First hint - right now you are using the code to do 1d noise, however the noise code does 3d noise, which means you’re doing 7 linear interpolations per point instead of 1 for 1d or 3 for 2d)
Great to hear that it could help. You mentioned I did 1d noise, but I think I do 2d noise right now in this code (renderNoise(x, 0, perlinTimePosition)), the x-axis for the lights and time on the z-axis. Still that could save 3 interpolations. However I also used it for an effect in a grid (so 3d, x, y and time).
I’ve got some code in place now that does almost everything with 16 bit math (barring some 32-bit operations in the heart of the lerps), also with a faster fade function (with a slightly different curve) that should cut back on the amount of progmem that you’re fighting with.
So far it’s got 1d, 2d, 3d noise, and before I finish it up, I’ll probably toss in a 4d noise version as well.
I can also tweak it a bit further to get rid of nearly all of the remaining 32 bit math (by going from 16.16 x/y coordinates to 24.8) - which i’ll probably do in a bit.
Then i’ll get it cleaned up a bit more, get it wired in with my grid mapping code (so you can rapidly map (and rotate), say, an 8x8 grid of perlin noise computed nodes to a 200x200 grid of led x/y coordinates), and get it published for folks to play with.
Cool… Going to have fun.
and I now have a version that uses no 32 bit math at all. Now to clean the code up, make 1d and 2d versions of the code that’s not using 32 bit math, and do some timing tests on the teensy 3 and avr and report back. Also, I’m going to talk to mark tonight about the possibility of including noise3d/noise3d8 in the library (as well as make finer decisions, like should coordinates be 16:16, 24:8, 8:8, or something else entirely). Oh, and then I want to see about building fractal functions on top of this - because, why not?
Not yet done optimizing - but some numbers (also, I think i may throw this into the library):
There’s four runs. There’s Perlin - which is the fixed point adaptation of Perlin’s improved/simplex noise that @Kasper_Kamperman linked to above.
There’s inoise16w12 - which is a 16bit version of the perlin function (no 32 bit math at all using a 12-bit fade instead of 16-bit (like the original prelin).
Then there’s inoise16w16 - which is the 16bit version, but using 16bit fades instead of 12bit.
Finally, there’s inoise8 - which is an 8bit version, with no 16 bit math operations.
Perlin: 4.444px/ms
inoise16w12: 4.975px/ms (10% faster)
inoise16w16: 5.347px/ms (20% faster)
inoise8: 6.329px/ms (42% faster)
Video and code coming soon
(oh, above numbers are on an arduino nano, running at 16Mhz)
I’m sorry, I seem to have gotten the above numbers wrong. (What’s that noise you ask? Er, um, don’t worry about it, we’re just strangling the life out of gcc in the background. We’ll set it on fire and walk away soon enough).
perlin: 4,444px/s
inoise16w16: 14,925px/s (335% faster)
inoise8: 28,571px/s (642% faster)
Or, to put another way, it takes only 35ms to update a thousand pixels w/inoise8 vs. 225ms for a thousand pixels with Ken Perlin’s fixed point implementation. (Your 50 pixels above would take about 1.75ms).
Wow, impressive numbers! Do you have a good source to read more about fixedpoint math? Seems good to have some understanding of this when working with microcontrollers.