Pixelblaze V3.19 beta

Feature Ideas + Requests
,
21

I think i get the power of the map, but afraid there are always going to be a lot of other patterns. hence once you get that perfect map done, and go find some other new pattern, you have to tweak the map. and it would be better to embrace the excellence of the power of the map rather than strive for every patterns perfection… make ALL patterns ‘more perfect’ by abstracting that hardware. regardless if the are written with the latest direction of the wind in mind.

My pov is have/support multiple maps and make it easy to pick one.

Every one of those EXAMPLE maps (along with the ability to customize and OVERRIDE some of the global values Pixel Count and Ex-pander board settings) ,be callable, bindable as a “config set” I’d like to be able include/exclude certain pixels to have them always on or always off, or virtually re-wire the ordering of multiple displays daisy chained. I know you can do all of that in pattern code. but dont want to do that in every pattern for every project. i want to do that more globally.

I think the map is underappreciated being cast as a simple set and forget translation layer.

1 Like
22

I tend to agree, and anyone can tweak a pattern to be more optimal for a given piece. I think the universality - that it can work out of the box with no modifications is powerful.

When it comes to displaying 3d patterns on 2D, the new version can do that now. It defaults to a 2D plan with a fixed Z component, which is probably not ideal but is easy to explain/understand. Perhaps there could be a way to specify how the 3d pattern renders in 2D, which of the 3 coordinates to use for the 2D, and perhaps a way to rotate/translate/transform in the style of a UI control without going in and coding it.

Going 2D to 3D is less straightforward unless you assume a cylindrical map and “wrap” the 2d around it, like a tin can label. And perhaps if we have a way to adjust how 3D patterns look in 2D, adding features like that would make sense and would have many applications. For something like that we’re previously talked about a renderPolar or something as well, to make it easier and allow a pattern to apply to different coordinate systems even if the map is cartesian.

Outside of PB, when I think of going from 3D to 2D its a projection. Like the map preview rendering 3D points in 2D browser window. I don’t know how well that would translate to low/medium density 2D LED setups though.

23

Yes, and that’s exactly the issue I’m having now:

I did a 3D map, but while my Y is correct (I made that height), my X and Z (essentially the circular components) are narrow and limited to a small range. I’m debating the right way to handle this, and so for fun, I put a controller with WLED onto it (actually onto the second unit, which I just built, and photos coming soonish) and immediately found a bug (it didn’t handle inexact matrixes correctly, so 11x27 is 297, and it would only light 3 rows till I changed it from 300 to 297 pixels) but I’m noticing that doing X as the 11 (so a wrap around the tin can) means that it’s a decent XY for things that only understand 2D.

But others don’t look right at all. There is no One True Way.

I’m going to go thru patterns with a few setups simultaneously. Like maybe a 1D strip, a 2D matrix panel, a lamp setup in 2D, a lamp setup in 3D, and see if there is a way to make “do the right thing” in all cases, or a way to at least make it a config. And yes, render_polar would be interesting, essentially when you do the X wrap on a cylinder, it’s really just polar (X becomes the angle, Y becomes the height, R is meaningless since all pixels are R from the central axis)

Now I just need to add “lava lamp simulator” to my to-do list, as my GF basically wants these giant 4-5 tall lamps to become that.

@zranger1, you’ll be happy to know that of ALL of the fire patterns, including on WLED (1D and 2D), Doom 2D 2.0 looks best on these lamps, according to her (and me too). I have to turn the dragon off though, as it’s way too much white at the base. Might want to add another dragon option with less white.

24

@Scruffynerf
Cube fire might be a good start for a lava lamp. I’ve played with it to make something similar on PB cubes where it moves mostly in one direction continuously. Maybe a merge of cubefire and rainbow melt.

25

Yeah, and I’ve seen metaballs used too. But I want a real lavalamp, so I’m looking at this code:

https://catkane-doodles.github.io/lava-lamp/

It warms the wax and those bits float upward… And as they cool, they drop back down. [warning - takes quite a while to warm up, just like a real lava lamp. I’ll have to figure out a jumpstart for it, like randomly warmer bits maybe.]

This one is built on top of a retired physics engine, but… it works.
http://wellcaffeinated.net/PhysicsJS/examples/lavalamp/

Ok, my own repo of the lava is a bit faster (massively increased heat source),

https://scruffynerf.github.io/lava-lamp/

and the code looks simple enough that a PB port will be possible, especially compared to the dozens of other projects I looked at, either more complex,.or worse: “lava lamp” (including led ones) that didn’t actually do “lava lamp” just plasma etc.

So hopefully this will be an actual lava lamp pattern, maybe first of it’s kind.

26

In Doom Fire, down near the end where it finally gets around to setting the pixel color, there’s a line:

hsv(baseHue+((0.05*bri)), 1.3-bri/4,baseBri * bri);

To decrease the white - the amount of desaturation of really hot pixels - change the constant 1.3 to something higher. All white will disappear at around 2.0, so maybe 1.75 or 1.8 would be about right.

I almost put a slider in for this, but figured I was already overcomplicating things. It’ll go in the next rev.

And I’m looking forward to what you come up with in the way of lavalamp. That ought to be super cool!

4 Likes
27

For example consider a square matrix wrapped around a cylinder with a circle matrix on the end.

If you just want this to be treated as one shape and render to that like a canvas its easy enough.

If you want to target these two panels with different patterns or use cases you have to write a multi-segment pattern. Or use multiple PBs and communicate between them via some external mechanism.

if you want to run the same pattern on both displays like scrolling text , the pattern needs tweaking. Even though text scrolling pattern would/could work fine on either display mapped by itself - just not with a map using “compound shapes”

I think a MUCH better LONG TERM approach is to simulate how multiple boards work today, kind of like setting up micro-services or virtualization or containers to handle different aspects of the overall layout. Maybe its not in the map or multiple maps as much as the ability virtualize a portion of the LEDs and map those to a pattern and run more than 1 pattern simultaneously.

For example.

In a pattern - have the ability to specify index start/stop as a parameter, not defined in the code, and to be clear the code should not even have To know about this constraint on which LEDs the pattern renders to by index) Then you can “target” the pixels that pattern renders to. Sort of like you can do with the serial expander config.

Would also want to be able to run more than 1 pattern at the same time targeting different sections of the overall mapped LEDs.

Then you can easily have an UX input/output text scrolling running on the Circle, with a few Digital pins, and then run any random flashing pattern on the Square matrix - as CONTROLLED by the pattern running the UX/ I/O Pins.

Several different concepts here, but ALL working together to make ‘ALL’ patterns ‘more’ “portable”.

Multiple pattern rendering could make it easier to re-use patterns together rather than always re-writing something new for multi-segment scenarios.

Ultimately the goal is to increase the ability to re-use an existing pattern in new ways rather than always needing to re-write a pattern to use it in a new way.

Conceptually - I dont really see this as multiple sandboxes running different patterns as much as i see as multiple threads. Ideally the separate patterns are running in the same global state, or have some IPC mechanism between them.

I know i can do that all with 1 pattern and after it’s done, i have exactly 1 ‘concrete’ pattern that works ‘correctly’ on this project and if i want another one it needs to all be coded up again…

RATHER THAN : just picking some random pattern from the library and defining the space it can render to, the square…in this example.

or i can run some random pattern from the library and loose the ‘customization’ for the project.

To me — either way is sub-optimal and there should be some middle ground so you dont have to re-write every pattern to work with something custom.

lots of different concepts there, but all similar in that — ‘everything’ does not belong in the pattern rendering code routines…

1 Like
28

I understand your view… BUT… the goal of mapping is to abstract, not to compartmentalize. To remove the differences between different LED setups and allow a pattern to run anywhere.

As for running multiple patterns, right now, we have both a multi-segment pattern and a multi-“map” pattern, which are super flexible and would allow people to use that technique to run whatever they want. What we don’t have is the ability to run more than one pattern at once, but it’s on the todo list, (or some way to import code)

Yes, I agree, it’s sub-optimal right now, but it’s also running on an esp32, and so we’re limited in terms of cpu/space. Given that limit, what we do have is pretty awesome.

2 Likes
29

Hi Beta testers!
Fresh update coming your way, a release candidate with more polish. In addition to above:

  • You can use recovery.html if in setup mode (most of it, the online update won’t work since it’s not online)

  • Updated css library (bootstrap)

  • Added arrayReplace and array.replace, and improved the efficiency of array literals a little more.

  • Updated docs for the new functions and array literals

  • Remove the fail-safe that would put PB in wifi setup mode when it restarts frequently. This caused more problems / headaches than it solved.

  • Holding the button during start / power on will enter WiFi setup mode. It will flash the orange status LED until you release the button.

  • Standard v3.19c.pb32.stfu (1.3 MB)

  • Pico v3.19c.pico32.stfu (1.3 MB)

If you update with these, please leave a comment and let me know how it goes, even if everything is OK!

2 Likes