Re: [Mesa3d-dev] New Mesa 3.2 Bugs - One serious (I think)

[Stephen J B. <sj...@li...>]

On Mon, 19 Jun 2000, Mark Paton wrote:

>    I am just starting to learn Mesa at a lower level and don't know too
> many the details of the rendering engine yet but:
>    The basic problem here seems to be that we are culling triangles
> without regard to its neighbouring triangles. I expect this would
> be very difficult to do and it is desirable to treat each triangle
> independently. However, wouldn't a solution be that the smallest 
> a triangle can be is one pixel - e.g. the scan conversion for this
> triangle is automatic. If a triangle is mathematically smaller then a
> pixel area its rasterization is just the nearest pixel. Then the 
> depth buffer test and other rendering details are processed accordingly.
>    Then if you do something crazy like rendering 50 million polygons in
> a 72x72 pixel box (which I tried). The system will have to render 50 
> million pixels, and many of them will be the same pixel but the result
> will be correct. Is this a valid thing to consider? I am assuming here
> that the numeric instibility problems are caused by attempting to scan
> convert a mathematically tiny triangle.  
 
You'd think that would be OK wouldn't you...but it's not.  :-(

Imagine a single pixel sphere made from a hundred red triangles each
with an alpha of 0.1 - rendered onto a black background.

If you rendered that in a truly correct manner, the colour of the
resulting pixel would be RGB=(0.1,0,0), but if each triangle
is forced to cover the entire pixel, you get nearly 100% red
because each triangle hides only 1/10th of the colour of the one
behind it - then adds 0.1 of its own colour...do that 100 times
and you have:

  0.1 + 0.9 * ( 0.1 + 0.9 * ( 0.1 ...a hundred times...... ))

...which sums to something like 0.9999999999 - peak red.

What you *should* do is to have the triangle be discarded unless
it covers the very center of the pixel...no matter how small that
triangle is.

This isn't a problem that's unique to very small triangles.

Even a large triangle that *touches* a pixel without covering
the exact center of the pixel should not render to it or else
you'll get a row of bright 'beads' running along the edges
of two translucent triangles that share a common edge.

Since Mesa already gets that right, using the existing rasterizer
should be OK so long as the polygon isn't simply discarded.

You might also want to think about what happens when a bunch of
long thin triangles meet at a point.  Each one is large - so the
small triangle test won't discard it - yet 360 one-degree-wide
triangles meeting at a point still have to make up a solid circle.

The answer to all of these problems is to stop thinking of pixels
as being little squares - but instead to think of them as infinitely
small points. Instead of thinking about whether a polygon touches
some point on a square pixel, think about whether the polygon covers
that infinitesimal point at the center of the pixel.

Of course if you are antialiasing - then thinking of pixels as
areas becomes sensible again.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1