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

["Ben Davis" <ben@xxxxxxxxxx>]

Don't apply my last patch for poly3d.c. It conflicts with a patch that has
already been applied. I'll come out with a new patch soon enough.

Important question at the end of this e-mail - don't miss it!

Bertrand Coconnier wrote:
> > Rather than ensuring the
> > edges are stored in clockwise order, the routine is now adapted
> to handle
> > both scenarios.
>
> Well, the routine already handled both cases. At least, it was supposed
> to :-)

I mean, once the list of edges is made, the rest of the routine can handle
it going in either direction. draw_polygon_segment() simply swaps e1 and e2
if they're the wrong way round. In do_polygon3d(), left_edge really refers
to the one that keeps doing an edge=edge->prev and right_edge is the one
that keeps doing an edge=edge->next. They may not actually be at the left
and right.

This eliminates the need for a clockwise/anticlockwise test.

> >  I had to change
> > the prototypes in aintern.h - but seriously, do those
> prototypes need to be
> > there?
>
> I guess some people planned to use them in some other routines.
> IMHO fill_3d_edge_structure[_f]() can safely be declared 'static' and
> the prototypes can be removed from aintern.h

OK, I'll remove them then. Do you want me to remove the leading underline as
well (fill_... as opposed to _fill_...)?

> Routines in poly3d.c have been massively rewritten since the last WIP.

I noticed :-)

> The main purposes were to add subpixel and subtexel accuracy but also to
> focus on FLAT poly speed enhancement. This is why the routines has
> changed so much. BTW I introduced some bugs which did not exist in the
> last
> WIP :-( I have released some patches to fix them and I hope your patch
> fixes the very last bug of poly3d.c

I was just looking at the last patch. I have a question - see the end of
this e-mail.

> A 3D polygon rasterizer *never* draws 1-pixel-thick polygons. In fact
> the right and bottom edges of a polygon are not drawn in order to avoid
> overdrawing.

I know.

> I don't understand how your patch fills the gap with 1-pixel-thick
> polygons ?!?

You could say they're 2-pixel thick then :-) They appear 1-pixel thick on
the screen. It's that fceil() function that does it, I think - otherwise
there wouldn't be a gap to fill with a thin polygon. Would it be better to
round it to the nearest?

QUESTION: In the last WIP or whenever, setting u,v to whole numbers would
indicate the centre of a texel. In the version I got from CVS and modified
(probably 1.9), setting u,v to whole numbers would indicate the top-left
corner of a texel. I thought this was a bug-fix, and I was pleased. Then I
realised it had changed back in version 1.10. Is there a reason for this?

IMHO it's better the way it was in version 1.9. Otherwise I'll have to be
persistent and use -0.5 and 127.5 for my texture coordinates :-)

Ben Davis