"Paul Bourke" <pau### [at] gmailcom> wrote:
> I am aware of the trace macro that returns the intersection point and normal at
> that point on a object given a ray (point and direction). But is there a way to
> get the colour?

I want this function, too. But I want it for UV map...

Post a reply to this message

Le 10/11/2018 à 05:20, And a écrit :
> "Paul Bourke" <pau### [at] gmailcom> wrote:
>> I am aware of the trace macro that returns the intersection point and normal at
>> that point on a object given a ray (point and direction). But is there a way to
>> get the colour?
> 
> I want this function, too. But I want it for UV map...
> 
> 
UV mapping of object does make sense (in term of trace), but I'm still
perplex about getting the colour...

There could be more than a single texture (layered), or a complex
texture, and there is finish too which can interfere (a white pigment
with a mirror finish reflecting a complex environment).

So, when asking for "colour" at intersection point, what is expected ?
#1: the colour (<r,g,b>) of the point as it would appear on a rendered
image (e.g. a white sphere in the dark would return black)
#2: the intrinsect colour(<r,g,b>) of the object at that point (e.g. a
white sphere in the dark would return white)

(Yes, I'm repeating C.Lipka's question, because it went unanswered)

Post a reply to this message

On 10/11/2018 04:20, And wrote:

On 11/11/2018 08:43, Le_Forgeron wrote:
>> I want this function, too. But I want it for UV map...
>>
>>
> UV mapping of object does make sense (in term of trace), but I'm still
> perplex about getting the colour...
> 
> There could be more than a single texture (layered), or a complex
> texture, and there is finish too which can interfere (a white pigment
> with a mirror finish reflecting a complex environment).
> 
> So, when asking for "colour" at intersection point, what is expected ?
> #1: the colour (<r,g,b>) of the point as it would appear on a rendered
> image (e.g. a white sphere in the dark would return black)
> #2: the intrinsect colour(<r,g,b>) of the object at that point (e.g. a
> white sphere in the dark would return white)
> 

I’ve thought about this in the past.
I think that your option #1 is too complicated. It seems to me that it 
would involve a secondary raytracing operation with maybe a limit to the 
depth of reflective and/or refractive bounces. (Sorry, I don’t have the 
right vocabulary.)
Option #2 is closer to what I would find useful. If “trace” also 
returned the RGB* value of the uv image map at the point of intersection 
of the object by trace. That would be usable.
* Also filter and transmit values, if possible.


> (Yes, I'm repeating C.Lipka's question, because it went unanswered)

Your option #2 opens up the discussion. Christoph's answer on first 
reading is too similar to what every other reply to this question has 
been. Which is: No, nay, never.


-- 

Regards
     Stephen

Post a reply to this message

On 27-10-2018 13:16, Paul Bourke wrote:
> I am aware of the trace macro that returns the intersection point and normal at
> that point on a object given a ray (point and direction). But is there a way to
> get the colour?
> 
> 

That would be nice to have. IT can of course be done now with a 
combination of (1) the trace macro, and (2) the eval_pigment() function.

-- 
Thomas

Post a reply to this message

I think that directly, one can get the underlying pigment rgb values, and
perhaps there's a way to reverse-uv-map the object to get a traceable point on
the image to evaluate.

With regard to the final displayed color, it might be possible to explore this
in light of the screen-object-placement work that's been done.
Pinpointing the pixel on the screen that corresponds to the trace intersection
point would give you the screen x-y position, and once the scene is rendered,
THAT pixel rgb is known with absolute certainty.

It's not a quick process by any means, nor would it likely easily lend itself to
convenient automation.
Perhaps if the selected coordinates of the 2D bounding box for the "re-render
only this area of the screen" feature could be captured, then that might make it
easier to "scan" that square and get a range of values, or render a new scene
composed of just those pixels - "enlarged" to a full-screen size, and with rgb
values in text superimposed....

Or you could just open the render in a 3rd party software package, zoom in, and
use the eye-dropper tool.   :)

Post a reply to this message

On 11-11-2018 14:23, Bald Eagle wrote:
> I think that directly, one can get the underlying pigment rgb values, and
> perhaps there's a way to reverse-uv-map the object to get a traceable point on
> the image to evaluate.
> 

The closest I have come is attached.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'carpet_01.zip' (961 KB)

Le 18-11-11 à 05:02, Stephen a écrit :

> Option #2 is closer to what I would find useful. If “trace” also 
> returned the RGB* value of the uv image map at the point of intersection 
> of the object by trace. That would be usable.
> * Also filter and transmit values, if possible.
> 
> 
Trace return a coordinate, and optionally, a normal vector.
#declare Normal = <0,0,0>;
#declare Location = trace(Object, Origin, Direction, Normal );

«Location» will return the intersection point, or <0,0,0> if it miss the 
object and «Norm» will return the normal at the found point, or <0,0,0> 
if the object is missed.
Only testing the normal can reliably determine if the object is hit or not.

Next, you need to use eval_pigment() to get the pigment at the 
intersection point, using the transformed pigment of the target object.
If a layered texture is used for the object, then, you need to evaluate 
that layered texture. Better declare that texture and keep track of any 
transformation applied to the object after the texture is applied.

This will return the RGB value of the pigment at the found point.

This don't work for UV mapped textures as those are only defined at the 
surface. Same for aoi and slope patterns.
It WILL work for an image_map as it stretch infinitely along the Z axis.
It will also work for any map type as those are defined everywhere.

What you want is a trace that do use a fifth parameter to return the 
pigment at the found point. This is not possible now, and probably not 
in the short trem. Something like :
#declare Normal = <0,0,0>;
#declare Pigment = rgb 0;
#declare Location = trace(Object, Origin, Direction, Normal , Pigment );

Post a reply to this message

In my imagine there is another function traceUvMap(start_point, direction)
return the uv-map <u, v>

Post a reply to this message

Le 14/11/2018 à 11:05, And a écrit :
> In my imagine there is another function traceUvMap(start_point, direction)
> return the uv-map <u, v>

Objections, my dear:
1. usual SDL is lowercase, and words are separated with underscore, not
Camel syntax (as Uppercase is reserved to users)

2. trace() requires an object, as the whole scene is not yet available,
and you might trace to defined but not present in scene object

So it would rather looks like
trace_uv_map( object, start_point, direction)

Post a reply to this message

Le 15/11/2018 à 18:08, Le_Forgeron a écrit :
> Le 14/11/2018 à 11:05, And a écrit :
>> In my imagine there is another function traceUvMap(start_point, direction)
>> return the uv-map <u, v>
> 
> Objections, my dear:
> 1. usual SDL is lowercase, and words are separated with underscore, not
> Camel syntax (as Uppercase is reserved to users)
> 
> 2. trace() requires an object, as the whole scene is not yet available,
> and you might trace to defined but not present in scene object
> 
> So it would rather looks like
> trace_uv_map( object, start_point, direction)
> 
> 
And it's a kind of 5 minutes patch, see at;
https://github.com/LeForgeron/povray/tree/feature/traceUvMap

demo to get output:
UV : <0.000, 1.000>

with

======================

#version 3.8;
global_settings{ assumed_gamma 1.0 }

#declare Object = sphere { 0, 1 }

#declare Start = <0,4,0>;
#declare Dir = -Start;

#declare UV= trace_uv_map( Object, Start, Dir );

#debug concat("UV : <", vstr(2, UV, ", ", 0, 3 ), ">\n")


======================

Now, let's fight about trace_uv_map or any better spelling or wording.

Post a reply to this message