Open sidequestboy opened 9 years ago
The dramatic color changes resulting from "overflowing" values are prominent in almost any(every?) pattern you can input . They probably do get in the way of the toy's usefulness as an education tool, and obfuscate the relationship between the function you input and the result you see, but the illusions of shapes and lines moving across the canvas is a positive artifact that I don't want to lose. One other way to approach this issue is by experimenting with other color formats like HSL or HUSL(1) (probably keeping saturation as 255 to avoid mushy colors). Overflowing values would still create discontinuities but they'd have different effects. I like your idea about separate equations for each color, imagine there's a lot of room for creativity there:
Thanks for writing up this issue, even though it's probably going to remain open
Comparison operators (issue #12) would make this solvable within the formula itself: compute a value for each of r, g, and b, apply bounds to them, and combine them.
However, for convenience, it would also be nice to have functions like rgb(r, g, b) and hsl(h, s, l).
Right now, a pixel function continuous in time is visually discontinuous in colour. This happens because the RGB colorspace represented as an integer between 0x000000 and 0xFFFFFF abruptly goes from e.g. 0x0000FF to 0x000100 in one timestep (which is full blue to near black). To see an example, try simply
time
as the input function.This could be solved by having the user specify three continuous functions (one for each of R,G,B), and ensuring each of those functions have no color discontinuities e.g. by truncating their values at 9 bits, and using the mapping:
Note that the above is only one possible way to make the mapping continuous (and of course there's the possible integer overflow of time that I haven't dealt with).
Of course, you might disagree that having colour discontinuities is even a bad thing.