Consider this scene (basically a stripped-down version of Insert > Scene
templates > Orthographic scene, with an added background).

camera { orthographic location <0, 0, -1> look_at <0, 0, 0> right 1*x up
1*y }
box { <-.5, -.5, 0>, <.5, .5, 0> pigment { rgb 0 } }
background { blue 1 }

As noted in the comments in the scene template, the box fits exactly in the
view, and thus completely blocks out the background. At least that's what
should happen. However, with anti-aliasing on (use method 2 with no jitter)
you can see a line of blue down the left and bottom side of the image.
Further investigation showed that, indeed, POV-Ray always shifts the image
up and right by half a pixel (whether or not anti-aliasing is on).

POV-Ray 3.5 beta 6, Windows 98, Athlon, 256 MB.

Post a reply to this message

Norbert

> Further investigation showed that, indeed, POV-Ray always shifts the image
> up and right by half a pixel (whether or not anti-aliasing is on).

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:


  The fact that it has always been that way doesn't make it the right
behaviour...
  Perhaps some consideration should be given to this issue.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

> > Further investigation showed that, indeed, POV-Ray always shifts the
image
> > up and right by half a pixel (whether or not anti-aliasing is on).
>


So was the bug in SOR, which was my first bug report here (in fact the
reason I came to these newsgroups), as well the text spacing bug I found.
Just because earlier versions behaved the same way doesn't mean that
behavior is right. In this case, it's clearly not.

Post a reply to this message

On Wed, 17 Oct 2001 21:14:04 +0200, "Norbert Kern"
<nor### [at] t-onlinede> wrote:


>
>> Further investigation showed that, indeed, POV-Ray always shifts the image
>> up and right by half a pixel (whether or not anti-aliasing is on).

Just shows that if it's a bug it's an old bug. IIRC even DKB-Trace did
it that way, but it's been a while. 

/Erkki

Post a reply to this message

Warp wrote:
> 
> Norbert Kern <nor### [at] t-onlinede> wrote:

> 
>   The fact that it has always been that way doesn't make it the right
> behaviour...
>   Perhaps some consideration should be given to this issue.

It isn't painfully obvious on large images, but when I was working on
"Showbots" (IRTC entry from last year), I was rendering some scenes at
40x30 (to accomplish the digital censoring), and the shift was
definitely perceptible.  I worked around it by adjusting the camera
angle, but there's got to be a better way.

I would venture to say that the centerpoint of the screen is always
rounded up or down, instead of being left at, say, (319.5,239.5),
which is where it should be for a 640x480 screen.

-- 
ICQ: 46085459

Post a reply to this message

> I would venture to say that the centerpoint of the screen is always
> rounded up or down, instead of being left at, say, (319.5,239.5),
> which is where it should be for a 640x480 screen.

No; looking at the POV-Ray 3.1 source, the problem is that, the x paramater
passed to create_ray() ranges from -0.5 to 639.5, and the y parameter ranges
from -0.5 to 479.5. Also (related), the center of pixel (100, 200) should be
(100.5, 200.5) rather than (100, 200) as it is now.

The easiest fix, although not the most elegant, is in create_ray() itself.
(This is under perspective camera; there are similar lines under every
camera type. Why shouldn't x0 and y0 be computed once, at the beginning of
this function? Then they can be scaled as necessary for some camera types.)
Anyway, the lines

      /* Convert the x coordinate to be a DBL from -0.5 to 0.5. */
      x0 = x / (DBL)Frame.Screen_Width - 0.5;
      /* Convert the y coordinate to be a DBL from -0.5 to 0.5. */
      y0 = ((DBL)(Frame.Screen_Height - 1) - y) / (DBL)Frame.Screen_Height -
0.5;

can be replaced with

      /* Convert the x coordinate to be a DBL from -0.5 to 0.5. */
      x0 = (x + 0.5) / (DBL)Frame.Screen_Width - 0.5;
      /* Convert the y coordinate to be a DBL from -0.5 to 0.5. */
      y0 = 0.5 - (y + 0.5) / (DBL)Frame.Screen_Height;

(similarly for other projections) and the problem goes away.

The better fix, which isn't that much harder, is to rework the code to use x
values in [0, width] and y values in [0, height], and pixels centered at
(mmm.5, nnn.5), as they should be. When antialiasing is not used, and you
are on pixel (i, j) (where i, j are integers from 0 to width-1 and 0 to
height-1), call create_ray with (i+.5, j+.5). When antialiasing is used,
make the values vary from (i, j) to (i+1, j+1). You also have to change each
(Frame.Screen_Height - 1) in create_ray to simply Frame.Screen_Height.

Anders

Post a reply to this message

Would this work with odd sized renders?

Post a reply to this message

> Would this work with odd sized renders?

Yes. By the time the height is divided by two, it has already been converted
into a double.

Anders

Post a reply to this message

This bug is still present in beta 7. (Should I be posting these kinds of
messages? Ron thanked me earlier for sticking with my first bug report, so I
assume that I should.)

Post a reply to this message