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