The function image type is mirrored vertically.
It does take values in the 0 to 1 range both horizontally and vertically as
it should, but the y values go from 1 to 0 instead of from 0 to 1.

The code below shows the bug. Can anybody confirm?

camera {location -3*z}
#default {finish {ambient 1}}
#declare F = function {pattern {spherical}}
plane {
   -z, 0
   pigment {function {F(x,y,z)}}
}
box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {function 100, 100 {F(x,y,z)}}
   }
}

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

Confirmed.

Beta 15.msvc, Windows 2000, AMD Athlon-C 1.33GHz, 768MB RAM.

Post a reply to this message

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

> The code below shows the bug. Can anybody confirm?

It is not a bug in POV-Ray but in your scene.  The origin of the image is at
the upper left of the box while the origin of the function is the center of
the image.  Applying an image map instead of the function image will clarify
the origin.

    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" wrote:
> It is not a bug in POV-Ray but in your scene.
> The origin of the image is at the upper left
> of the box while the origin of the function
> is the center of the image. Applying an image
> map instead of the function image will clarify
> the origin.

Funny, because when rendering the code below I see an upside-down image.
Another bug in my scene?

camera {location -3*z}
#default {finish {ambient 1}}
#declare I = function {pigment {image_map {png "test.png"}}}
#declare F = function {I(x,y,z).gray}
plane {
   -z, 0
   pigment {function {F(x,y,z)}}
}
box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {function 100, 100 {F(x,y,z)}}
   }
}

Post a reply to this message

In article <3caeba7d$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> It is not a bug in POV-Ray but in your scene.  The origin of the image is at
> the upper left of the box while the origin of the function is the center of
> the image.  Applying an image map instead of the function image will clarify
> the origin.

Wouldn't it be much less confusing for the users if the function used 
scene-space coordinates instead of image-space? Then a function image 
could be used as a direct drop-in replacement for a function.
Does this affect anything else? If I remember correctly, images from 
file formats with a different coordinate system (< 0, 0> at the lower 
left, for instance) are modified to be oriented properly, couldn't the 
same be done for function images?

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

"Christopher James Huff" wrote:
> Wouldn't it be much less confusing for the users
> if the function used scene-space coordinates instead
> of image-space?

Of course it would. The current behavior is completely illogical. It puts
everything upside down.

> Does this affect anything else?

There's no need for any exceptions or special cases. Currently everything is
upside down. It should be fixed so that everything is correctly aligned. The
y values passed to the function in the 0 to 1 range should not be reversed
as they currently are.

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 <3caec8fe$1@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Funny, because when rendering the code below I see an upside-down image.
> Another bug in my scene?

Yes, because I said you should use an image map instead of the function image
to see that it works correctly:

box {
   <0,0,-0.001>,<1,1,1>
   pigment {
      image_map {image_map {png "test.png"}}
   }
}

When doing this you will notice that the origin of the image is at exactly the
same place where the function is.  This is the way image maps always worked,
so it won't be changed because it would break far too many scenes.

    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

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> Wouldn't it be much less confusing for the users if the function used
> scene-space coordinates instead of image-space?

But then it wouldn't be an image map any more:  The image simply can't know
where and how it is applied.  What you are suggesting sounds like uv-mapping
of some kind.

> file formats with a different coordinate system (< 0, 0> at the lower
> left, for instance) are modified to be oriented properly, couldn't the
> same be done for function images?

The current origin is *correct*.  Of any image the origin is at the upper left
corner and POV-Ray (tries) to make this true for all image formats (afaik only
TIFF allows other origins anyway).  If you check replace the function image by
a plain image map (or simply look at the source code) you will find that the
same is true for the function image.  The origin is that the upper left of the
image map that is being created.

Sure, the origin can be chosen arbitrarily, but for all computer images the
accepted standard (probably because that is where the beam usually starts on
CRTs) is to have the origin at the upper left rather than the lower left
commonly used in mathematics.

POV-Ray intentionally takes a middle way and "compensates" (see comment in
function 'map' in 'image.cpp') for this and places the image origin for an
image mapped "once" at <0,1,0>.  So as all other image types use the upper
left as origin together with this "compensation" it would be really illogical
to use the lower left for function images and thus not to compensate for it
just to allow Rune's special case exception.


    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

"Rune" wrote:
> There's no need for any exceptions or special cases.

Sorry Chris, from Thorsten's replies I can understand that I misunderstood
something. If internally the function image type is reversed due to the way
all image maps work, then a special case should be made for the function
image type so that it isn't reversed, and so that it works in a consistent
way for the user.

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:
> Yes, because I said you should use an image map
> instead of the function image to see that it works
> correctly:

All other image types may work correctly, but the function image type is
reversed. I'm not saying that all image types are wrong, just the function
image type. It may be that internally the function image type works
consistently with the other image types, but for the user it works very
inconsistently with the other image types, and this should be corrected. The
current behavior is highly unintuitive and very annoying to work with.

> This is the way image maps always worked, so it won't
> be changed because it would break far too many scenes.

So you're saying that a thing like reversing just one image type (the
function image type), which sounds like a piece of cake to do, actually is a
difficult task to change??? I had no idea!

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 <3caf30b1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> But then it wouldn't be an image map any more:  The image simply can't know
> where and how it is applied.  What you are suggesting sounds like uv-mapping
> of some kind.

I'm not talking about the mapping applied to the image. I'm just saying 
that people aren't going to think in the internal POV-Ray image 
coordinate system when writing a function that may or may not be used in 
an image, and they shouldn't have to.


> Sure, the origin can be chosen arbitrarily, but for all computer images the
> accepted standard (probably because that is where the beam usually starts on
> CRTs) is to have the origin at the upper left rather than the lower left
> commonly used in mathematics.

Actually, that is just an arbitrary choice. Most image formats work that 
way, but you can't make the assumption all do. There are several other 
formats besides TIFF that use different systems (I think SGI RGB is 
one), and some popular API's (OpenGL for example) use the lower left 
corner as the origin.

POV should compensate for the fact that a function's origin is at < 0, 
0, 0>, and not < 0, 1, 0>, as most image file formats have it. The 
internal coordinate system of the image should be hidden from the user. 
All they should have to care about is where the "top left" and "bottom 
right" map to in the scene coordinate system. Exposing it in this way is 
inconsistent, counter-intuitive and very user-unfriendly.

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

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

> All other image types may work correctly, but the function image type is
> reversed.

No, it isn't reversed, it only appears to be because of different coordinate
systems.  When generating the image the origin and coordiante system of an
image is used.  This means that the upper left is (0,0) and the lower right of
the image generated is function value (1,1).  This is consistent with the way
all image coordinates work.  Now, you are trying to place the image with its
origin (and coordinate system) over a function as a pattern which uses a
different origin (and coordinate system).

This isn't different from moving the box somewhere else and expecting the
image still to match the other function's origin.

    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

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> I'm not talking about the mapping applied to the image. I'm just saying
> that people aren't going to think in the internal POV-Ray image
> coordinate system when writing a function that may or may not be used in
> an image, and they shouldn't have to.

This has nothing to do with "to think in the internal POV-Ray image coordinate
system" - see below.

> POV should compensate for the fact that a function's origin is at < 0,
> 0, 0>, and not < 0, 1, 0>, as most image file formats have it. The
> internal coordinate system of the image should be hidden from the user.

But there is no "internal coordinate system"!  The coordinate system used in
images is extremely important as otherwise images could have a random
orientation.  One simply cannot use images without defining their origin and
coordinate system.  As soon as you edit the image you are going to expose the
origin as well as the coordinate system to the user.  Without doing so editing
images would not be possible.

In conclusion the origin as well as the coordinate system are well defined in
POV-Ray and function images use this well defined coordinate system.  Sure,
this cannot fit all needs, but changing this simple and obvious origin and
coordinate system to some completely randomly choosing different origin and
coordinate system just to make it work in this one special buggy scene file is
simply unreasonable.

If you find it reasonable, fine, but I don't and given my clear and simple
reasoning I am not going to change my mind.  So we will continue to disagree
on this and any further discussion will lead nowhere.

    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" wrote:
> No, it isn't reversed, it only appears to be because
> of different coordinate systems.

Right, then one coordinate system is reversed vertically compared to the
other. Why do you say it isn't reversed when obviously everyone can see that
it is indeed reversed, no matter what you choose to call it?

> When generating the image the origin and coordiante
> system of an image is used.  This means that the
> upper left is (0,0) and the lower right of the image
> generated is function value (1,1).

Yet, strangely, when using an image map the upper left corner is at (0,1)
and the lower right corner is at (1,0). This is because POV-Ray takes care
of the correction for the user.

Why can't POV-Ray correct the alignment for the user when using the function
image type, so that the user won't see any hint of reversed coordinates?

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:
> But there is no "internal coordinate system"!
> The coordinate system used in images is extremely
> important as otherwise images could have a random
> orientation.

Agreed, coordinates are important. However, when working with images, users
expect up to be up and down to be down. They don't think that (0,0) must
always be (0,0) and (1,1) must always be (1,1) regardless of the coordinate
system used.

> One simply cannot use images without defining their
> origin and coordinate system.

Agreed.

> As soon as you edit the image you are going to
> expose the origin as well as the coordinate system
> to the user.

Depends on your definition of "exposing". Though many graphics programs show
the coordinates while editing, it's perfectly possible to draw an image
without thinking about the coordinates.

> Without doing so editing images would not be possible.

See above.

> In conclusion the origin as well as the coordinate system
> are well defined in POV-Ray and function images use this
> well defined coordinate system.

Images use one coordinate system while POV-Ray space use another coordinate
system. POV-Ray compensates for this, so that up remains up and down remains
down. But functions do not use a different coordinate system, and thus no
compensation should be done. In functions, when considering the square from
(0,0) to (1,1), it is the lower left corner that is the origin. Thus no
compensation should be done. Applying the compensation anyway only reverses
the image so that it's upside down.

> Sure, this cannot fit all needs, but changing this simple
> and obvious origin and coordinate system to some completely
> randomly choosing different origin and coordinate system
> just to make it work in this one special buggy scene file is
> simply unreasonable.

We're not discussing a random chosen origin and coordinate system. We're
discussing making sure that the alignment is correct regardless of the
origin and coordinate system used. I.e. making sure that upper right remains
upper right, lower left remains lower left etc. This is completely
consistent and reasonable and even intuitive too.

> If you find it reasonable, fine, but I don't and given
> my clear and simple reasoning I am not going to change
> my mind.

I find my reasoning clear and reasonable too and would like to continue to
discuss this matter.

> So we will continue to disagree
> on this and any further discussion will lead nowhere.

You haven't argued why POV-Ray should compensate in this case where
compensation is incorrect. All you have said is something like "compensation
is done for all image types and therefore it is correct". That isn't an
argument.

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 <3caf823a@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Right, then one coordinate system is reversed vertically compared to the
> other. Why do you say it isn't reversed when obviously everyone can see that
> it is indeed reversed, no matter what you choose to call it?

It isn't reversed. It is in exactly in the same coordinate system as in all
other images!

>> When generating the image the origin and coordiante
>> system of an image is used.  This means that the
>> upper left is (0,0) and the lower right of the image
>> generated is function value (1,1).
>
> Yet, strangely, when using an image map the upper left corner is at (0,1)
> and the lower right corner is at (1,0). This is because POV-Ray takes care
> of the correction for the user.
>
> Why can't POV-Ray correct the alignment for the user when using the function
> image type, so that the user won't see any hint of reversed coordinates?

It is correct just like for all other image map types.  As I pointed out, try
to substitute the function image by a plain image map.  You will notice that
the origin of the image is of course still at (0,0) in image coordinates,
which equals (0,1,0) in POV-Ray coordinates.  The function is also at exactly
this place, (0,0) in image coordinates and (0,1,0) in POV-Ray coordinates.

So you generate an image using a function inside the image coordinate system,
which goes from (0,0) to (1,1) where (0,0) is defined as the upper left and
(1,1) as the lower right.  The (0,0) is then mapped to (0,1,0) and the (1,1)
is mapped to (1,0,0) like for all other image formats.


    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" wrote:
> It isn't reversed. It is in exactly in the same
> coordinate system as in all other images!

Please see my other reply to you in this thread where I have better
explained my point.

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

It will be interesting to see how many more of these Rune vs. Thorsten
fights will we see before the final release... ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" wrote:
>   It will be interesting to see how many more of these
> Rune vs. Thorsten fights will we see before the final
> release... ;)

I consider a discussion to be an attempt at obtaining mutual understanding.
I don't care if Thorsten convinces me or I convince him, I just don't like
when one part quit the discussion before mutual understanding has been
reached...

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 <run### [at] mobilixnetdk> wrote:
> I consider a discussion to be an attempt at obtaining mutual understanding.
> I don't care if Thorsten convinces me or I convince him, I just don't like
> when one part quit the discussion before mutual understanding has been
> reached...

  Sometimes just stopping is the only solution if the other one just refuses
or is incapable of understanding.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" wrote:
> Sometimes just stopping is the only solution if the
> other one just refuses or is incapable of understanding.

But I don't think Thorsten is incapable of understanding... ;)

Seriously, I don't think Thorsten have responded to my argument yet, so I
think it would be fair to keep the discussion running as long as we keep
getting closer to mutual understanding, as I think we are.

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

On Sat, 6 Apr 2002 00:23:15 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> The function image type is mirrored vertically.

As I understand all those discussion (with my poor language):

When function 100, 100 {...} is performed it means that engine samples space
from <0,0,0> to <1,1,0> and makes grid of values. After sampling it isn't
coordinate system at all. It is internally flat grid/array[100][100] of values
just like grid with values of pixels/colors in images. Then it is passed to the
same procedure as typical image. This is separated procedure and it doesn't
metter what grid is. Grid is a grid, it is placed/mapped from <0,1,0> to <1,0,0>
becouse general rule for images is that first line of grid makes top line of
image. Right ?

ABX

Post a reply to this message

On Sun, 07 Apr 2002 18:50:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> No, a real image is generated internally, there is no special traetment for
> function images at all.

so, at parse time internal grid (as image) is generated by sampling content of
function, and rest about mapping rules is right in my post ?

ABX

Post a reply to this message

In article <seu0bu45o99vgvg0cn804nrckdd3p1bs6h@4ax.com> , W„odzimierz ABX 
Skiba <abx### [at] babilonorg>  wrote:

> and rest about mapping rules is right in my post ?

Yes.

    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" wrote:
> W"odzimierz ABX Skiba wrote:
> > and rest about mapping rules is right in my post ?
>
> Yes.

The problem is that POV-Ray assumes the pattern function to have the origin
in the upper left corner like all the other image types, when in fact
patterns have the origin in the lower left corner *unlike* all the other
image types. So just because all the other image types are reversed, it
doesn't mean that the function image type should be too. Thorsten, I haven't
yet heard your argument against this.

In POV-Ray x is defined as right and y is defined as up. Thus, when
considering the square from <0,0,0> to <1,1,0>, which is the square POV-Ray
use for the pattern image type, the origin is in the lower left corner, not
the upper left corner. If you refuse to change the feature, could you please
explain why?

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

On Mon, 8 Apr 2002 16:51:49 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> In POV-Ray x is defined as right and y is defined as up.

here is my imagination of internal behaviour :

// get dimensions from script
#declare GridX=100;
#declare GridY=100;

// get function from script
#declare Content = function (x,y,z) { ... };

// create internal image as grid of values like other images
#local Image=array[GridX][GridY];

// run loop over function - array coordinates are coordinates on xy plane

#local Z=0;
#local X=0;
#while ( X/(GridX-1) <= 1 )
  #local Y=0;
  #while ( Y/(GridY-1) <= 1 )
    #local Image[X][Y] = Content(X,Y,Z); // nothing is reversed in grid
    #local Y=Y+1;
  #end
  #local X=X+1;
#end

// now content is array with image/grid of values
// put it to general procedure for all image types
// this is unified procedure for all images
// no internal handling for function images

#macro CreateFunctionFromImage(x,y,z,Image)
  #local ImageX = X;
  #local ImageY = 1-Y // becouse first line of image is top line on screen
  function{ Image( ImageX , ImageY, 0 ) }
#end

ABX

Post a reply to this message

"W³odzimierz ABX Skiba" wrote:
> here is my imagination of internal behaviour

Sorry, but the internal behavior really isn't the issue here. Technically
I'm sure it would be no problem to change the pattern image type if it was
desired. The issue is if the current behavior is right or 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

On Mon, 8 Apr 2002 18:31:33 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> The issue is if the current behavior is right or wrong.

For me as user it is just automatic behaviour. If I know this behaviour (I know
it becouse of You, thanks btw) I can control it. Your problem is kind of:
why function{pattern{checker}} is different than
function{pigment{checker}.gray}}

ABX

Post a reply to this message

On Sun, 7 Apr 2002 17:54:01 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> I don't think Thorsten have responded to my argument yet

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.

ABX

Post a reply to this message

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

> The problem is that POV-Ray assumes the pattern function to have the origin
> in the upper left corner like all the other image types, when in fact
> patterns have the origin in the lower left corner *unlike* all the other
> image types. So just because all the other image types are reversed, it
> doesn't mean that the function image type should be too. Thorsten, I haven't
> yet heard your argument against this.

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.

    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

"W³odzimierz ABX Skiba" wrote:
> 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