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

In article <pan### [at] gmxch> , "Christian Walther" 
<cwa### [at] gmxch> wrote:

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

I do not know what you base your observations on, but they are incorrect.
POV-Ray does not behave the way to describe it.  Function images are created
by evaluating the function exactly as specified in the user manual.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3f9d224c$1@news.povray.org: 

> In article <pan### [at] gmxch> , "Christian
> Walther" <cwa### [at] gmxch> wrote:
> 
>> 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?
> 
> I do not know what you base your observations on, but they are
> incorrect. POV-Ray does not behave the way to describe it.  Function
> images are created by evaluating the function exactly as specified in
> the user manual. 


Are you sure about this Thorsten ?


Tor Olav

Post a reply to this message

In article <Xns### [at] 204213191226> , Tor Olav
Kristensen <tor_olav_kCURLYAhotmail.com>  wrote:

> Are you sure about this Thorsten ?

The relevant code was taken unchanged from MegaPOV (0.7 iirc), and there it
worked without problems.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 27 Oct 2003 15:18:17 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > Are you sure about this Thorsten ?
>
> The relevant code was taken unchanged from MegaPOV (0.7 iirc), and there it
> worked without problems.

Let's see what happens with height value when function 100,100 happens:

1.  during parsing:
        Image->height = Parse_Float();
    so 100 is in height field

2.  during making image with pattern
        Image->iheight = Image->height;     // iheight = 100, height = 100
	Image->height--;                    // iheight = 100, height = 99
        for(i = 0; i < Image->iheight; i++) // i = 0 .. 99
        { 
            Point[Y] = ((DBL)i / (Image->height - 1));
                                            // Point[Y] = 0/98 .. 99/98

99/98 ?

ABX

Post a reply to this message

In article <6jbqpvo3pcufp7nb9rok6eddgu4ohuivtr@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>  Image->height--;                    // iheight = 100, height = 99

Hmm, tracking back in Perforce says the person who submitted it most likely
did so unintentionally.  This line does indeed not make any sense at all.
It turns out this line also didn't exist in MegaPOV version (0.7 iirc) whose
changes were added to 3.5.  Strange...

> 99/98 ?

Yes, that would be the result then.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 27 Oct 2003 16:17:30 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> >  Image->height--;                    // iheight = 100, height = 99
>
> Hmm, tracking back in Perforce says the person who submitted it most likely
> did so unintentionally.

I suppose that intention was to avoid substraction in every loop.

ABX

Post a reply to this message

>> 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?
> 
> I do not know what you base your observations on, but they are incorrect.
> POV-Ray does not behave the way to describe it.  Function images are created
> by evaluating the function exactly as specified in the user manual.

Well, the manual doesn't specify very much. The only thing that it
specifies that is contrary to my observation is "The image is taken from
the square region <0,0,0>, <1,1,0>", and this isn't a very accurate
specification either.

Here is the scene used and some images:

  http://n.ethz.ch/student/walthec/functionhf/

o It is clearly visible that the kinks in the height field coincide with
the edges of the checker texture, so one can count that the height field
has 11 vertices along each direction, while it is defined by "function 12,
12 {".

o Thanks to the "(N-1)/(N-2)-y" used in the function (what I refer to as
"workaround"), the height field shows the desired result, namely that the
gauss functions have their peaks exactly on a vertex. This wouldn't be the
case if I had used "TheFunc(x, 0, y)" (or "TheFunc(x, 0, 1-y)").

 -Christian

Post a reply to this message

In article <f3eqpvs9frupg3q87fer5favi92h6pi4h5@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> >  Image->height--;                    // iheight = 100, height = 99
>>
>> Hmm, tracking back in Perforce says the person who submitted it most likely
>> did so unintentionally.
>
> I suppose that intention was to avoid substraction in every loop.

No, because nobody in the team would optimise code in such a way because it
doesn't make sense (there is no gain).  What I suggested is far more likely,
especially as the subtraction in the loop was not removed and the value
should not have been subtracted outside the loop at all in the first place.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

I have just dug up the source code (and the instructions for compiling it
on Mac OS X) again and can confirm that removing the two lines

  Image->width--;
  Image->height--;

from Make_Pattern_Image(...) in parstxtr.cpp fixes the problem.

One thing that still makes me wonder is that the function evaluation point
(for the pixel that controls the height_field vertex at <x, 0, z>) is
<x, 1-z, 0>, i.e. the image is upside down. Is there a reason for this?
Wouldn't it be more logical (and consistent with e.g. image_maps) to have
<x, z, 0>? Or would that break anything?

I believe that this is a bug which was introduced because the author
didn't consider that image scanlines are usually (and apparently also in
POV's IMAGE structure) numbered from top to bottom, while y coordinates
(in POV's standard coordinate system) increase from bottom to top.

A way to fix this, should one agree that it is a bug, would be replacing

  gray16_line = Image->data.gray16_lines[i] = ...

by

  gray16_line = Image->data.gray16_lines[Image->iheight-1-i] = ...

in Make_Pattern_Image(...).

 -Christian

Post a reply to this message