> I don't think You have answered to my argument about
> better kerning handling in standard include files, btw.
> Feel free to send me ANY answer.

Sorry, I haven't had time to investigate it yet and there are still several
things that needs to be done that I consider of higher priority. But when I
get time I'll look into it and come back to you on this. As I haven't looked
into it yet, I'm not saying that your arguments are wrong.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

"Thorsten Froehlich" wrote:
> The function is evaluated as if (actually is) an image
> was generated from it. Thus the evaluation takes place
> in the image space, not the scene space.

Image space doesn't have to be the same for all image types. For most image
types the origin is defined as being in the upper right corner. Because this
is a standard in those image types, the user can be sure that up will always
remain up and down will remain down. What corner of the image is the origin
doesn't really matter, but one corner had to be chosen so that the user can
count on the alignment always being the same.

Now, when choosing what corner should be the origin in the function image
type, one should choose the best solution for *this* image type, not just
use the same as for all the other image types. So what is the best solution
for the pattern image type?

Well, naturally it is to use the same coordinate definition as used
everywhere else in POV-Ray, i.e. the corner being in the lower right corner.
That is what users expect both logically and intuitively.

It's important for me to point out that what you call "image space" can be
whatever you make it to, so you have to choose the image space that is the
*best* solution. I have argued that having the origin in the lower left
corner is the image space that is easiest to understand for users. What is
your argument for using a different image space)?

To me it seems like you keep assuming that there is only one possible
definition of image space and that is the one the other image types use.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Rune, I think I get your point, but don't you think you have beaten this
horse enough?

Isn't the solution as easy as using image_map {function 100, 100
{F(x,1-y,z)}} in your code? One additional sentence in the docs could point
this out to everyone who is not able to work it out him/herself.
I know, that's not your point, but if the solution is that simple, that even
I can work it out in no-time, I don't think it's worth to discuss this in
such extend. In another eight days it's time for the next beta and afaik
there are quite some bugs left to work on.

Just my opinion,

Marc-Hendrik

Post a reply to this message

"Marc-Hendrik Bremer" wrote:
> Rune, I think I get your point, but don't you
> think you have beaten this horse enough?

I think the behavior is wrong and if it isn't fixed before the final release
of POV-Ray 3.5, then we will be stuck with this annoyance forever to ensure
backwards compatibility.

I just don't get it. I make an image in a paint program. It's correctly
aligned (the image is not upside down). I use this image as an image_map.
It's still correctly aligned.

I use this image in a function and use the function as a pattern in a
pigment. It's still correctly aligned.

Now I use the image in a function in an image_map. Now it's upside down! And
*that* is consistency???

Thorsten keeps saying that the function image type use "image space"
coordinates, but he has not yet explained why the function image type has to
use the same definition of image space, when the concept of up and down is
the opposite in function coordinates than it is in all external image
formats.

But no, I can't get any explanation despite of how long this thread has been
running by now...

I also would have liked to hear other people's thoughts on what would be the
correct behavior, but apparently no one have anything to say about it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3cb35700$1@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> I think the behavior is wrong and if it isn't fixed before the final release
> of POV-Ray 3.5, then we will be stuck with this annoyance forever to ensure
> backwards compatibility.

I agree. POV should make sure the *upper left corner* is at < 1, 0>, not 
the internal image coordinates < 0, 0>. I highly doubt anybody thinks in 
terms of these "image space" coordinates when writing a function. The 
upper left corner is at < 1, 0>, there is no obvious reason for that to 
suddenly be treated as < 0, 0>, and for the y coordinate to be negated.
It is also an annoying inconsistency when using a function both directly 
and as a function image. When no special warping or mapping is done, the 
function image should have the same orientaion as the function.

I can only see this causing confusion and frustration, no matter how 
well documented it is.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message