Bill,
thank you for clarifying this "space oddity". Now, taking into account your
explanations, I will use this function more carefully :) --
--
YB

Post a reply to this message

[yesbird wrote:]
> This small playground localizes this issue (shifting by Y):
[scene code snip]
>
> I discovered that the height_field function moves the rendered object along
> the Y axis by 1 unit without scaling and this effect increases proportional
> to the scaling amount.

This 'y-movement' that you are seeing-- actually not real movement at all-- is
the typical 'look' and behavior of a height_field when a particular kind of
function is used for it...or even a particular kind of image_map function.

A height_field is just a floating 'shell' surface, which ideally expects to see
function values (or image_map pigment values) that go from 0.0 to 1.0. IF those
values do so, you would see parts of the height_field extend all the way down to
y=0, no matter how large you scaled it afterward. But if the values given to the
function actually start at + 0.4 for example (like a gray rgb 0.4 in an
image_map as it's 'darkest' value), then the function will create the lowest
surface of the HF shell at y=0.4, not y=0  (assuming a final HF y-scale of 1.0).
The shell then appears to float above the surface-- and naturally appears to
move higher as you scale everything up, like Bald Eagle mentioned earlier.

In your example code and image, you're using

#declare FnPoly0_2 = function { pattern {
         granite poly_wave 0.2 scale 0.7
         }
}

then scaling your height_field afterward by <2,2,2>.

I suspect that the poly_wave is adding a positive 'bias' value to the function,
causing *extra* floating of the HF because the function no longer has any zero
values(?). Remove that wave type to see how some parts of the HF then almost
touch y=0, more or less.

A better explanatory example would be to try this function instead-- just an
infinitely-thin surface at y=0.4. It's flat HF 'shell' naturally floats above
the ground (unless you scale y to almost zero!)

#declare FnPoly0_2 = function(y) {x + .4}

then...

#declare HF_Poly0_2_2 = height_field {
     function 10, 10 { FnPoly0_2(y) }
     scale   <2, 2, 2>
     pigment {Red}}

Change the y-scale to see the *apparent* movement.

You will need a non-orthographic camera to see the thin shell; use this one
instead:

camera {
  perspective
  location  <1.5, 2, -3>
  look_at   <.75, .4,  .4>
  right     x*image_width/image_height
   angle 67
}

Post a reply to this message

> This 'y-movement' that you are seeing-- actually not real movement at all-- is
> the typical 'look' and behavior of a height_field when a particular kind of
> function is used for it...or even a particular kind of image_map function.

After your explanations and a few suggested experiments this strange fenomena
become to me clear, but  believe, you will agree, that from the user's  point of
view the behaviour of this function is unexpected and leads to some confusion.
I do not mean, that implementation is poor, but only that result are
non-intuitive.

Thanks a lot for consultation, at least now I know how to avoid these pitfalls.
The world is not what it seams ...
--
YB

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
>
> After your explanations and a few suggested experiments this strange fenomena
> become to me clear, but believe, you will agree, that from the user's
> point of view the behaviour of this function is unexpected and leads to
> some confusion. I do not mean, that implementation is poor, but only that
> result are non-intuitive.
>
> ...at least now I know how to avoid these pitfalls.
> The world is not what it seams ...

Sad but true!

BTW:
A height_field can actually be 'solidified' to look like a regular object, by
making an intersection{...} of it with another slightly smaller object. This
might help to better-visualize its behavior. (The empty space 'under' a
floating HF can be considered part of it-- down to -y infinity.) Try this:

intersection{
box{0.01, 0.99  pigment{green 0.8}}
// OR...
// sphere{0,0.5 translate <0.50,.25,0.5> pigment{green 0.8}}
height_field{
function 500,500 {...your function...}
smooth
pigment{red 0.8}
scale <1,0.5,1>
}
scale 1.0 // final scale of everything
}

Post a reply to this message

Attachments:
Download 'function_hf_with_intersection.jpg' (94 KB)

Preview of image 'function_hf_with_intersection.jpg'

Interesting !

In combination with colormaps very attractive effect achieved. I will put it in
macro, with parameters.

---------------------------------------------------------
#include "playground.inc"
#include "colormaps.inc"

// Axis
axis (1.2,0.8,1.2,0.01)

// Cameras
// camo (5,5,5,0,0,0,45)
camp (2,2,2,0,-0.25,0,45)

//
// Prepare colormaps of desired transparency
//
#declare _f = 0;
#declare _t = 0;
#declare jet    = make_colormap (jet_arr,    _f, _t);
#declare spring = make_colormap (spring_arr, _f, _t);
#declare hot    = make_colormap (hot_arr,    _f, _t);
#declare winter = make_colormap (winter_arr, _f, _t);
#declare hsv    = make_colormap (hsv_arr,    _f, _t);
#declare autumn = make_colormap (autumn_arr, _f, _t);
#declare parula = make_colormap (parula_arr, _f, _t);
#declare summer = make_colormap (summer_arr, _f, _t);
#declare turbo  = make_colormap (turbo_arr,  _f, _t);
#declare cool   = make_colormap (cool_arr,   _f, _t);

//
// Object
//
intersection{
  box{0.01, 0.99

  pigment {  gradient y
               color_map {hsv}
               translate -y*0.1
               scale 0.6 }
  }

  height_field{
    function 500,500 { pattern { bozo scale 0.08 } }

    smooth
    pigment {  gradient y
               color_map {hsv}
               translate -y*0.81
               scale 0.8 }

    scale <1,0.4,1>
    }
  scale 1.0
}
---------------------------------------------------------
YB

Post a reply to this message

Attachments:
Download 'height_field_int_cmap.png' (211 KB)

Preview of image 'height_field_int_cmap.png'

> // OR...
> // sphere{0,0.5 translate <0.50,.25,0.5> pigment{green 0.8}}

This is even more interesting !

Post a reply to this message

Attachments:
Download 'height_field_int_cmap.png' (158 KB)

Preview of image 'height_field_int_cmap.png'

It seams to me this is a theme for animation.

Post a reply to this message

Attachments:
Download 'height_field_int_cmap.png' (136 KB)

Preview of image 'height_field_int_cmap.png'

And finally - pie :)

Post a reply to this message

Attachments:
Download 'height_field_int_cmap.png' (164 KB)

Preview of image 'height_field_int_cmap.png'

"yesbird" <nomail@nomail> wrote:
> And finally - pie :)

Looks delicious! I like the wild colors too.

Speaking of colors:
I want to thank YOU for introducing a new pigment construction to me:
            pigment{red 1.0 green 0.6}

I have never used that(!!). I have used 'transmit' and 'filter' in my scenes for
many years, but I thought that such COLOR keywords were parts of "colors.inc" !

I think that I got something confused in the distant past--

             Red (capital letter; pre-#declared in colors.inc)
             vs.
             red 1.0 (a built-in keyword)

It seems that even an old-timer like me needs to re-read POV-ray's *basic*
documentation, now and then ;-)

Post a reply to this message

> I want to thank YOU for introducing a new pigment construction to me:
>             pigment{red 1.0 green 0.6}

Always welcome, I don't remember, where I saw it, but this notation is more
'human-readable', than others, IMHO. Anyway, we are here to exchange knowledge
and ideas. Now I'm working on animation of this 'orange'.

> It seems that even an old-timer like me needs to re-read POV-ray's *basic*
> documentation, now and then ;-)

Yes, we should learn onward :)
--
YB

Post a reply to this message