|
|
In article <in0n0ts7vbq5e22kq7rjlb04ib7t4od0pu@4ax.com>, Peter Popov
<pet### [at] usanet> wrote:
> Color.x is just a hack used by those who have been RTTL :) If you have
> Color.r and Color.hue, why use Color.x and make your life harder? Of
> course, for backwards compatibility it should be kept equivalent to
> Color.r
RTTL? Ray Tracing Too Long?
My syntax suggestion was to store all colors as 3D vectors and get rid
of the r, g, b, red, green, blue, etc... keywords.
> Another approach is to use rgb space and automatically convert hsb to
> it. So color hsb <2/3,1,1> would make a color rgb <0,0,1>. One may
> still access the hsb values of this color, though.
I still don't like the "automatically convert to rgb" part. If I set the
first component of a vector to 1, the first component should be 1 when I
come back to it later. If I set a color to hsb <2/3,1,1> and try to put
a sphere at the point in space equivalent to that point in hsb space
(say I am making a graphical representation of the relationships between
colors), I shouldn't get xyz < 0, 0, 1>!
On the other hand, automatic converting would probably make mixing
colors from different systems easier...
How about this: when you specify a color in a pigment or something, it
is converted to rgb for internal use, but color variables store the
color space as well as the components. You could get the rgb version of
a declared color with "rgb(COLOR)", the hsl version with "hsl(COLOR)",
etc. These conversion functions use the extra "color space" variable.
You get a parse error if you try to use ".hue" on a rgb color, ".green"
on a hsl color, etc.
Adding two colors or a color and a vector adds the values of their
components, ignoring the system they are from. To add two colors of
different systems, you would usually want something like: "rgb(COL_A) +
rgb(COL_B)" to be safe.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|