On Wed, 08 Nov 2000 16:48:36 -0500, Chris Huff <chr### [at] maccom>
wrote:

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

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

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.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

GrimDude wrote in message <3a0b768a@news.povray.org>...
>Mark, did you ever post a Windows binary? Sorry, but my newsgroup time is
>limited and this thread is full of messages...


Yes.  Use the links from http://www.geocities.com/rengaw03/povray.html


--
Mark

Post a reply to this message

Thank you, sir!

Grim

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3A0A735E.A48E843C@tapasmail.net>, J?r?me M. Berger 
> <jbe### [at] tapasmailnet> wrote:

>>       Maybe, but OTOH you don't need to specify a color where the object is
>> fully transparent, so their patterns are related. I've never felt the
>> need to specify transparency independently from color...

> Simplest case: a multicolored transparent ball which is evenly 
> transparent and has a big color_map. You decide you want to change the 
> amount of transparency...you have to change every color in the 
> color_map. If you had it specified in a separate block, you would only 
> have to change one value. It would also make specifying transparence for 
> image_maps a lot easier.

Well, this, at least, is easy.  If you want a constant transparency that you
want to be able to change, just declare it as a variable (say, Trans) and
use that in your color map.  All you have to do is change one place.  I
often do this with variables that are used many places (the size of certain
objects in relation to one another, for instance), and are likely to be
changed while tuning the scene.

The transparency for image maps, I agree, though.

Geoff

Post a reply to this message

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

In article <3a0bf591@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Well, this, at least, is easy.  If you want a constant transparency 
> that you want to be able to change, just declare it as a variable 
> (say, Trans) and use that in your color map.

That is what you have to do now...
And what about blur and other transparency effects? Things like 
fade_color, dispersion, ior, etc. would also fit better in a block 
dedicated to simulating transparency. Transparency just isn't a color 
attribute, and has no business being there.


> The transparency for image maps, I agree, though.

And why not for all textures?

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

On Fri, 10 Nov 2000 17:25:04 -0500, Chris Huff <chr### [at] maccom>
wrote:

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

This seems overkill.

<snip>

I think it should be enough if colors are kept the way they are and
there are introduced parser functions to convert a 3D vector to and
from hsb and rgb. This will keep backwards compatibility and will
offer the user more power. I am not sure how useful this will be,
though, as everything here mentioned can be done with simple macros.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> 
> On Fri, 10 Nov 2000 17:25:04 -0500, Chris Huff <chr### [at] maccom>
> wrote:
> 
> >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.
> 
> This seems overkill.
> 
> <snip>
> 
> I think it should be enough if colors are kept the way they are and
> there are introduced parser functions to convert a 3D vector to and
> from hsb and rgb. This will keep backwards compatibility and will
> offer the user more power. I am not sure how useful this will be,
> though, as everything here mentioned can be done with simple macros.
> 
Seems reasonable. RenderMan Shading Language supports various color
spaces and conversion functions between them, but it is totally up to
coder to ensure, that correct color space is used. If this solution is
usable in "real CGI" world, then it could be used in "amateur league" as
well?
As Einstein said:
Keep it as simple as possible, but no simpler.

Post a reply to this message

In article <kn8v0tkg6h7ddc5j1q81ehvclvanuq06v1@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> I think it should be enough if colors are kept the way they are and
> there are introduced parser functions to convert a 3D vector to and
> from hsb and rgb. This will keep backwards compatibility and will
> offer the user more power. I am not sure how useful this will be,
> though, as everything here mentioned can be done with simple macros.

It would be very simple to do once you have the code for converting 
between the color systems. I can think of two possible ways of doing the 
syntax:
1: Separate rgb_to_hls(), rgb_to_cmy(), rgb_to_hsv() functions.
2: Three functions: rgb_to(COLOR_SYS, COLOR), to_rgb(COLOR_SYS, COLOR), 
convert_color(COLOR_SYS_SRC, COLOR_SYS_DEST, COLOR). This has the 
advantage of being simpler when there are a lot of color systems.

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

> It would be very simple to do once you have the code for converting
> between the color systems. I can think of two possible ways of doing the
> syntax:
> 1: Separate rgb_to_hls(), rgb_to_cmy(), rgb_to_hsv() functions.
> 2: Three functions: rgb_to(COLOR_SYS, COLOR), to_rgb(COLOR_SYS, COLOR),
> convert_color(COLOR_SYS_SRC, COLOR_SYS_DEST, COLOR). This has the
> advantage of being simpler when there are a lot of color systems.

Actually, this kind of function could be usefull for users, but if in
addition you want to improve the final quality of rendering, Spectral
Color Space has to be implemented into PoV. There's a BIG difference of
quality between an image rendered using spectral space and the same one
rendered in RGB...

S.M.

Post a reply to this message