On Wed, 01 Sep 1999 10:19:45 -0700, Jerome M. BERGER wrote:
>It depends on the way sky_color is defined and on the way povray treats
>#declare... If sky_color is declared as a+b (no parethesis) and pov
>simply replaces (the way it works in c/c++)

It doesn't.  It computes the value of a+b at the time the #declare is
parsed and puts the result in the "variable."

I'd guess that it's something odd about the way division works with
vectors.  Try multiplying by .5 instead of dividing by 2.  If that
works, it's probably a bug that should be looked at.

Post a reply to this message

> It doesn't.  It computes the value of a+b at the time the #declare is
> parsed and puts the result in the "variable."

As one would expect.

> I'd guess that it's something odd about the way division works with
> vectors.  Try multiplying by .5 instead of dividing by 2.  If that
> works, it's probably a bug that should be looked at.

It did not work. It still renders incorrectly.

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

I tried something new. I added the keyword "color" before the formula
and it set the values straight. I don't like this. How come without that
keyword the other expression works, and without it the compact one
doesn't? I did a #debug on the value of the #declare'd variables and
look at this:

 #declare b=(sky_color+White)/2;   //ugly
 #declare p=(sky_color*.5+White*.5);   //nice

 #debug concat("B = ",str(b.x,0,3)," ",str(b.y,0,3)," ",str(b.z,0,3),"
P = ",str(p.x,0,3)," ",str(p.y,0,3)," ",str(p.z,0,3),"\n")

See for yourselves how much B differs from P. I don't understand how
this can generate such different results. At any rate, when you add
"color" to the UGLY pigment declaration, it becomes NICE. :P

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

On Wed, 01 Sep 1999 14:10:59 -0400, TonyB wrote:
>I tried something new. I added the keyword "color" before the formula
>and it set the values straight. I don't like this. How come without that
>keyword the other expression works, and without it the compact one
>doesn't? I did a #debug on the value of the #declare'd variables and
>look at this:
>
> #declare b=(sky_color+White)/2;   //ugly
> #declare p=(sky_color*.5+White*.5);   //nice
>
> #debug concat("B = ",str(b.x,0,3)," ",str(b.y,0,3)," ",str(b.z,0,3),"
>P = ",str(p.x,0,3)," ",str(p.y,0,3)," ",str(p.z,0,3),"\n")
>
>See for yourselves how much B differs from P. I don't understand how
>this can generate such different results. At any rate, when you add
>"color" to the UGLY pigment declaration, it becomes NICE. :P

I did this myself and discovered the same thing.  I went further and looked
at the parser to see why, and it is indeed a bug.

By the way, I didn't get the same results you did.  I determined that
when the expression is in parentheses, or in any other way doesn't start
with a token that explicitly identifies it as a color, it parses as
a vector which is then promoted to a color, but the promotion is not 
done correctly.

In parse.c, in the function Parse_RValue, in the case where Terms is 5,
(search for "case 5" without the quotes) there was a line that said

            Assign_Colour(*DataPtr, Local_Express);

This is wrong, because Assign_Colour is a memcpy and Local_Express is an
array of DBL's, not of COLC's, and doesn't have the same layout in memory.  
This should read like so instead

            for (i=0;i<Terms;i++)
    	      ((COLC *)(*DataPtr))[i]=(COLC)Local_Express[i];

Don't forget to add a declaration for i at the top of the function.

This message has been crossposted to povray.bugreports, but followups 
remain in povray.general.  Please keep any discussion in .general.

Post a reply to this message

Oooh. This is so exciting. *I* found a bug. Wow... I'm overwhelmed. I must sit
down, oh, yeah, I'm already seated. I must faint... (thud...)

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

TonyB wrote:
> 
> Oooh. This is so exciting. *I* found a bug. Wow... I'm overwhelmed. I must sit
> down, oh, yeah, I'm already seated. I must faint... (thud...)
> 
> --
> Anthony L. Bennett
> http://welcome.to/TonyB
> 
> Non nova, sed nove.

Try not to get too excited about it. They are not supposed to be there.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

TonyB wrote:
> 
> Oooh. This is so exciting. *I* found a bug. Wow... I'm overwhelmed. I must sit
> down, oh, yeah, I'm already seated. I must faint... (thud...)

Fine.  Now go search for bugs in Win98, and come back when you got them
all... :)

There is another strange behaviour of pov with colors : 
 pigment {checker Red White} gives the default green/yellow checker !!!

but
 pigment {checker color Red color White} gives white and red, as
expected...

Fabien.

Post a reply to this message

On Thu, 02 Sep 1999 18:00:09 +0200, Fabien Mosen wrote:
>TonyB wrote:
>> 
>> Oooh. This is so exciting. *I* found a bug. Wow... I'm overwhelmed. I must sit
>> down, oh, yeah, I'm already seated. I must faint... (thud...)
>
>Fine.  Now go search for bugs in Win98, and come back when you got them
>all... :)
>
>There is another strange behaviour of pov with colors : 
> pigment {checker Red White} gives the default green/yellow checker !!!
>
>but
> pigment {checker color Red color White} gives white and red, as
>expected...

Crossposted to bugreports, followups to general, as usual.

This was reported a long time ago but never resolved.  It's actually
bigger than you think: any time two or more colors appear in a row with
no intervening commas or other stuff, POV will happily parse them all 
away, keeping only the value of the last one.  This means you COULD say
something like "color Red green 1" to get yellow.  In fact, that usage
is documented (but uncommon in the real world, I suspect.) 

Unfortunately, you can also say "color Red Green" and get green.  This 
is not documented, and is probably a bug (the docs do say COLOUR_IDs 
should come first.)  Parse_Colour should probably UNGET and EXIT when
it gets a second instance of any of COLOUR_ID, rgb, rgbt, rgbf, rgbft, 
or a bare vector expression.  This would make rgb 1 red 0 legal as a 
shortcut for cyan, but make rgb 1 rgb 0 become two separate colors,
suitable for use in checkers or bricks or hexagons.

Post a reply to this message

TonyB wrote:

> Hello. I am having a small math problem. All my life I have found this
> to be true. I even tried it on paper, and it works.

> A/2 + B/2 = (A + B)/2

	Yes. 

> Am I wrong? The reason I ask is because of something that happened to me
> while playing with Jaime Vives' clouds. The line that reads:

> #declare p=sky_color*.5+White*.5;

#declare p=(sky_color*.5)+(White*.5)

> *can* be re-written as:

> #declare p=(sky_color+White)/2;

> right? 

	As I wrote it, yes. 

	I have not tested it but interpretors and compilers and parsers
have their rules of evalution of operators such as * a +. *
should come before + as you assumed. Your first version may be
confusing the POV parser. BUT any well behaved software ALWAYS
obeys parenthesises. When in doubt, use them. 

	They are well behaved becaues their noses get rubbed in it if
they do not obey parenthesises. 

	BTW: Has anyone identified the parser used and where to find the
specs for it?

Post a reply to this message

On Sun, 05 Sep 1999 03:18:59 -0400, Matt Giwer
<mgi### [at] giwersworldorg> wrote:

<snip>
>	BTW: Has anyone identified the parser used and where to find the
>specs for it?

The parser is Chris Young's job, and a good one at that. I find his
code so easy to read and understand, mainly because of the use of
macros like EXPECT etc. And I am not really a programmer, mind you. A
couple of weeks ago I tried to make a parser with YACC for a program I
am writing and liked the ease, but when it came to tweaking the code
it generated, brrrrr! The POV parser OTOH has been designed to allow
for easy modification of existing and addition of new features, at
least this is the way I see it. I hope this answers your question.


Peter Popov
ICQ: 15002700

Post a reply to this message