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

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