POV-Ray : Newsgroups : povray.beta-test : color dot operators Server Time
30 Jul 2024 10:18:31 EDT (-0400)
  color dot operators (Message 1 to 6 of 6)  
From:
Subject: color dot operators
Date: 17 Dec 2001 07:37:18
Message: <ofpr1ug9r6q3cak417pmj72bck6ufmgbtg@4ax.com>
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.

#macro Test(Radius)
  sphere{0,Radius}
#end

#local Float=1;
#local Point=<2,3,4>;
#local Color=color rgb <5,6,7,8,9>;

Test(Float)          // works
Test(Point.x)        // works
Test(Color.red)      // not
Test(0+Color.red)    // works

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35


Post a reply to this message

From: Mike Williams
Subject: Re: color dot operators
Date: 17 Dec 2001 15:11:55
Message: <8+74wDA4AlH8Ewle@econym.demon.co.uk>

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

It was in beta-test.binaries:-


Re: Mosaic... some clarifications
(#local A2=P(1,2,3).hf; fails)
http://news.povray.org/9n9j1uo0mdlrs4i5toupujr0pqrj4vvb8d@4ax.com

I'm going to keep this one on the unconfirmed list. You didn't manage to
fool me by trying to confirm your own bug report.

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Slime
Subject: Re: color dot operators
Date: 17 Dec 2001 16:18:12
Message: <3c1e6114@news.povray.org>
> I'm going to keep this one on the unconfirmed list. You didn't manage to
> fool me by trying to confirm your own bug report.

Confirmed. I get the error "float expected but vector or color expression
found."

Win 98 Pentium III (900 mhz I think) 256 MB RAM... that should cover it...

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]


Post a reply to this message

From:
Subject: Re: color dot operators
Date: 18 Dec 2001 02:25:05
Message: <0nrt1ucganr0k9o3c4aeqpsemfa1trpol8@4ax.com>
On Mon, 17 Dec 2001 20:06:16 +0000, Mike Williams <mik### [at] nospamplease> wrote:
> I'm going to keep this one on the unconfirmed list. You didn't manage to
> fool me by trying to confirm your own bug report.

I think it is not the same. The problem with .hf operator was connected with
function engine. .hf was recognized only inside function. Problem with color
operator is that when you apply color operator then it return color instead
float.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35


Post a reply to this message

From:
Subject: Re: color dot operators
Date: 18 Dec 2001 04:02:13
Message: <l91u1uo5c9thqog30m86cohaqn9ie0h6q1@4ax.com>
On Mon, 17 Dec 2001 16:16:08 -0500, "Slime" <noo### [at] hotmailcom> wrote:
> Confirmed.

Thanks

> I get the error "float expected but vector or color expression found."

That's it.
And another short example of it:

#local A=<1,2,3,1>; // without 'color'
#local F=A.filter;
sphere{ 0 F } // works

#local A=color <1,2,3,1>; // with 'color'
#local F=A.filter;
sphere{ 0 F } // not

ABX


Post a reply to this message

From: Ron Parker
Subject: Re: color dot operators
Date: 26 Dec 2001 16:59:39
Message: <slrna2ki2e.c4m.ron.parker@fwi.com>

> 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.