I am suddenly not sure. Is it possible to read a colour at a defined 
point - using trace() - on the surface of an object, by using 
eval_pigment() at that point? I know how to do it with an image_map as 
intermediary but can it be done directly?

For instance, if object{A} has a texture{B} and trace() finds a position 
P=<x,y,z> on the surface of A, would the colour at P then be 
D=eval_pigment(A,P) ? That obviously does not work as A is not a 
pigment. However, I would like to do something like that but do not know 
how.

Thomas

Post a reply to this message

On Tue, 11 Nov 2014 17:36:22 +0200, Thomas de Groot <tho### [at] degrootorg>  
wrote:

> I am suddenly not sure. Is it possible to read a colour at a defined  
> point - using trace() - on the surface of an object, by using  
> eval_pigment() at that point? I know how to do it with an image_map as  
> intermediary but can it be done directly?
>
> For instance, if object{A} has a texture{B} and trace() finds a position  
> P=<x,y,z> on the surface of A, would the colour at P then be  
> D=eval_pigment(A,P) ? That obviously does not work as A is not a  
> pigment. However, I would like to do something like that but do not know  
> how.
>
> Thomas
>

It would be wonderful if it worked on uv-mapped meshes as well :)

-- 
-Nekar Xenos-

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I am suddenly not sure. Is it possible to read a colour at a defined
> point - using trace() - on the surface of an object, by using
> eval_pigment() at that point? I know how to do it with an image_map as
> intermediary but can it be done directly?
>
> For instance, if object{A} has a texture{B} and trace() finds a position
> P=<x,y,z> on the surface of A, would the colour at P then be
> D=eval_pigment(A,P) ? That obviously does not work as A is not a
> pigment. However, I would like to do something like that but do not know
> how.
>
> Thomas

Since Trace only returns the point of intersection and the normal vector, and
there's really no way to query object attributes, the best I'd think you could
do is pass the intersection Point and the pigment to eval_pigment...

Although... You might get more information from a function.   It's worth
investigating.

Regards,
A.D.B.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
 > Thomas
>
> Since Trace only returns the point of intersection and the normal vector, and
> there's really no way to query object attributes, the best I'd think you could
> do is pass the intersection Point and the pigment to eval_pigment...
>
> Although... You might get more information from a function.   It's worth
> investigating.
>
> Regards,
> A.D.B.

That would be of help in very simple situations only. First the object must have
a pigment only and not a more complicated texture or worse an uv-mapping. Second
you must invert all transformations applied to the object after coloring it.

I can understand the wish by Thomas since one can e.g. plant grass of different
length at the object depending on the color - just a stupid idea. In fact I used
color maps, which can be evaluated with eval_pigment, sometimes to determine the
kind of vegetation in a landscape with a corresponding shape.

May be it is possible to implement it into the trace()-statement as a third
return value, but this issue and the effort necessary I cannot judge.

Best regards,
Michael

Post a reply to this message

I searched around a bit, but didn't seem to find much of use.
There was some mention of coupling trace with eval_pigment, but I didn't see any
code or elaboration on that idea...

What's an "object pigment"?
It seemed to be something along the lines of

pigment {object {Something} }

Is / was that some sort of experimental thing / MegaPov?

Maybe LeForgeron knows a way to do this - he's got a ton of clever stuff that he
works on...

POV-Ray obviously needs to work with just such information in order to generate
the rendered image.   I wonder if there's a way to patch into that, or write a
separate object property querying function...  y'know, for 4.0....

Post a reply to this message

> I searched around a bit, but didn't seem to find much of use.
> There was some mention of coupling trace with eval_pigment, but I didn't see any
> code or elaboration on that idea...
>
> What's an "object pigment"?
> It seemed to be something along the lines of
>
> pigment {object {Something} }
>
> Is / was that some sort of experimental thing / MegaPov?
>
> Maybe LeForgeron knows a way to do this - he's got a ton of clever stuff that he
> works on...
>
> POV-Ray obviously needs to work with just such information in order to generate
> the rendered image.   I wonder if there's a way to patch into that, or write a
> separate object property querying function...  y'know, for 4.0....
>
>

object pigment is a block pigment, in a way, similar to checker. It 
demand 2 pigments or textures: The first to be used inside the reference 
object, and the second to be used outside.
It's used on an object larger than the controll object.
A use would be to add some text to an object, that text been controled 
by a text object. You can then use a warp to have that text warp around 
some object.

Post a reply to this message

On 11-11-2014 18:31, MichaelJF wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>   > Thomas
>>
>> Since Trace only returns the point of intersection and the normal vector, and
>> there's really no way to query object attributes, the best I'd think you could
>> do is pass the intersection Point and the pigment to eval_pigment...
>>
>> Although... You might get more information from a function.   It's worth
>> investigating.
>>
>> Regards,
>> A.D.B.
>
> That would be of help in very simple situations only. First the object must have
> a pigment only and not a more complicated texture or worse an uv-mapping. Second
> you must invert all transformations applied to the object after coloring it.
>
> I can understand the wish by Thomas since one can e.g. plant grass of different
> length at the object depending on the color - just a stupid idea. In fact I used
> color maps, which can be evaluated with eval_pigment, sometimes to determine the
> kind of vegetation in a landscape with a corresponding shape.

Yes, that is what I generally do too and it works fine. My question in 
fact derives from that usage and a solution would be a smart addition 
but I am afraid it is not really possible.

>
> May be it is possible to implement it into the trace()-statement as a third
> return value, but this issue and the effort necessary I cannot judge.

Yes, that would be the logical thing indeed.

Thomas

Post a reply to this message

On 12.11.2014 9:10, Thomas de Groot wrote:

>> May be it is possible to implement it into the trace()-statement as a
>> third
>> return value, but this issue and the effort necessary I cannot judge.
>
> Yes, that would be the logical thing indeed.

it's not quite the same thing, but the camera_view pigment
in MegaPOV might help in some cases.

Post a reply to this message