<Jer### [at] enstfr> wrote:

> 	Why not? Actually, red SOMETHING hue SOMETHING does make sense: first
> work in rgb color-space and change red without touching green and blue,
> then work in hsl and change hue without touching saturation or
> brightness...

But what would the resulting vector be? Would it be a rgb vector, or a 
hsl, etc...
#declare Color = color red 0.6 hue 0.75;
Is Color.x red or hue? Is Color.y green or saturation?
"color rgb" should only accept red, green, and blue...


> 	This would make for an easy way to get the grayscale equivalent of a
> color for example (color rgb <whatever> saturation 0) or other effects
> of the kind...

I think this would be better done with color conversion functions, not 
the color specification. The idea is that you pick a color space and 
then set each component, when you try to set a component that isn't part 
of the color space things get messy. To get the grayscale of a color, it 
would be something like:
#declare Color = color rgb rgb_to_hsl(<whatever>).z;


> 	I prefer to have the color and transparency defined together (the way
> they are now) since they usually follow the same pattern. Needing to
> specify the pattern twice would be redundant, more difficult and
> error-prone...

It could be done so you don't have to specify the pattern twice, and it 
would give much more flexibility. And I never have understood why 
transparency was considered part of the color...the only explanation I 
can think of is that it developed from the use of alpha channels in 
images. It seems more of an interior feature to me, or a separate 
texture attribute.
And they usually follow the same pattern because it would be very 
difficult (impossible?) to get them to do otherwise with the current 
syntax. If it was easily possible to do it differently that might not be 
the case.

-- 
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