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

On Tue, 28 Oct 2003 12:26:13 +0100, "Christian Walther" <cwa### [at] gmxch>
wrote:
> 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.

Yes, this is already fixed for next release.

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

It was discussed already a few times (iirc most widely during beta-testing of
3.5 in beta-test group about two years ago). In short it is mainly due to
different coordinate system in images.

> I believe that this is a bug

No. It is not a bug at all.

ABX

Post a reply to this message

> It was discussed already a few times (iirc most widely during beta-testing of
> 3.5 in beta-test group about two years ago). In short it is mainly due to
> different coordinate system in images.

Ah, found it. The thread in p.b-t has subject "Function image type mirrored
vertically" and was started by Rune on 5 Apr 2002. I basically take Rune's
point there, but I don't want to bring up that discussion again. Knowing
that it was meant to be as it is is just as good for me as having it how I'd
have done it.

But this really ought to be documented more clearly. Have there been any

release? If not, I could contribute a paragraph or two (and maybe an
image).

 -Christian

Post a reply to this message

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

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

No, it is intentional and I think has been discussed to death when 3.5 was
in public beta.

    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