 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
mr.art <mr.### [at] gci net> wrote:
> I just ran into something strange. While trying to
> pass a color vector through a macro, the color changed!
> The code is simple
[snip]
> If I #declare CapColor= a three or four component vector, it works
fine.
> But as a five component vector something doesn't work so well.
> Can anyone give some insight on this?
I think that second-last sentence is the clue: you don't actually want a
5-component vector, you want a colour. Therefore, if you declare your
CapColor as a colour variable, eg: #declare CapColor = rgbft <1, 0, 0,
0, 0>; you should find that everything works as expected.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha <war### [at] punarastascstutfi> wrote:
> It certainly looks like a bug. I don't know of any way of printing
the
> values of the vector when it has five components so I can't see what's
> happening. There seems to be no way to access the 5th component of a
vector
> and #write doesn't work for 5-dimensional vectors for some strange
reason.
> 5-dimensional vectors are obviously handled differently from 4 or
less
> dimensinal vectors, and perhaps the bug is related to that.
If the variable you want to pass is declared as a colour then everything
behaves as expected. Taking into account other seemingly 'strange'
behaviour (eg. what happens when you specify checker colours without
commas, or try certain colour arithmetic) I don't think I'd classify
this as a bug. Declaring a variable as a colour (using the color
prefix, or rgbft, etc.) also allows you to correctly access the filter
and transmit components using dot notation (although colours are not
supported by the #write function).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Does this mean that when povray expects a vector and it finds a 5-dimensional
one, it promotes it to a 4-dimensional vector?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well,
#declare Test=<0,0,0,0,0>;
#declare Test=<0,0,0,0>;
generates: error: Attempted to redefine colour identifier as 4d-vector
identifier.
But,
#declare Test=<0,0,0,0,0>;
#declare TestPig=pigment{rgb Test}
generates no error. My assumption is it discards what it doesn't need.
Nieminen Juha wrote:
>
> Does this mean that when povray expects a vector and it finds a 5-dimensional
> one, it promotes it to a 4-dimensional vector?
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3842979b@news.povray.org> , Nieminen Juha
<war### [at] punarastascstutfi> wrote:
> Does this mean that when povray expects a vector and it finds a
5-dimensional
> one, it promotes it to a 4-dimensional vector?
No, it tries to use memcpy to convert an array of doubles to an array of
floats ... look at the report posted in povray.bugreports and the source of
this strange error will be obvious. Fortunately it doesn't copy more bytes,
but less!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3842ACC3.D70701F8@gci.net> , "mr.art" <mr.### [at] gcinet> wrote:
> #declare Test=<0,0,0,0,0>;
> #declare TestPig=pigment{rgb Test}
> generates no error. My assumption is it discards what it doesn't need.
Nope, the error is very obsure from a non-programmer perspective.
In short it copies only some parts of the vector.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
