"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> I found a big difference in using a image pigment in the height_field function
> and that pigment in the height_field alone.
>
> that is
>  #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
>  #declare Dirt =
> function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
>  height_field {function 400,400{ Dirt(x,y) }...
> and
>
>  height_field {tga "FinalB.tga"
>
> they don't match! The function has a lower height and seems to be shifted both
> in the +z and +x directions
>

Out of curiosity, I used your code examples but with my own .png image_map (not
..tga), and I see some interesting things:

First, I was surprised that your constructed DIRT function works at all. Z's
instead of y's there? But it does work! Substituting y for z *also* works:
       function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}

But moving on...
My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
The resulting height_fields have a gradient-y color_map applied, from black to
reddish. (I shouldn't have used black; it makes the results difficult to see.)

I don't see any x or z reversal between the two HF examples. We're both using
the (1-z) trick for the function version, so that should solve it. It does for
me.

But *most* interestingly, the two HF-creation methods show some different
results for the height values. The 'direct' approach uses only the RED color
channel, AND shows the linear white-to-black 'ramp' correctly; the function
approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
that!

Post a reply to this message

Attachments:
Download 'height_field_direct_and_by_functions_kw.jpg' (266 KB)

Preview of image 'height_field_direct_and_by_functions_kw.jpg'