Re: [AD] Bug in clip3d_f() / polygon3d_f()

[George Foot <gfoot@xxxxxxxxxx>]

On Fri, Dec 22, 2000 at 01:36:17AM +0100, Bertrand Coconnier wrote:
> May be, but when I want a rectangle to be drawn from pixel (0,0) to
> pixel (31,31) I do not call rect(bmp,0,0,32,32,c) but
> rect(bmp,0,0,31,31,c) which is more intuitive.

I thought of this too, but in some ways texturing is more like
blitting.  However, with blitting you specify the width of the
area, not the coordinate of the bottom-right corner, so it's not
so comparable.

> I know but what I mean is that tilling behaves in a strange way :
> according to your convention, drawing a texture from (0,0) to (32,32) is
> the same thing than drawing a texture from (32,32) to (64,64) so it
> seems a texel is shared (but it is not).

That's still the case with the current code.  I think one
important thing to consider is what the polygon rendering code
does in any case -- if I tell it to draw to a screen region
equal to the texture coordinates then I expect it to effectively
blit the texture, with no artifacts and no missing pixel
columns.  The old code wouldn't do this, and assuming the
rasterizers do draw the pixels you specify, the new code is
wrong too.

To explain this better, imagine we draw a square from (0,0) to
(32,0) to (32,32) to (0,32), using the same values as the u,v
coordinates in our 32x32 texture.  How long is each side of the
square?  If it's 32x32, then Ben's solution is fine.  If it's
33x33 (as I expect) then the polygon drawing is inclusive of the
endpoints, so the texturing should also be inclusive.  In this
case we need to adjust the target u for each scanline.

It think it might help a lot if the u,v coordinates
to refer to the same position in the texel as the x,y
coordinates do in the pixel.  Since line drawing generally uses
the centres of the endpoint pixels, the old code would then be
correct, but it depends how Allegro treats its fixed/float
coordinates -- are whole numbers still the centres of pixels, or
are they the top left corners?

> I agree :-) In fact you made me understand that due to the way Allegro
> computes gradients it "forgets" one texel. Therefore in the very first
> version of the polygon renderer, the right column and the bottom row of
> the texture were not drawn : this was a bug. In order to fix it, Calin
> Andrian added 0.5 to the gradients to shift the whole texture of a
> half-texel to the up/left corner. That way, the bottom row and right
> column were drawn and the top row and left column were still drawn but,
> as you said, edges of the texture were a half-texel thick.
> So, you suggest to remove all those "0.5" and to "remind" Allegro to
> draw the last texel by incrementing the bottom/right texture coordinates
> by ourselves.

I don't think it forgets a texel, I think it draws too many
pixels and takes them all into account...

> IMHO we can reach that goal in another way. So far, the gradients for
> texture coordinates are computed this way :
> du = (right_u - left_u) / scanline_width
> while it should have been :
> if (right_u > left_u)
>    du = (right_u + 1 - left_u) / scanline_width
> else
>    du = (right_u - 1 - left_u) / scanline_width
> This way, the right column texel is not forgotten anymore and it
> prevents the user to increment the bottom/left corner texture
> coordinates by himself/herself. BTW the 0.5 texel shift is not needed
> anymore. 

An important thing I'm trying to consider here is that if you
draw two polygons which share an edge then you should be able to
use the same vertex data for the shared vertices -- screen
coordinates *and* u,v coordinates.  It looks like Allegro was
broken already here, but I don't think your solution is correct
-- I think this is better:

    du = (right_u - left_u) / (scanline_width-1)

This makes the u,v of the right hand edge be applied to the
pixel before the last one drawn, because the last one is an
overlap to the next tile of the polygon to the right.

I'm not sure what to think of this extra pixel though.  If
you're tiling polygons and sharing vertex data between them,
Allegro is (probably) drawing an extra pixel so you need this
u,v correction to be applied.  If you're just drawing single
polygons, though, you might not think of it as drawing an extra
pixel, though it will be making your polygons slightly fatter
than they should be (if you specify the square I mentioned
above, its dimensions ought to be 32 along each side).  Maybe in
fact Allegro shouldn't draw this overlap pixel -- but there's a
risk that this will make gaps between polygons due to rounding
errors.  If we did that, though, there would be no need to tweak
u,v coordinates or gradients at all.

George

-- 
Random project update:
22/06/2000: AllegroGL alpha 8 released at http://allegrogl.sourceforge.net/
        Improved Windows support.  New directory structure.
        Fixed OpenGL coding mistake in `tex.c'.