Path: chuka.playstation.co.uk!news
From: Andreas Schrattenecker <"Andreas Schrattenecker">
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: HELP:small planar quads
Date: Thu, 15 Jan 1998 22:52:45 +0100
Organization: PlayStation Net Yaroze (SCEE)
Lines: 94
Message-ID: <34BE852D.1B61@jk.uni-linz.ac.at>
References: <69ilnb$c4e1@emeka.playstation.co.uk> <34BCEC93.4581@jk.uni-linz.ac.at> <01bd212d$f848afc0$77e16dc0@ulthar.han.de> <34BD58FB.37C5@jk.uni-linz.ac.at>
Reply-To: andreas.schrattenecker@jk.uni-linz.ac.at
NNTP-Posting-Host: ried-remote12.ivnet.co.at
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.02 [de] (OS/2; I)

After thinking over, what has been said yesterday, and after
some more testing, i think i know whats wrong in the LIBs 
regarding the handling of small-quads.

1) testing of visibility is not done with the traditional
backface-culling
   methode (looking at the angle between poly-normal and
eye-to-vertex-vector),
   but, like Lewis Evans said, depends on the order of vertices on
SCREEN

   If you look on top of a (visible) quad, and define the vertices
following

   2 3 0 1

   2     3 
   * --- *
      /
     /
   * --> *
   0     1

   after local-to-screen transformation and perspective conversion,
   the quad is handled as visible if the calculated SCREEN-coords
   (always looking on first 3 vertices) are still:

   2:top-left 3:top-right 0:bottom-left

   or:	

   1 0 3 2

   2     3 
   * <-- *
      /
     /
   * --- *
   0     1

   1:bottom-right 0:bottom-left 3:top-right

2) Like Roland Boettcher said, inaccuracies of fixedpoint calculations 
   are involved. (inaccuracies of calculated SCREEN-coords).
   But to say, errors due to inaccuracies happen, and you can nothing do
   against the errors, would not be right. Inaccuracies always have to
be
   handeld different, depending what is done with the results.

The problems with small quads crop up if SCREEN-coords fall together.
While it seems this is handled correct in triangles, it isnt in quads
(it seems to be handled same as in triangles).

What i have seen: If 2 or 3 of the 3 SCREEN-coords
(3 in triangles, first 3 in quads) fall together, it is handled as
not-visible

for example:

   2     3 
   * --- *
      /
     /
   * --- *
   0     1

   SCREEN-coords 2 & 0 fall together	

   in Triangle:
  
      two Triangles: 2 3 0 , 3 1 0	
      230 is not drawn, 310 is drawn -> OK, because 310 covers 230

   in Quads:

      one PLANAR-Quad: 2 3 0 1
      230 is taken for visible-detection, and handled as not-visible
      not drawn, although quad is visible
      
  
This quads-error appears not only on quads with not-reasonable angles.
It appears also if you go into more "polygon-detail", and there are
a lot of moire-effects. Sometimes large areas are not drawn.

To correct this outside the libs, i have to calculate (in realtime)
the angle and distance to quads, and if detecting problem-quads,
pull vertices in a direction, that SCREEN-coords dont fall together.
Needless to say that this eats performance.
I can remember on a thread with David White, who had to calculate
the areas of the 2 triangles in quads, for his particular case...


If i am wrong please let me know
Andreas Schrattenecker