I have a disk-shaped lighting element, 6 rings of equally-spaced pixels (ring 1=30, ring2=24,18,12,6 pixels). This doesn’t map well to rectangular 2D. So, I have created a usermod for effects that reflect this geometry, eg. radial chase, and angular chase, and another usermod that comprises a mapping function which takes a polar coord and gives back a pixel #, and can be configured, through the existing mechanisms, with the specifics of the disk geometry (#s of pixels for each ring).
I have another project that has another different geometry.
Proposed enhancement:
The minimal enhancement I propose is to expand the existing geometry tagging of effects beyond 1D, 2D and 3D, to allow for new geometries such as disks, lattices, etc. and to show that tag in the UI.
I doubt it is universal, but I have two previous projects with polygonal column lighting elements, but using small MCUs (those might work with 2D arrays), and I see someone has done a project lighting a drum.
Eventually, I’ll get around to the finer points of the above proposal.
That is a seriously cool project. I went to teamLabs Borderless in Tokyo (I live an hour away) a month ago, and got inspired to try for more complex projects. Thanks for the link. I think I’ll also look at the MoonModules project. Interesting ecosystem y’all have built.
When I was implementing 2D I thought about polar coordinates and how they would relate to existing code in effects. Unfortunately there were little effects written explicitly for polar coordinates in general and none for WLED. So I decided to not add dead code to WLED (though I kept float version with relative coordinates).
It also clashed with the implementation of cartesian space LEDs were organised on pre-made panels (the ones readily available).
IMO to have a truly polar implementation one would need to figure out mapping 1st as LED circles have progressively larger number of LEDs each with different separation angle. Once that is figured out (keeping low memory requirements) then implement Segment::setPixelColor() accordingly.
There may be other ways to do it, but I can’t think of any ATM.
A simple mapping from polar coords to a discrete spacial distribution of pixels will not be exact, and the same problem exists for rotating a line in a regular cartesian grid. Anti-aliasing is the obvious approach to make that better, but this is all lo-res so it may not look so good. The simple mapping approach is what I’ve taken, although I’ve experimented a tiny bit with anti-aliasing.
But that isn’t what I’m suggesting here. Imagine you write a usermod for a new GeometryX which suits whatever oddball physical arrangement of pixels you’ve created, and an ability to parameterize that through the usermod config. And that usermod has a bunch of effects that work with GeometryX and then map the results to pixel indices in a segment. That’s enough to get the effects going.
What I am proposing is: it would be helpful to users to flag those usermod effects in the Effects UI as being for GeometryX. One might imagine having additional effect parameters, but that remains to be seen.
I’m not sure if there would be any other requirements for this minimal support for new geometries…
With ledmaps (actually a 1D representation) you logically rearrange physical LEDs. How you interpret this rearrangement needs to be built into setPixelColor() method.
WLED internally works either in 1D (setPixelColor()) or cartesian 2D (setPixelColorXY()) which is organised internally as a ledmap spanning from top-left to bottom-right row-after-row arrangement.
Fair enough. I just got these basic effects to work 5 minutes ago (something is going wrong with loading the config, so I had to hard code it once I figured that out). Apologies for terrible video quality.[VID_20240403_213139.mp4 - Google Drive](Angular chase)
[VID_20240403_215822.mp4 - Google Drive](Radial chase)
This is running on an ESP-M2 (ESP8266) on a custom board.
And that’s enough for this evening. I note in passing that reversing or mirroring the segment doesn’t give a sensible result. It would be nice to have a reverse button. Maybe one of the UI bars could be considered +/- for that… I need to check the UI docs again.
Here’s the board (I repurposed the USB D+/D- for TX/DX), which fits in a USB stick case. Note the patch wire that changes the LED GPIO. Fixed in the next version.
Very good work
but this only fits your setup most props are wirerd in Zigzag mode on the Spinners
and as of Xlights the MAPPING is virtuall and on the Mouse sweep
No idea what ‘Zigzag mode on the Spinners’ means, and why it is significant. Sure, the disk is my design, but LED rings that are designed to nest together are common enough.
As I mentioned earlier, I also have projects which are polygonal cylinders, with analogous patterns being appropriate (chasing around ~ angular and chasing up-and-down ~ radial).
Hence my proposal here: let people create usermods for these odd geometries, and just support tagging the associated effects in the UI. (And, later if takeup is good, additional support once you know what it should be.)
@TokyoDave Here is a 10min work small sequence on your Setup
there are 5Mapps involved to do that and just some blink resets
so i PERSONLY think alöl your work is not needed
CONSUNING 0,14Amps at 91Nodes/Pixels/LEDS
AS Specialy thinks like the CAKE Slice in the Video is hard to handle on no MAPPING
