|
|
> POV 3.5 b 8, Win NT 4 sp 6 on PII 233 , 128 MB
>
> I don't remember where but I think I have readed about my current problem
> somewhere on this newsserver. Currently I can't find it so I report it. I'm
> affraid it could be expected behaviour but I can't find any note about it in
> documentation.
It's semi-expected behavior in that that's the way it works. We decide what
the type of the expression is based on the first token in the expression, in
order to keep the parser logic manageable. Since the first token in your
expression is a color, even though the result is a number, we put it in a
color object (which is not quite the same as a vector) to pass it to the
macro. I've spent some time looking at this problem, but I don't see any
easy fix short of redoing a huge chunk of the parser.
I think another workaround is to add an extra set of parentheses around
expressions like this.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|