Here is a novel string pattern I have been working on. Finally got it running after a few grounding and whoops, hot and neutral disasters. The pattern is Blinkfade in a cube-frame, strung in a “stochastic” fashion, that is from only the edges of the frame.
4 Likes
Really nifty, hard to tell the scale. What’s the separation on the LEDs apart on the line?
If you mapped this, it would be awesome. Doing it by hand would be a pain though. There are some tools that take video, where you light up each pixel in sequenence and take video from different angles and it calcs the 3D coordinates.
It is a 1 meter cube. Pixels are addressable “Fairy” lights about 4" apart on the strings. They are ridiculously, impractically, physically and electronically delicate.
Of course, I 'm looking for more robust alternatives at lower cost than these more durable-looking alternatives - https://www.adafruit.com/product/3630?gclid=Cj0KCQjwktKFBhCkARIsAJeDT0hx_6sFoUmyycu-MiYjkxenDfwsrP3SvL3yHn9mJvKz_RqoFKc7YDoaApSZEALw_wcB.
I’ve thought of mapping this framework with a high-end 3D scanner (my local U has one available to whomever) but have not tried it. The longer term intent is to employ more “macroscopic” forms of LED lens, more visible to a presumptive scanning device. Perhaps that approach you suggest @Scruffynerf, with sequential lighting and photography would be a better alternative!
One example (scroll to bottom of post for my recommended solution, but listed a pile of others first…)
Another:
Another:
Another: Spatially-Mapped Christmas Lights | ch00ftech Industries
More:
Btw, there is a commercial product, Twinkly.
But I suspect we can do better.
Getting closer:
This is a ESP32 cam based solution, which is neat…
but it looks like this next guy used some of this code, and made it better:
I’d linked this before here and just refound that post, and another by @devoh that mentioned it as well.
This one is a web app you upload video to…(and the web stuff is open sourced) and it uses an Arduino program to generate the led pattern (just a run thru each led) which you then video. SO… If someone ports that super simple .ino pattern code into a PB pattern, then with just that pattern and two self recorded videos, you’d be all set.
Right now that is the method I’d prefer to see us flesh out. I think we can make this into a PB recommended solution.
Ben did a great 2D mapping tool, but I’m not aware of a 3D one (yet). @wizard , since the above led3D code runs entirely locally in a browser (no video uploading is needed), you could tweak and host that, if you wished, and have a 3D tool as well. An .epe to download the pattern onto the PB, take two videos at right angles, and then load the webpage add videos, and then 3D video mapping that generates the map in a cut/paste format ready to go for PB.
2 Likes
To be clear, I suspect you could map this manually fairly easily, measuring the end points of each span across the cube, and doing a point every 4 inches. If you go this route, and provide a spreadsheet, we can turn this into a map.
Happy to discuss this, but now that I’ve seen the led3d stuff, I think that’s actually WAY less work. I’d rather help you figure out how to use that.
This is simply amazing tech, and super well-outlined in that above-provided YouTube video. This sounds very promising and interesting. I’ll need some time to see how I could adapt this to my needs. But dang, I now want to map in 3D, looks like some real creative possibility there!
By the way, here is the mess driving that cube. One 40A and one 30A (nominal) power supply, a PB v3, an output expander and four channels running 800 LEDs.
I was going for 1000, but decided to film before something blew up. Its all pretty delicate at this point.
2 Likes
which fairy lights are you using that are so delicate?
Are the wires stranded or solid core?
I got some addressable fairy lights that used stranded wire and they were super delicate. But I found some that are solid core and had no issues.
Check the “Color: 50 leds Copper wire” option
I’ve also found these which are even more solid and larger “bulbs”
But the addressing is weird and you can’t have more than 200 leds on a single data line without repeating. If your 800 LEDs are divided evenly on 4 channels you’d be fine.
Yes, the second item is the one I believe he’s using, that we’ve discussed elsewhere. They aren’t that fragile, I’ve found. I still think they are awesome, and the 200 limit is really the only big negative. I wish someone would make closer spaced lights out of them, but I did figure out a good trick to reduce the wiring between: curl them (wrap around a small dowel/rod, and then slide it out, leaving a tiny bundle/spring that hopefully will help with spacing closer, with minimal light blocking in some cases.
The problem with the first one (and the ones @JustPete linked to originally from Adafruit, which are ultra expensive for no good reason) is that they are single sided circles (really tiny pcbs). For flat surfaces, or in a window, fine, but for 3d use, not really good, and putting two together (back to back) doubles your power requirements (you could fork the data line, so they’d mirror lighting wise at no extra FPS).
Or maybe someone will invent something similar to @wizard 's bullet clip for these, that will diffuse the light into a nice globe for cheap. (The premade ones I’ve made aren’t cheap). You can buy unsoldered 1 pixel PCBs (usually in unbroken PCB panels of 100) fairly cheaply, but then you have to add all of the wiring and solder it (6 solder points on each), which is not fun.
I’ve been using these - IMHO, they are too fragile both electronically and physically - https://smile.amazon.com/gp/product/B08HK67784/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
These mfrs use aluminum conductors that are really quite insubstantial. We need some tensile strength and these have very little. Further, the “blob” of resin at each px does not fully cover exposed wire ends and thus they are not adequately electrically insulated. They seem to develop bad px really easily.
We used non-addressable in some constructs in the past. These strings’ copper conductors and lack of snagging cut wire ends made their handling much easier than these addressable ones.
Of course, the attractions of the firefly-type lighting are the relatively discrete wiring and the near 360 degree view angle. Indeed, this might be achieved with back to back 5050s or something like that but… as @Scruffynerf mentions, LOTS of hand work or perhaps custom China order.
We also experimented with a 3D-printed shell on the firefly lights but it seemed to dim them too much. Am considering using a UV-cure resin to enhance the blob as we need a bigger one… granted we are still experimenting.
Here is a link to another pattern I loaded into the present cube test frame -
https://www.youtube.com/watch?v=4T66yrczwtA
It more readily shows the “stochastic” pattern my friends at Corporation Chaos Camp came up. This is a great group of B. Man folks who tend toward philosophy and math. Don’t know why they let me hang w/them. But that’s another story.
Anyway, good discussion, cheers and off to the weekend with gf.
2 Likes
Oooh, I didn’t realize you were using those (I call them the 3+1 wire lights, cause they are really 4 pins, but they alternate the middle.) Those are true ws2812s, you COULD run more than 200 of those in a single strand.
The wires on the “fairy lights” one are definitely more sturdy.
Have a good weekend, and when you return, we’ll get a true 3D map on that thing.
Looking forward to continuing here, absolutely. Momentarily absorbed elsewhere but will return. Wanted to let you know. Cheers.
1 Like
Well, I finally got through crashing my computer and finally getting it all rebooted with functioning graphics drivers and everything. Man, what an adventure, besides all else!
Anyway, here is an vid of the cube upgraded to 1000 px, running the Color Twinkles Pattern. I thought some of you might like to see it - [Color Twinkles 1000 px - YouTube]
I am all for that. Happy to at least provide some video to the effort.
I have not tried the referenced strings but may. Not sure why there is a 200 px limit but that is what I am running per channel now anyway. That seems to limit future-forward flexibility, tho.
I am working on something, please stay tuned.
Then we also have the lack of backside illumination problem, all which has been mentioned prior.
In any case, mapping the cube would be fun (I expect) so if there’s interest, let’s do it!
1 Like
Here’s a quick-and-dirty PB port of the .INO…
delayFor = 5000; // How long before the pattern starts
displayFor = 200; // How long each LED stays lit
export var initialDelay = delayFor;
export var whichLED = 0;
totalTime = 0;
export function beforeRender(delta) {
if (initialDelay > 0) initialDelay -= delta;
else {
totalTime += delta;
if (totalTime > displayFor) {
totalTime = 0;
whichLED++;
if (whichLED > pixelCount) {
initialDelay = delayFor;
whichLED = 0;
}
}
}
}
export function render(index) {
if ((initialDelay < 0) && (index == whichLED)) rgb(1,1,1);
else rgb(0,0,0);
}
EDIT: took a second look and noticed that the pattern repeats.
2 Likes
With this [quote=“Scruffynerf, post:4, topic:1280”]
If someone ports that super simple .ino pattern code into a PB pattern, then with just that pattern and two self recorded videos, you’d be all set.
[/quote]
and
I’ll see if I can squeeze something in on this this this coming week. Please do stay tuned. Thanks @pixie and @Scruffynerf
1 Like