I know there was some way to fetch the rgb-color off of
an object, but I'm not sure if there was a POV-inbuilt way
of doing this, or if I'd have to use a roundabout way with
functions to get what I want?

I'm basically trying to script a heightfield-generator within
POV for use with my Mesh-Modifying-Macros. Eventually,
the implementation should take care of the normals-bug
occuring with heightfields (I've never experienced problems
with the normals that were generated by my MMM), and
also leave some more flexibility in the use (cause I can
deform the heightfield later on). What I want to do now is
get a way to "read" an image with any designated amount of
resolution. But to begin with, I need to read the image-map's
rgb-components.

And I know, how about using bigger resolutions with smaller
images? I plan to have two versions for this: one which will
just read the image, extrapolate the heights and build the mesh,
another one will read the image, extrapolate the heights and
may use interpolations between pixels when heightfield
resolution exceeds the User-Specified pixel-resolution, and
build the mesh from that. As a final step, the MMM may be
used to get the normals for smooth-heightfields.

So, question remains: how to fetch the rgb from an image
(better yet: from a pigment)?

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> So, question remains: how to fetch the rgb from an image
> (better yet: from a pigment)?

  The HF_*() macros in shapes.inc do pretty much what you are trying
to achieve (ie. they create a mesh which is the heightfield created
using the given function).

  Anyways, to get the rgb values of a pigment, you need to create a
pigment function. A pigment function returns a color (instead of a float
like regular float functions do), and naturally you can access the
components of this color with the dot operators (.red, .green, .blue,
.filter and .transmit, or if you prefer, .x, .y and .z).
  As a pigment can contain an image map, you can make a pigment function
conaining an image map and thus get the colors of the pixels of the image
(of course there's no way of knowing the resolution of the image map other
than hard-coding it into your code according to the size of the image you
are using).

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

You're right about the HF_Square macro returning what I
want to do with the "standard" heightfield-macro, nontheless,
I need the macros to output the data I need for my other
macros, so I'll script that macro myself (also, I'm THAT kind
of POVer :-).

Additionally, I want to script some macros which will
interpolate among adjacent samples to generate heightfields
with a higher resolution than the image-map supplied for it,
this may be done by either letting the User specify the original
image-resolution, or by just sampling in-between nodes.

As a last macro, I plan to have one sample the image for
different colored pixels, and interpolate among these, in order
to fully avoid the plateaus. I'll then have to make some macros
which could generate plateaus, e.g. by specifying a certain
"clipping height" + range, thus clipping y-values in a certain
magnitude to be clipped to another certain y-value. Combining
this with another image-map (to define where the plateau should
be), and I get a nice heightfield with plateaus where I want them,
and smooth angles everywhere else...

Well, thanks about the info on how to get the rgb, as you can see,
thats pretty essential for the macros to function properly.

Regards,
Tim

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> > So, question remains: how to fetch the rgb from an image
> > (better yet: from a pigment)?
>
>   The HF_*() macros in shapes.inc do pretty much what you are trying
> to achieve (ie. they create a mesh which is the heightfield created
> using the given function).
>
>   Anyways, to get the rgb values of a pigment, you need to create a
> pigment function. A pigment function returns a color (instead of a float
> like regular float functions do), and naturally you can access the
> components of this color with the dot operators (.red, .green, .blue,
> .filter and .transmit, or if you prefer, .x, .y and .z).
>   As a pigment can contain an image map, you can make a pigment function
> conaining an image map and thus get the colors of the pixels of the image
> (of course there's no way of knowing the resolution of the image map other
> than hard-coding it into your code according to the size of the image you
> are using).
>
> --
> plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
> sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
> density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
> <1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Hello,

I experienced similar problem, I needed the color from texture at point P.
The trick which worked for me was:

#declare TEX=texture {
....
}

sphere {
  <0, 0, 0>, 1
  texture {
    TEX
    translate -P
    scale 1000
    ...
  }
  translate ...
  ...
}

This way the spere has color from the given point on texture. But if there
is some better way, please enlighten me, i would like something:

color=TEX[P]

or alike :)


Regards,
Vlada

Post a reply to this message

Thats what the function was about. I'm not very used
to functions, but they return only float values AFAIK.
Thus, you'd need to have three functions, each using
the pigment from the texture, and then accessing
only red, green and blue via .red, .blue und .green.
You've got to look at the documentation for that.

Your method is only useful for coloring objects, but not
when I want to calculate stuff based on the color...

Regards,
Tim

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> Hello,
>
> I experienced similar problem, I needed the color from texture at point P.
> The trick which worked for me was:
>
> #declare TEX=texture {
> ....
> }
>
> sphere {
>   <0, 0, 0>, 1
>   texture {
>     TEX
>     translate -P
>     scale 1000
>     ...
>   }
>   translate ...
>   ...
> }
>
> This way the spere has color from the given point on texture. But if there
> is some better way, please enlighten me, i would like something:
>
> color=TEX[P]
>
> or alike :)
>
>
> Regards,
> Vlada
>

Post a reply to this message

"Tim Nikias v2.0" <tim### [at] gmxde> wrote in
news:3e89a5dd$1@news.povray.org: 

> Thats what the function was about. I'm not very used
> to functions, but they return only float values AFAIK.
...

Then I suggest that you RTFM.


Tor Olav

Post a reply to this message

Hm, you're right. Oversaw that pigment-functions return vectors.
Thanks for the suggestion (thats not meant sarcastic, to me,
Read The Fucking Manual is just like Laughing Out Loud, some
common term abbreviated)...

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> > Thats what the function was about. I'm not very used
> > to functions, but they return only float values AFAIK.
> ...
>
> Then I suggest that you RTFM.
>
>
> Tor Olav

Post a reply to this message

It could also mean "Read The Fine Manual".

=)

And you have transform functions and spline functions
which returns vectors as well.


Tor Olav



"Tim Nikias v2.0" <tim### [at] gmxde> wrote in 
news:3e89c665@news.povray.org:

> Hm, you're right. Oversaw that pigment-functions return vectors.
> Thanks for the suggestion (thats not meant sarcastic, to me,
> Read The Fucking Manual is just like Laughing Out Loud, some
> common term abbreviated)...
> 
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: Tim### [at] gmxde
> 
>>
>> > Thats what the function was about. I'm not very used
>> > to functions, but they return only float values AFAIK.
>> ...
>>
>> Then I suggest that you RTFM.
>>
>>
>> Tor Olav
> 
> 
>

Post a reply to this message