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