Excellent explanation Justin! That was clear and understandable.
My guess is that some of the weird effects that we see are because of
the first part, "Is the entire polygon visible or not". With a little
bit of float precision error as you turn the view, a vertex of a large
polygon may flicker between visible or not visible. And that seems like
it could result in large display differences. The scan line comparisions
that would not be computed when the entire polygon is considered "not
visible" are suddenly computed, when that little bit of round off brings
a vertex "visible", resulting in large sections of a polygon jumping in
front of the otherwise occluding polygon.
- John
Justin Couch wrote:
>
> John Wright wrote:
>
> > find it difficult to believe that a graphics card could calculate all
> > pixel locations for potentially tens of thousands of polygons for nearly
> > a 1 million pixel display (1024x768) all in 1/100th of a second? I'm
> > guessing that they somehow optimize this to reduce the raw power needed.
>
> Yes, that is something done by the video card. PC type cards have had
> hardware Z buffers since at least 1995 back when I had my old Matrox
> Impression Plus. Depth testing is a very simple thing - you don't do it
> for each pixel.
>
> The simplified algorithm for how this is done is:
>
> - Is the entire polygon is visible or not? It does this by looking at
> the average depth of the polgon. There are different approaches to this
> including full polygon depth sorting in the view space coordinates, but
> the simplest is to convert the verticies to screen space and test the z
> values of each vertex in the depth buffer. If all the vertices are
> deeper than the current values, toss the polygon away.
>
> - If the entire polygon is in front, start to render it, scanline
> fashion. As you are calculating the values, you can check start and end
> points of the current face part. If both are lower than the current
> depth values, toss the line away. If both higher, draw the entire line
> and ignore depth calculations - just do lighting
>
> - If the polygon intersects with the other polygon(s), scanline render
> and test every depth. Some implementations will attempt to segment the
> polygon into entirely visible and entirely invisible parts and then
> throw away the invisible part.
>
> Where you run into problems (always) is the floating point accuracy. If
> you get two polygons that are very close together in relative depth, the
> inaccuracies of a floating point calculation due to rounding errors
> allows a fair amount of wiggle room. Thus, you get z-buffer tearing as
> you end up with two co-planar polygons, or at the very intersection of
> two intersecting polygons. The tearing is due to this floating point
> precision. Effectively, what the depth buffer does is allocate an int
> value of either 16 bits or 32 bits for each pixel on screen. Each value
> of the int becomes one depth value. Each depth increment is determined
> by (back_clip_distance - front_clip_distance) / sizeof(int) . So, what
> happens is your card determines the exact depth as a float and then
> casts it back to one of the int values. Then, to determine if the new
> value is deeper than the current value, it is a simple integer
> difference rather than a vector calculation. Thus, with two values close
> together, and both reduced to the same depth buffer int value for the
> depth you get the inaccuracies.
>
> --
> Justin Couch http://www.vlc.com.au/~justin/
> Freelance Java Consultant http://www.yumetech.com/
> Author, Java 3D FAQ Maintainer http://www.j3d.org/
> -------------------------------------------------------------------
> "Humanism is dead. Animals think, feel; so do machines now.
> Neither man nor woman is the measure of all things. Every organism
> processes data according to its domain, its environment; you, with
> all your brains, would be useless in a mouse's universe..."
> - Greg Bear, Slant
> -------------------------------------------------------------------
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
