Hi all. I have a Grasshopper (for Mac) “minor bug” or rather an irregularity to report:
I use the fantastic ColorWheel to generate “pseudo-random” numbers in the domain (0-255). The “colors” can be used as “pseudo-random” X,Y,Z coordinates, but only on the Windows platform. It seems like the RGB values are converted or “reparameterized” into a totally different domain than 0-255, when used as “points”. See the attached files. The larger GH definition is from Windows, the smaller is from Mac OS X.
This appears to be due to the point component being before the notes panel in the definition. If it is used after the notes panel the original values are maintained. I’m seeing the same behavior on Windows and Mac Grasshopper here so it looks like it’s by design… the reason for which I can’t say but at least it’s consistent and the order of the components controls the result.
If I’ve misunderstood the issue, please explain more and I’ll make sure it gets filed but at the moment I don’t see a discrepancy between Windows and Mac Grasshopper here. The point component when used directly from the color wheel output appears to map the values between -1 to 1 or as you said reparameterizes them.
Hi Brian. Technically the numbers are reparameterized from (0-255) to (-1 to 1), right?
What would be the easiest way to reparameterize to e.g. (-150 to 150)? If possible…?
The reason is that I want unit vectors to all convert into unique colours. This allows you to use tangent or normal vectors and immediately generate a colour map from them. They’re mapping to [-1, +1] for x, y and z rather than mapped to the unit sphere because it makes the maths significantly simpler and more predictable.
