POV-Ray : Newsgroups : povray.general : height_field { function n, n { ... weirdness : height_field { function n, n { ... weirdness Server Time
3 Aug 2024 20:18:17 EDT (-0400)
  height_field { function n, n { ... weirdness  
From: Christian Walther
Date: 27 Oct 2003 08:34:55
Message: <pan.2003.10.27.13.35.03.917274@gmx.ch>
Hi!

I'm using POV-Ray 3.50c compiled from source on Mac OS X. While trying to
approximate an isosurface-based terrain by a height field for faster
rendering, I stumbled upon some behavior of the "function n, n { ..."
image type that I consider strange. My experimentation showed that:

o The height_field generated by a "function n, n" image type has n-1 by
n-1 vertices (and therefore n-2 by n-2 squares), where I would expect n by
n vertices (and n-1 by n-1 squares).

o The height (y) value for the height field vertex with base coordinates <x, 0,
z> is found by evaluating the function at <x, (n-1)/(n-2)-z, 0>, where I
would expect <x, z, 0> (or possibly <x, 1-z, 0>). This
means that the samples for the height field are not taken from the (<0, 0,
0>, <1, 1, 0>) square, but from (<0, 1/(n-2), 0>, <1, (n-1)/(n-2), 0>),
i.e. shifted by 1/(n-2) in y direction.


Is this the intended behavior? (If so, could anyone explain it to me?)
Have others noticed that too, or am I doing something wrong?
Is this a bug that will eventually be fixed, or can I rely on my
"workaround" remaining valid?

In any case, it would be helpful if the documentation would explain where
exactly the samples for the virtual image are taken instead of just
stating "The image is taken from the square region <0,0,0>, <1,1,0>"
(section 6.7.11.16).

If anybody is interested, I can post the scene file I used to make these
observations.

 -Christian


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.