OK, my curiosity has finally reached the point where I want to start playing
around with eval_pigment.  But a few questions first (perhaps naive ones) so
that I don't end up guessing at the results:

1) Does it return specifically a COLOR vector (i.e., does POV-ray treat the
result as such internally, as another pigment); or just a 'generic' vector, with
no color information implied? (The manner in which it is returned has
consequences if I want to pull just one component out of the vector later, using
dot notation--see 3.2.1.5.5 "common color pitfalls" in the docs.)
2) How many components are in the returned vector--3 or 5?

Thanks!

Ken

Post a reply to this message

eval_pigment returns a color-vector.

the following is an excerpt from my LED macros:
#macro Display(mS, tS, mD, Image)
#declare mI =
pigment {
 image_map {
  jpeg Image
  map_type 0
  interpolate 4
  once
  }
  translate <-0.5, -0.5, 0.0>
  scale <mS.u, mS.v, 1>
  rotate 90.0*x
 }
#local a = mS.u / tS.u;
#local b = mS.v / tS.v;
#local bO = cylinder { -0.125*y, 0.015625*y, 1.875*ft }

#local rC = 0.0*b;
#while(rC <= 1.0*b)
 #local tC = 0.0*a;
 #while(tC <= 1.0*a)
//#if(inside(bO, <(-mS.u/2)+(tS.u*tC), 0.0, (-mS.v/2)+(tS.v*rC)>) != 0.0)

#local Color = eval_pigment(mI, <(-mS.u/2)+(tS.u*tC), 0.0,
(-mS.v/2)+(tS.v*rC)>);
#local Shade = (
 Color.red +
 Color.green +
 Color.blue ) / 3 ;

#local rS = Color.red ;
#local gS = Color.green ;
#local bS = Color.blue ;
 ColorBlock(rS, gS, bS, transform { translate <(-mS.u/2)+(tS.u*tC), mD,
(-mS.v/2)+(tS.v*rC)> })

// Diode(0, Red, Shade, transform { translate <(-mS.u/2)+(tS.u*tC), -mD,
(-mS.v/2)+(tS.v*rC)> })
//#end
 #local tC = tC + 1;
 #end
#local rC = rC + 1;
#end
#end

The macro turns an image into a mosaic of tiles containing three colored LEDs
and sets the Diode shades to the value of the rgb components.

I assume the vector is three values, I haven't seen any indication that
eval_pigment takes an alpha channel into account.

A.D.B.
"Kenneth" <kdw### [at] earthlinknet> wrote:
> OK, my curiosity has finally reached the point where I want to start playing
> around with eval_pigment.  But a few questions first (perhaps naive ones) so
> that I don't end up guessing at the results:
>
> 1) Does it return specifically a COLOR vector (i.e., does POV-ray treat the
> result as such internally, as another pigment); or just a 'generic' vector, with
> no color information implied? (The manner in which it is returned has
> consequences if I want to pull just one component out of the vector later, using
> dot notation--see 3.2.1.5.5 "common color pitfalls" in the docs.)
> 2) How many components are in the returned vector--3 or 5?
>
> Thanks!
>
> Ken

Post a reply to this message

> OK, my curiosity has finally reached the point where I want to start playing
> around with eval_pigment.  But a few questions first (perhaps naive ones) so
> that I don't end up guessing at the results:
>
> 1) Does it return specifically a COLOR vector (i.e., does POV-ray treat the
> result as such internally, as another pigment); or just a 'generic' vector, with
> no color information implied? (The manner in which it is returned has
> consequences if I want to pull just one component out of the vector later, using
> dot notation--see 3.2.1.5.5 "common color pitfalls" in the docs.)
> 2) How many components are in the returned vector--3 or 5?
>
> Thanks!
>
> Ken
>
>

It should return a 5D vector, or what can be caled a full colour vector:
<red, green, blue, filter, transmit>
You can extract each components with:
.x or .red for the red component
.y or .green
.z or .blue
.t or .filter
.transmit

Internaly, there is little difference between a 3D colour vector, a 
location vector, a translation vector and a rotation vector.
<1,2,3>.x will return the same thing as <1,2,3>.red



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> Internaly, there is little difference between a 3D colour vector, a
> location vector, a translation vector and a rotation vector.
> <1,2,3>.x will return the same thing as <1,2,3>.red

Sorry for the delay--POV-Ray 3.6.1 crashed on me yesterday (no fault of it's
own), and I'm having problems installing 3.6.2 for Windows...so I can't test
anything out right now, or even read the 'Help' files.

But back to your reply: I'm not so sure that's correct (although I could be
wrong); the fault may be in how I worded my original questions.

I'll assume that eval_pigment returns a 5-component vector, as you say.

Here's an example of what concerns me: I can #declare a 5-component vector one
of two ways...
#declare my_vector = <.1,.8,.5,.3,.4>;
// or...
#declare my_vector = rgbft <.1,.8,.5,.3,.4>;

I call the first example a 'generic' vector, with no color information attached.
If I use a dot operation on it--like my_vector.y--it will (or should!) give me
just that component-- .8 --- as a simple single float value, AFAIK. If I do the
same with the 2nd example--which POV sees as a COLOR vector--then my_vector.y
will return <.8,.8,.8,.8,.8>---no longer a float but another 5-component vector
(described as one of the 'common color pitfalls' in the documentation, if I
understand it correctly.) If I don't 'correct' for this situation, it could have
unintended consequences later, depending on how I use my_vector.y

SO...the real question I have is, does eval_pigment give me just
<.1,.8,.5,.3,.4> or rgbft <.1,.8,.5,.3,.4>?

Ken

Post a reply to this message

> I call the first example a 'generic' vector, with no color information 
> attached.
> If I use a dot operation on it--like my_vector.y--it will (or should!) 
> give me
> just that component-- .8 --- as a simple single float value, AFAIK. If I 
> do the
> same with the 2nd example--which POV sees as a COLOR vector--then 
> my_vector.y
> will return <.8,.8,.8,.8,.8>---no longer a float but another 5-component 
> vector
> (described as one of the 'common color pitfalls' in the documentation, if 
> I
> understand it correctly.) If I don't 'correct' for this situation, it 
> could have
> unintended consequences later, depending on how I use my_vector.y
>
> SO...the real question I have is, does eval_pigment give me just
> <.1,.8,.5,.3,.4> or rgbft <.1,.8,.5,.3,.4>?

I think you are missunderstanding vector promotion and
extraction (demotion).

The color keyword (color, rgb, rgbft) triggers promotion of smaller
vectors and floats to the specified vector size. The dot operator
extracts one component as a float.

So
#local a=<0.1,0.8,0.5,0.3,0.4>.x;
is a float, where a == 0.1
but
#local a= rgbtf  <0.1,0.8,0.5,0.3,0.4>.x
is a 5D vector, where a == <0.1,0.1,0.1,0.1,0.1>
first the dot operator demotes the vector to a float,
then rgbtf  promotes it back to a 5D vector.

There is no type difference in POV between a
5D vector specified with color keywords or without.

Promotion of vectors makes for a nice shorthand...
Things like
translate 1.2*x
since x is a predefined vector <1,0,0> and
the 1.2 gets promoted to <1.2,1.2,1.2>, it ends up <1.2,0,0>
in this case a 3D vector. Vectors get promoted to the expected
levels... 5D for colors.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:

> I think you are missunderstanding vector promotion and
> extraction (demotion)....
>

> ...There is no type difference in POV between a
> 5D vector specified with color keywords or without.
>

Thanks for the reply.  I'm still trying to make clear sense of that.  :-)

Now that I have POV-Ray back up and running, I need to do some tests (with
eval_pigment, probably a good test platform) to fully understand where my
misconception lies re: dot operators and colors. Your reply shows me that I'm
making a subtle mistake in my thinking, somewhere. Thanks again.

Ken

Post a reply to this message