Arbitrary 3D light arrangements.

[danielkleinert]

Hey there,

Cool project! The UI is pretty fancy for an embedded project.

I'm exploring the layout options and noticed they're optimized for grid-based arrangements. I understand the current
approach is efficient for mapping panels and cubes to a rigid virtual grid, which allows reusing WLED patterns. However,
this doesn't work well for arbitrary 3D positions like:

• Christmas light strings mapped with https://github.com/TheMariday/marimapper
• LEDs on sculptures or architectural installations
• Non-uniform panels like https://www.evilgeniuslabs.org/fibonacci512-pixelblaze
• Panels placed at angles to each other

Current limitations I've noticed:

1. Positions are quantized to integers and discarded after layout
2. For sparse arrangements (e.g., 500 LEDs in a 100×100×100 space), effects iterate the entire grid rather than just the
   physical LEDs
3. No way to access actual LED positions for distance-based effects

What would help:

Storing the actual world position (x, y, z as floats) for each LED, and changing the effect interface to something like
Pixelblaze does:

  export function render(index) {
    // pixelCount, x, y, z available as globals
    h = distance(x, y, z, centerX, centerY, centerZ) * 0.1
    hsv(h, 1, 1)
  }

This would enable:

• Physically accurate rendering across angled/non-planar surfaces
• Efficient iteration (loop through 500 LEDs, not 1M grid cells)
• Position-dependent effects (ripples, waves based on actual distance)

Has this approach been considered, or is it outside the scope of the project? Curious to hear thoughts on this!

[ewowi]

Hi Daniel,

Excellent idea!!
I was already struggling how to do some mappings , especially what you describe if you have for instance a Xmas tree you should position a logical grid which become quite big.

I have a PIXELblase device (thx @atuline 🙏) but did not use it for years but vaguely remember the concepts.

We don't need to exactly copy it but I am all ears if you have ideas to design a mapping system which covers the type of setups you describe

[ewowi]

Storing the actual world position (x, y, z as floats) for each LED

Do I understand correctly that a formula is used to do this during rendering ?
The way I do it now is read all positions before rendering and create a mapping table out of this , so not all positions needs to be stored in memory , what would be quite a lot of memory if I did.
So a formula avoids using a mapping table?

This would be easy for a matrix panel, but how to do that for a completely random layout ?

[danielkleinert]

I was thinking to store the positions on device as that is the only option for random points. That at least is how the Pixelblaze (Mapping Doku) as well as Twinkly does it.

However, the memory constraints seam significant. My napkin math tells me that 3 floats for each LED is 120KB for 1000 LEDs, which is a quarter of available SRAM on an ESP32. I assume SvelteKit also needs a bunch of memory for its runtime, so storing positions directly on device is impossible without PSRAM on larger installations?

That said, maybe having functions return the position at render time works in most basic configurations. For a Christmas tree it's apparently even somewhat sufficient to model the spiral with rings. So super high accuracy may not always be needed for aesthetically pleasing effects.

I think a hybrid approach makes sense: if the device has enough memory (especially with PSRAM), the user could switch the procedurally-generated points with a stored map from camera capture. This gives you the best of both worlds - memory-efficient mathematical models for simple geometries, and precise stored coordinates for complex or irregular installations.

I find the concept of capturing the position of the lights with the camera much more appealing than having to estimate the form with geometric functions by fiddling with a bunch of parameters. The two systems I tested (Twinkly and Marimapper) also do work quite well. But I have neither tested it with ginormous amounts of LEDs nor with much occlusion, so I'm curious about the practical limits.

Another software project that features arbitrary 3D mapping is Cromatik. Maybe it's worth having a look at what they do in terms of fixture generation, fixture positioning and normalization bounds.

[ewowi]

For systems with psram that is absolutely feasible !
As 90+ % of psram is just doing nothing so let's fill it up 🤟

[ewowi]

The advantage of the current mapping system is that multiple modifiers can be applied to a mapping:

First thing the mapping system is doing currently is allocate each coordinate of a fixture in a grid. For the x-mas tree you could say every 5 cm is a slot: 10 * 10 * 50 would then cover a 50x50x250 cm tree, this is 5000 virtual pixels and whatever the number of real leds is (between 100 and 1000-5000 leds?).

A camera capture of pixel coordinates , normalized within a 10x10x50 space can then be used as the layout - need to make some software for that - but that is not the end of the world. Maybe you have something you captured, happy to use that as test set.

Running this with 5000 virtual leds is really no problem at 30-100fps on a normal ESP32.

If modifiers are applied then you can rotate, mirror, multiply etc on that effect - but let's put that as a side effect for this discussion.

I think however it is an interesting idea to add other mapping systems. procedurally-generated points will probably be one of them as that keeps efficiency for very large fixtures without the need of mapping tables. @hpwit does this also in his clockless drivers for panels. I think you will loose the modifier functionality here (afaik) but it might be a good tradeoff for speed.

Next is your idea with precise coordinates. What I don't oversee yet is how effects work on them (except distance). I guess normal wled effects don't work on them - or can we add a layer in between ? Will we create a dedicated set of effects for this?

Copying in @Brandon502 here, as he made very nice combinations of effects and modifiers before. Brandon502, if you have ideas here as well, happy to hear.