hi,

On 10/09/2017 16:03, clipka wrote:
> Am 10.09.2017 um 16:01 schrieb Stephen:
>> On 10/09/2017 14:27, clipka wrote:
>>> Am 10.09.2017 um 15:13 schrieb Stephen:
>>>> If I trace an object. How can I get the colour of the intersection of
>>>> the ray and object. As far as I can see trace() only returns the normal.
>>> You'll need to know the pigment of the object, and invoke `eval_pigment`
>>> on the intersection point you get...
>> Thanks, I had a blank in my memory.
>>> ... and hope that the pigment isn't UV-mapped,
>> Hope is not involved because there is a good chance I would want to do
>> that. Is it at all possible?
> No; not with the current versions of POV-Ray. The `trace` function would
> have to be extended to report the UV coordinate of the intersection, so
> that you could then feed it into `eval_pigment` instead of the 3D
> coordinate.

do I understand this correctly?  if I trace some object with a regular
pigment it will work, but the trace will fail if the object's
pigment/colour is "not simple"?  seems .. strange.

regards, jr.

Post a reply to this message

Am 10.09.2017 um 21:22 schrieb jr:
> hi,
> 
> On 10/09/2017 16:03, clipka wrote:
>> Am 10.09.2017 um 16:01 schrieb Stephen:
>>> On 10/09/2017 14:27, clipka wrote:
>>>> Am 10.09.2017 um 15:13 schrieb Stephen:
>>>>> If I trace an object. How can I get the colour of the intersection of
>>>>> the ray and object. As far as I can see trace() only returns the normal.
>>>> You'll need to know the pigment of the object, and invoke `eval_pigment`
>>>> on the intersection point you get...
>>> Thanks, I had a blank in my memory.
>>>> ... and hope that the pigment isn't UV-mapped,
>>> Hope is not involved because there is a good chance I would want to do
>>> that. Is it at all possible?
>> No; not with the current versions of POV-Ray. The `trace` function would
>> have to be extended to report the UV coordinate of the intersection, so
>> that you could then feed it into `eval_pigment` instead of the 3D
>> coordinate.
> 
> do I understand this correctly?  if I trace some object with a regular
> pigment it will work, but the trace will fail if the object's
> pigment/colour is "not simple"?  seems .. strange.

No, the `trace` function works perfectly fine for what it was designed
for: It gives you the point in 3D space where a given ray intersects a
given geometric object. In and of itself, it has nothing to do with
pigments whatsoever.

Likewise, the `eval_pigment` function works perfectly fine for what it
was designed for: It gives you the colour of a given pigment for a given
point in 3D space. In and of itself, it has nothing to do with geometry
whatsoever.

And that's where the problem with UV-mapped textures arises: Since
`trace` knows nothing about textures, and `eval_pigment` knows nothing
about geometry, the two can only be combined for good effect if there is
a direct mapping between geometry and pigment via 3D XYZ space. But with
UV-mapping that's not the case, and hence the /combo/ of the two
functions breaks down there.

Post a reply to this message

hi,

On 10/09/2017 20:57, clipka wrote:
> Am 10.09.2017 um 21:22 schrieb jr:
>> do I understand this correctly?  if I trace some object with a regular
>> pigment it will work, but the trace will fail if the object's
>> pigment/colour is "not simple"?  seems .. strange.
> 
> No, the `trace` function works perfectly fine for what it was designed
> for: It gives you the point in 3D space where a given ray intersects a
> given geometric object. In and of itself, it has nothing to do with
> pigments whatsoever.
> 
> Likewise, the `eval_pigment` function works perfectly fine for what it
> was designed for: It gives you the colour of a given pigment for a given
> point in 3D space. In and of itself, it has nothing to do with geometry
> whatsoever.
> 
> And that's where the problem with UV-mapped textures arises: Since
> `trace` knows nothing about textures, and `eval_pigment` knows nothing
> about geometry, the two can only be combined for good effect if there is
> a direct mapping between geometry and pigment via 3D XYZ space. But with
> UV-mapping that's not the case, and hence the /combo/ of the two
> functions breaks down there.

thanks.

regards, jr.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> And that's where the problem with UV-mapped textures arises: Since
> `trace` knows nothing about textures, and `eval_pigment` knows nothing
> about geometry, the two can only be combined for good effect if there is
> a direct mapping between geometry and pigment via 3D XYZ space. But with
> UV-mapping that's not the case, and hence the /combo/ of the two
> functions breaks down there.

So, the color of a surface on a uv-mapped object is not directly measurable by
the eval_pigment() function? [ ! :O ]
I would never have guessed that.

It must then use a completely different algorithm than the ray-object
intersection used to generate the final scene.

Can you:
1. use trace() to get the point and the normal
2. define a pigment constructed in the plane intersecting that point with the
same normal
( I likely have no idea what I'm talking about here: I'm just confabulating the
possibility that some slice of a function-object-pattern thing might be a
workaround... )
3. then do an eval_pigment() on the plane?

Post a reply to this message

On 10/09/2017 14:27, clipka wrote:
> Am 10.09.2017 um 15:13 schrieb Stephen:
>> If I trace an object. How can I get the colour of the intersection of
>> the ray and object. As far as I can see trace() only returns the normal.
> 
> You'll need to know the pigment of the object, and invoke `eval_pigment`
> on the intersection point you get...
> 

Follow up question.

How would you use eval_pigment if you were tracing a CSG?
Is it possible?

-- 

Regards
     Stephen

Post a reply to this message

On 09/10/2017 10:01 AM, Stephen wrote:
> On 10/09/2017 14:27, clipka wrote:
...
> 
>> ... and hope that the pigment isn't UV-mapped,
> 
> Hope is not involved because there is a good chance I would want to do 
> that. Is it at all possible?
> 
We do now have a user defined by functions camera. If you can work out 
how to map each 'trace' to an equivalent user defined camera ray, it 
should be you can create an image - sort of a new version of the uv 
mapped texture as 'seen' mapped onto the object. This rendered image 
could then be queried at the appropriate x,y positions for each trace to 
give you the color values.

Likely want to create that image with a modified finish of ambient 1.0 
or emission 1.0 - and diffuse 0.0 for the object's texture.

I've had the reverse of what you are attempting floating around in my 
head for creating uv mapped images via texture baking environments for 
all POV-Ray's uv mapped objects. We have the uv mapping for a 
significant number of primitives, but for most, no easy way to create uv 
image maps for them. In other words, as part of the uv mapping 
capability for each primitive, might we be able to provide uv mapping 
functions which could be use to create inward or outward facing user 
defined functional cameras more or less in the 'shape' of the primitive 
object. Kind of a mesh camera capability. Every uv mapped primitive 
could also be a primitive shaped camera by using the uv appropriate 
functions and matching shape parameters. ;-)

Using the mesh camera to get a rendered image for the traced colors is I 
think another possibility. Create a triangle in the 'camera' mesh for 
each traced ray.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 09/10/2017 10:01 AM, Stephen wrote:
> > On 10/09/2017 14:27, clipka wrote:
> ...
> >
> >> ... and hope that the pigment isn't UV-mapped,
> >
> > Hope is not involved because there is a good chance I would want to do
> > that. Is it at all possible?
> >
> We do now have a user defined by functions camera. If you can work out
> how to map each 'trace' to an equivalent user defined camera ray, it
> should be you can create an image - sort of a new version of the uv
> mapped texture as 'seen' mapped onto the object. This rendered image
> could then be queried at the appropriate x,y positions for each trace to
> give you the color values.
>
> Likely want to create that image with a modified finish of ambient 1.0
> or emission 1.0 - and diffuse 0.0 for the object's texture.
>
> I've had the reverse of what you are attempting floating around in my
> head for creating uv mapped images via texture baking environments for
> all POV-Ray's uv mapped objects. We have the uv mapping for a
> significant number of primitives, but for most, no easy way to create uv
> image maps for them. In other words, as part of the uv mapping
> capability for each primitive, might we be able to provide uv mapping
> functions which could be use to create inward or outward facing user
> defined functional cameras more or less in the 'shape' of the primitive
> object. Kind of a mesh camera capability. Every uv mapped primitive
> could also be a primitive shaped camera by using the uv appropriate
> functions and matching shape parameters. ;-)
>
> Using the mesh camera to get a rendered image for the traced colors is I
> think another possibility. Create a triangle in the 'camera' mesh for
> each traced ray.
>
> Bill P.

More food for thought. I am going to die of glutony. ;-)

I've been meaning to look at the mesh camera for ages. I like the idea of using
it as a UV mapper.

But with my luck at the moment...

I'm having to post this from the web interface as TBird did not load the text.

Computers!

--

Stephen

Post a reply to this message

Am 10.09.2017 um 23:50 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> And that's where the problem with UV-mapped textures arises: Since
>> `trace` knows nothing about textures, and `eval_pigment` knows nothing
>> about geometry, the two can only be combined for good effect if there is
>> a direct mapping between geometry and pigment via 3D XYZ space. But with
>> UV-mapping that's not the case, and hence the /combo/ of the two
>> functions breaks down there.
> 
> So, the color of a surface on a uv-mapped object is not directly measurable by
> the eval_pigment() function? [ ! :O ]
> I would never have guessed that.
> 
> It must then use a completely different algorithm than the ray-object
> intersection used to generate the final scene.

Actually no, the `trace` function is essentially the same as the one
used in the render. And the `eval_pigment` function is also essentially
the same as the one used in the render.

But the `trace`-like function used in the render not only computes the
3D XYZ location and surface normal, but also the UV coordinate as yet
another output value; and the render alghorithm then decides whether to
call the `eval_pigment`-like function with <X,Y,Z> as the location
parameter, or whether to use <U,V,0> instead.

> Can you:
> 1. use trace() to get the point and the normal

Yes, absolutely.

> 2. define a pigment constructed in the plane intersecting that point with the
> same normal
> ( I likely have no idea what I'm talking about here: I'm just confabulating the
> possibility that some slice of a function-object-pattern thing might be a
> workaround... )

You're right, that sounds a bit... confabulated. ;)
Whatever your brain is concocting there, it can't replace computing the
UV coordinate of the intersection.

> 3. then do an eval_pigment() on the plane?

You cannot do `eval_pigment` on shapes. You can only call it on pigments.

Post a reply to this message

Am 11.09.2017 um 09:11 schrieb Stephen:
> On 10/09/2017 14:27, clipka wrote:
>> Am 10.09.2017 um 15:13 schrieb Stephen:
>>> If I trace an object. How can I get the colour of the intersection of
>>> the ray and object. As far as I can see trace() only returns the normal.
>>
>> You'll need to know the pigment of the object, and invoke `eval_pigment`
>> on the intersection point you get...
>>
> 
> Follow up question.
> 
> How would you use eval_pigment if you were tracing a CSG?
> Is it possible?

Presuming the CSG elements have different textures... no.


So with that in mind, probably the easiest (from a user perspective) way
to solve this whole group of issues would be to provide a function that
not only computes a ray-object intersection, but also does a proper
pigment lookup.

Which has its own issues though; most notably, texture patterns and
layered textures would be a b*tch to deal with, as in the actual render
algorithm they're not handled at the pigment level, but at the "what
does that texture actually look like as seen from this angle" level
(finish level if you will, with highlights and reflections and all).

Post a reply to this message

On 11/09/2017 14:38, clipka wrote:
> Am 11.09.2017 um 09:11 schrieb Stephen:
>>>
>>
>> Follow up question.
>>
>> How would you use eval_pigment if you were tracing a CSG?
>> Is it possible?
> 
> Presuming the CSG elements have different textures... no.
> 
> 
> So with that in mind, probably the easiest (from a user perspective) way
> to solve this whole group of issues would be to provide a function that
> not only computes a ray-object intersection, but also does a proper
> pigment lookup.
> 
> Which has its own issues though; most notably, texture patterns and
> layered textures would be a b*tch to deal with, as in the actual render
> algorithm they're not handled at the pigment level, but at the "what
> does that texture actually look like as seen from this angle" level
> (finish level if you will, with highlights and reflections and all).
> 

So that means it will be ready after PovRay Ver 4.0 and Moray's 
re-write. ;-)
Thanks for looking into it Clipka.

-- 

Regards
     Stephen

Post a reply to this message