Hi!
I’m adding support for 1D pixel maps. It will work in much the same way, normalizing world units, etc. There’s been an x coordinate passed to render for a while (a shortcut for index/pixelCount), but will be mappable now. Handy if you have strips/strings and want to control the direction of animations. Existing 1D patterns would need a small update to take advantage of it, but that should be as easy as replacing index/pixelCount with an x parameter passed in to render(index, x).
For what it’s worth, the coordinate transformation APIs will also work on 1D maps, though probably a lot less interesting, but would make running 2D and 3D only patterns that use these APIs still work and hopefully be interesting on 1D setups, certainly more interesting than nothing.
I’m changing the logic around which render function is picked as part of this in order to try and minimize cases of “render function not found” and cases when your pixels are all black because of a pattern and map mismatch.
It will default to the highest dimensionality render function that it can find unless there’s an exact match. Missing dimensions are filled in with something in the middle of 3D space. With no map, x will default to index/pixelCount.
This is the resulting list of priorities:
- 1D map or no map:
render,render3D,render2D - 2D map:
render2D,render3D,render - 3D map:
render3D,render2D,render
I know many people are creatively using extra dimensions in pixel maps to add data, and I have ideas for adding support for data sets outside of the coordinate system. I don’t think this change would break those setups.
I’m also changing how unmapped pixels render. Before the change, if you had a map of e.g. 50 pixels but had 60 pixels in settings, those last 10 pixels wouldn’t render and would draw black. The render function wouldn’t even be called. With the change, all 60 pixels would get a render call, but there would be a new bit of state you could check to see if a pixel was mapped or not (something like inMap()), and your pattern could control how to handle those. They would get default coordinates using the above rules.
Given how many patterns have been made simpler by assuming that given a pixelCount it will only see pixels render with an index between 0 and pixelCount - 1 (valid indexes into an array of size pixelCount), I think it would make sense to keep calling render for the same number of pixels.
Another option might be some kind of mode or API to exclude these from render calls, or maybe just override the output of those renders with black.
That would enable future support for “ghost” pixels, basically some way to indicate that a given pixel somewhere in the middle, not just at the end, isn’t part of the map and needs special handling.
Thoughts?