 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 28 Oct 2003 12:26:13 +0100, "Christian Walther" <cwa### [at] gmx ch>
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: height_field { function n, n { ... weirdness
Date: 28 Oct 2003 11:58:52
Message: <3f9ea04c$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
