Arbitrary number of pixel attributes in the mapper &| choose not to normalize map values

Feature Ideas + Requests
1

I have a tendency to use the mapper in a hacky way. I use what is ‘supposed’ to be a physical coordinate to store other information about the pixels.

For example, I’m working on this cornhole project:

image
image1536×2048 334 KB

And in addition to the X and Y coordinates of each pixel, I want to know if that pixel is in the ring and what clock position in the ring it is. I also accidentally mixed LEDs with different RGB order, so I need to track which pixels need to be corrected in software. All this meta information is stored in the Z coordinate, so I get this weird generated map:

image
image405×429 18.9 KB

image
image524×617 28.1 KB

It works, but it’s pretty hacky and difficult to parse out several different attributes from one numerical value that has been normalized between 0 and 1.

So my request it either implement some sort of function override for render() for an arbitrary number of parameters, e.g. if you mapped each pixel to have 8 values, then you could call

render(a, b, c, d, e, f, g, h){
   …
}

Or the other, probably easier thing to implement is an option to not normalize map values at all and leave them exactly as they were entered into the mapper.

3 Likes
2

I have made this kind of hack too! My next step would have been copying arrays of metadata into every pattern :frowning: . We need meta data separate from location data, e.g. by adding an extra optional argument:

render{,2D,3D}(index, x[,y[,z]][,meta]) {
    ...
    if( meta[23] == 17 ) { // Pixel is part of the harbinger hegemony
        fgunp = 37; // Adjudicate appropriately
    }
    ...
}
3 Likes