"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

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

> 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