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