Chris Huff 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?
	Whatever you do, you'll need a unique internal representation (which
should probably be rgb to avoid breaking something elsewhere in the
code). If Color.(x/y/z) is to make any sense, it would be with relation
to this internal representation. I personnally would favor using
Color.red or Color.hue...

> 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;
> 
	This makes for more things to type and isn't any clearer or easy to
understand. Moreover, if you need to remember in wich space you defined
each color, you're in for a lot of bugs in your scenes ("Why the h*** is
that sphere white instead of blue???")

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


-- 

* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************

Post a reply to this message

In article <3a0a439b@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> There's a very good reason for using POV_REALLOC etc.: garbage 
> tracking and collection.  By using the POV_*ALLOC functions, it is 
> much easier to track down memory leaks.

But that won't help you figure out if there is a bug in POV_REALLOC(). 
:-)
I can understand working around it using the POV_*() functions, but I 
was talking about figuring out where the problem was. Oh, well...there 
are a couple places in my work with glows that could use POV_REALLOC(), 
I will try to figure it out myself...


> >Hmm, my copy of "3D Graphics Programming" has some explanations of
> >cubic, Hermite, and Bezier splines...not that I can make much sense of
> >it. Not much in the way of examples either...mostly just the math.
> I'll see what Vahur Krouverk's code is like for this.

And I'll poke around in the "other" spline patch...I think it had 
something like a "rational bezier spline".

-- 
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 <3a0a3db8$1@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> The next version of SkyPOV will be released when I've managed to get the
> splines working properly.

No hurry. :-)
I have plenty of other coding stuff to do(I think I finally got glows to 
attach to objects properly!), and plenty of other stuff that I *should* 
do...MP+ 0.6a mod 0.1 will have some other new stuff.

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

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

It becomes an even better idea when you add blurred transparency, etc.
Other programs do it because they often use image maps that use the 
alpha channel to define transparency...but does *tranparency* really 
belong in a *color*? Especially in POV, where image maps are relatively 
rarely used.

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

Mark, did you ever post a Windows binary? Sorry, but my newsgroup time is
limited and this thread is full of messages...

Grim

Post a reply to this message

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