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?

Post a reply to this message

"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?

Hi Paul!
Good to see you on here.

In functions.inc, there is eval_pigment which returns the pigment at any given
vector location.

Pre defined functions
eval_pigment(Pigm, Vect): This macro evaluates the color of a pigment at a
specific point. Some pigments require more information than simply a point,
slope pattern based pigments for example, and will not work with this macro.
However, most pigments will work fine.

Parameters:

Vect = The point at which to evaluate the pigment.
Pigm = The pigment to evaluate.


Thanks for all of the information you've posted over the years - it's been a
great help as well as an inspiration.


Bill Walker

Post a reply to this message

Am 27.10.2018 um 13:16 schrieb Paul Bourke:
> 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?

If by "colour" you mean apparent colour (as it would appear in the 
output image), the answer is a clear "nay".

If by "colour" you mean pigment, the answer is "well, sort of"; you can 
use the `eval_pigment` function Bald Eagle mentioned already, but you'll 
have to separately keep track of transformations and stuff, POV-Ray 
doesn't do that for you. Also, `eval_pigment` doesn't work with pigments 
that depend on properties of the object surface, the ray, or interaction 
betweent the two, such as pigments using the `slope` or `aoi` patterns.

Post a reply to this message

eval_pigment returns the 'linear' color of an object, not a gamma-bent color
(i.e., not at gamma 2.2.) I.e., it returns an rgb color, not an srgb one. If the
*original* color of your object was chosen to be srgb <...> rather than rgb, and
you want to use the returned srgb equivalent in your scene or for some other
purpose, the result should be used as  srgb <0.2,0.5,0.75>, for example, not rgb
<...>.

But if your original color was  rgb <...>, then eval_pigment will return that
same color.

As Clipka noted, eval_pigment doesn't take into account the *illumination* of
the object-- lighting, shadow, phong, etc--, just the basic strict color found
there.

Post a reply to this message

Le 18-10-28 à 12:50, Kenneth a écrit :
> eval_pigment returns the 'linear' color of an object, not a gamma-bent color
> (i.e., not at gamma 2.2.) I.e., it returns an rgb color, not an srgb one. If the
> *original* color of your object was chosen to be srgb <...> rather than rgb, and
> you want to use the returned srgb equivalent in your scene or for some other
> purpose, the result should be used as  srgb <0.2,0.5,0.75>, for example, not rgb
> <...>.
> 
> But if your original color was  rgb <...>, then eval_pigment will return that
> same color.
> 
> As Clipka noted, eval_pigment doesn't take into account the *illumination* of
> the object-- lighting, shadow, phong, etc--, just the basic strict color found
> there.
> 
> 
> 
> 

Also, it probably won't work for UV mapped textures.

Post a reply to this message

"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?


What do you have in hands to determine the intersection point?

Personally I love the „Illusion“ code of Rune and its possibilities. Perhaps
there lies a solution for some of the mentioned limitations - in combination
with a mesh camera.


Norbert

Post a reply to this message

"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

Am 15.11.2018 um 18:33 schrieb Le_Forgeron:

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

Since you cannot compute an UV coordinate without computing an 
intersection, I would lean towards designing this as an extension to the 
existing `trace` function, via yet another optional parameter after the 
normal variable. That way we can avoid double work when the user wants 
both the intersection point's location and the UV coordinates.

Also, if for some reason we need to implement it as a separate function, 
I would prefer `trace_uv`. We don't have the `map` appendix in any other 
UV mapping related stuff (e.g. it is `uv_vectors`, not 
`uv_map_vectors`), so adding it here would be inconsistent.

Post a reply to this message

Le 18-11-15 à 13:38, clipka a écrit :
> Am 15.11.2018 um 18:33 schrieb Le_Forgeron:
> 
>> Now, let's fight about trace_uv_map or any better spelling or wording.
> 
> Since you cannot compute an UV coordinate without computing an 
> intersection, I would lean towards designing this as an extension to the 
> existing `trace` function, via yet another optional parameter after the 
> normal variable. That way we can avoid double work when the user wants 
> both the intersection point's location and the UV coordinates.
> 
> Also, if for some reason we need to implement it as a separate function, 
> I would prefer `trace_uv`. We don't have the `map` appendix in any other 
> UV mapping related stuff (e.g. it is `uv_vectors`, not 
> `uv_map_vectors`), so adding it here would be inconsistent.

So, it should look somewhat like :

#declare Location= trace( Object, Start, Dir, Normal, UV_Location );

or

#declare Location= trace( Object, Start, Dir, Normal, UV_colour );

If it ever get implemented.



Alain

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> 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
>

Sorry, how to use...

I mean github



> 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

Am 17.11.2018 um 05:18 schrieb And:

>> And it's a kind of 5 minutes patch, see at;
>> https://github.com/LeForgeron/povray/tree/feature/traceUvMap
>>
> 
> Sorry, how to use...
> 
> I mean github

I guess the most important things to know (in this case):

- What the link takes you to is GitHub's overview of a patched version 
of POV-Ray.

- Clicking on the green "Clone or download" button and then "Download 
ZIP" (at the bottom of the pop-up) will download a ZIP package 
containing that version's complete source code.

- The version does not come with binaries, so to use it on a Windows 
machine you would have to compile it yourself.


If you are more interested in having a look under the hood of the patch 
rather than test-driving it:

- To view what has been changed in the patched version, click on 
"Compare" immediately below said button (in the line reading "This 
branch is 1 commit ahead of POV-Ray:master")

Post a reply to this message

Am 16.11.2018 um 20:34 schrieb Alain:

> So, it should look somewhat like :
> 
> #declare Location= trace( Object, Start, Dir, Normal, UV_Location );

Yes, that would be the trivial-to-implement solution.

> or
> 
> #declare Location= trace( Object, Start, Dir, Normal, UV_colour );

In this case, it would be more like:

     #declare Location= trace( Object, Start, Dir, Normal, colour );

While I agree that this would be the most desirable solution, I'm not 
sure whether it would be possible to implement in a fully consistent 
manner. As someone hinted at earlier in this thread, objects don't have 
pigments - they have textures, which may be arbitrarily complex. There 
may be cases (either now or in the future) where there's no single 
unambiguous colour associated with the ray-object intersection.

As an extreme example, take SSLT: In the first incarnation (somewhen 
during the beta phase of POV-Ray v3.7.0) the colour of SSLT textures 
wasn't controlled by a pigment, but was an emergent property of quite 
different physics-based parameters.

While it may turn out to be possible to resolve this issue in a 
well-defined manner, it certainly won't be trivial.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.11.2018 um 05:18 schrieb And:
>
> >> And it's a kind of 5 minutes patch, see at;
> >> https://github.com/LeForgeron/povray/tree/feature/traceUvMap
> >>
> >
> > Sorry, how to use...
> >
> > I mean github
>
> I guess the most important things to know (in this case):
>
> - What the link takes you to is GitHub's overview of a patched version
> of POV-Ray.
>
> - Clicking on the green "Clone or download" button and then "Download
> ZIP" (at the bottom of the pop-up) will download a ZIP package
> containing that version's complete source code.
>
> - The version does not come with binaries, so to use it on a Windows
> machine you would have to compile it yourself.
>

I think I will use this function in the future, but temporary not.

In fact I'm unable to compile it.


clipka <ano### [at] anonymousorg> wrote:
> Am 16.11.2018 um 20:34 schrieb Alain:
>
> > So, it should look somewhat like :
> >
> > #declare Location= trace( Object, Start, Dir, Normal, UV_Location );
>
> Yes, that would be the trivial-to-implement solution.
>
> > or
> >
> > #declare Location= trace( Object, Start, Dir, Normal, UV_colour );
>
> In this case, it would be more like:
>
>      #declare Location= trace( Object, Start, Dir, Normal, colour );
>

From my perspective UV_Location = trace_uv_map(Object, Start, Dir); is better,
after all not every objects have uv map.

#declare Location= trace( Object, Start, Dir, Normal, UV_Location ); does the
same function (for my needs)


At the beginning I want this function because I want to create some scene. E.g
fungus growing on a rock. And I want to produce the rock with a third party
software like blender, and paint a texture on it to design the density of
fungus. If I have the trace uv map function I can trace the rock to get the
color of texture, then use random() <? texture color to decide whether
is the fungus there to achieve my intention.

Post a reply to this message

Inspired by these pictures

https://www.pinterest.com/pin/186617978287852820/

https://www.pinterest.com/pin/477663104213161095/

https://www.pinterest.com/pin/518265869605948864/

https://www.pinterest.com/pin/451837775112045194/

Post a reply to this message

Le 15/11/2018 à 19:38, clipka a écrit :
> Am 15.11.2018 um 18:33 schrieb Le_Forgeron:
> 
>> Now, let's fight about trace_uv_map or any better spelling or wording.
> 
> Since you cannot compute an UV coordinate without computing an
> intersection, I would lean towards designing this as an extension to the
> existing `trace` function, via yet another optional parameter after the
> normal variable. That way we can avoid double work when the user wants
> both the intersection point's location and the UV coordinates.
> 
> Also, if for some reason we need to implement it as a separate function,
> I would prefer `trace_uv`. We don't have the `map` appendix in any other
> UV mapping related stuff (e.g. it is `uv_vectors`, not
> `uv_map_vectors`), so adding it here would be inconsistent.

You can have the best of both world, now, at >
https://github.com/LeForgeron/povray/commit/cea994f8e69375f9de809bea5df241f1a269f702

(same branch as before):
* added uv-vector as optional parameter of trace(), after normal
* changed trace_uvmap to trace_uv, for the ones which only wants uv data
and do not care about intersection & normal.

Post a reply to this message

Attachments:
Download 'traceuv.pov.txt' (1 KB)

Le_Forgeron <jgr### [at] freefr> wrote:
> You can have the best of both world, now, at >
> https://github.com/LeForgeron/povray/commit/cea994f8e69375f9de809bea5df241f1a269f702
>
> (same branch as before):
> * added uv-vector as optional parameter of trace(), after normal
> * changed trace_uvmap to trace_uv, for the ones which only wants uv data
> and do not care about intersection & normal.


^^

Post a reply to this message

"And" <49341109@ntnu.edu.tw> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > You can have the best of both world, now, at >
> >
https://github.com/LeForgeron/povray/commit/cea994f8e69375f9de809bea5df241f1a269f702
> >
> > (same branch as before):
> > * added uv-vector as optional parameter of trace(), after normal
> > * changed trace_uvmap to trace_uv, for the ones which only wants uv data
> > and do not care about intersection & normal.
>
>
> ^^

Waiting a binary release

(Or should I understand how to compile a c++ program)

Post a reply to this message