Color Array/Steps : Blends : Creating a color matrix

please don't use data structure (arrays, matrices) for something like this.

(note: I got top and bottom upside down. oops. also, the math is a bit wrong, so it goes from 0.0 to 0.8 instead of 0.0 to 1.0. hopefully its enough to give you a rough idea.)

Very cool example, Chris.

@jersmi: thanks

I was a bit too lazy to fix the math the correct way, but I threw in a scaling term to make it work out correctly anyway.

Edit: looks like you beat me to it, Chris. No, wait, mine's different :)

Here's Chris' comp with adjustable grid size, width and height.

Javascript question: in this snippet, why the 0/0? I thought dividing by 0 was something to be avoided.

 else {
      result.valid = false;
      result.minX = 0/0;
      result.minY = 0/0;
   }

Not A Number, i believe. Its testable, and better than an un-initialized value.

@jersmi: yeah, that's an idiom for nan. Picking an arbitrary number (rather than not a number) would lead to bizarre behavior of the blenders when the mouse was out of range.

By the way, yours is much better generalized than mine - I'd advise people to use yours, rather than mine (yours allows a parameterized width and height, and configurable quantization levels.)

@vade: spot on.

#lol #TwoParentComment

Thanks to both parents. :)

One issue here with the lerp in the shader is that the grid doesn't show the pure RGB and white colors at the corners. Not sure how to adjust the shader to have the pure colors.

Edit: correction, red is 100%, blue, green and white not 100%. Be good to know proper way to fix this. And what about the mix vs lerp talk I see around?

Red's 100% because it's the 0 point on both X and Y axes. G, B, and W (frightening initials, I know) are at 1 points on either X or Y (or both, in the case of W) -- those aren't getting 1.0 as their lerp coefficient, but N-1/N (where N = quantize value). The shader and the color mixers both have the same "problem", which is why they still match, despite both being incorrect.

mix == lerp in the GLSL shader. I jump between ARB fragment programs, GLSL, CI, CL, and C enough that I never remember which language has which. Thanks for reminding me that GLSL does in fact have mix :)

Added the fix to your example, replaced lerp with mix. this is pretty close to finished, from what I can tell.

Okay, hmm. So in the shader, how can I make it so the color input for the corners matches the color I select in the color inputs? Do I define the lerp differently? I haven't looked closely but I guess you are saying the js has to change as well?

@cwright #glsl gradient

Oh, that's hot.

The shaded material patch is actually (well, I may be talking out my butt here), but is SEEMINGLY suited for normal map generation (I found this incidentally when I was on my jag on that from a while back).

By feeding it an appropriate gradient image (like this I suspect... maybe slightly different), I suspect one should be able to have it work like a good normal map generator. I've done it with less than ideal source (eg. making a signed gradient in gimp as an image.), and it works ok.

(Right now I feel like people are like "normals what?"... that's some of the coolest area for exploration and enhancement of QC looks, but people don't seem to get it or care maybe... I wonder how it can be explained better?).

Thankfully you don't have to throw Cg into the mix too! ;P

@ 0/0=nan ... too bad it didn't work in OpenCL 1.0 when I was trying it a year or so back...

Ohhhhh dude, are you doing a massive object detect patch by holding color texture? If so, kudos.

@jersmi #lol #anachronism #multiParentComment #ILessThanSlashThreeFlatThreads

My -final version updated the shader and the JS, so it all Just Works. The lerp's fine, it's that the alpha its being fed doesn't cover the 0-1 range, but 0-(N-1)/N), so it doesn't quite hit 1.0. Updates correct for that.

@gtoledo3 0/0 isn't quite safe in type-strict languages like C and probably CL -- 0 is the integer 0, and integer-divide-by-zero is a huge No-no. 0.0 is floating point 0, and that's ok to divide by zero. JS doesn't care, so I took the short route, but in other contexts you'd probably want 0.0 / 0.0, or a built-in NaN, if the language provides it.

We'll have to have an offline chat about shader-y languages sometime soon; I've learned some frightening (and not in a good way) stuff recently that you'd probably get a kick out of :)

@cwright #YouRock

cwright wrote:

We'll have to have an offline chat about shader-y languages sometime soon; I've learned some frightening (and not in a good way) stuff recently that you'd probably get a kick out of :)

Aren't we in a perpetual offline chat about shader-y languages ? lol.... Please do though ;)

Kinda interested in a BCC: there ;-)

Wow, pretty phenomenal both of you. I looked at all the code, got into the javascript on multiple patches. Amazing you pulled this off so fast. Would be nice to have the background color remain the last color touched, but I'm just grateful you shared this.

I made a slightly modified version with the topLeft and bottom etc, fixed. And I picked some colors that show halation better. File attached below. Again, thanks.

I was digging in to see if I could make the next page, spacing out the swatches, extending them to be poles and deleting the bottom row of colors, but got caught up in the javascript. http://colorisrelative.com/poles.html

Is this something that would be relatively straightforward to make?

BTW, I'm attempting to use this for acolorbox.com and just merged it with OSCeleton with fairly succesful results. Happy to share the file. And it has me wondering of ways to use different body movements to change the outside poles. With two users, one hand could change the color of the pole and the other could touch it to change the background. Just brainstorming.