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