Alejandro Saez (cano++at++silicon.cl)
Wed, 29 Apr 1998 12:20:00 -0400
Jim,
Sure, no sweat. I don't know if you know how Z buffer works, so here is
a small explanation. Z buffer is used to determine which primitives oclude
other primitives. For each pixel in the frame buffer, there is a corresponding
"point" in the Z buffer, this point holds distance information. Each time a
pixel corresponding to a primitive (i.e, triangle) is to be drawn, it is first
check against the Z buffer. If a pixel was te be drawn at coordinates 10,15 in
the frame buffer, and say this point is a 100 meters away from the observer,
then the system checks what's the distance stored in the frame buffer, if this
distance is less than 100, then the new pixel is not drawn, because some other
pixel has been drawn before which is closer to the observer than the new pixel,
thus ocluding it. If the distance stored in the Z buffer is greater than 100,
then the pixel is drawn because the previously drawn pixel is further away from
the observer, at the same time, the Z buffer distance for that coordinate is
updated to 100 meters. The thing goes on until the whole scene has been drawn,
and occasionaly during this process another primitive will try to project a
pixel in the same coordinate, an again the Z buffer is checked, and if this
other pixel is closer than 100 meters, both frame and Z buffer are again
updated. During the screen refresh, the frame buffer is initialized to
background color and the Z buffer is initialized so that each point in it, is
holding infinite distance.
Now, how does is this distance information stored in the Z buffer. Well
it is coded as integer numbers in a logarithmic scale. Why?? Because if it
wasn't a log scale then you would have a too small range, and what's worst, two
points a couple of inches apar but close to the observer would probably get the
same resolution ( say 2 bits) as two points that are 100 meters aparts but are
far from the observer. By using the log scale, you get a lot of bits to
differentiate points that are close to the observer, and get continuosly less
bits for points far away from him. Now since objects close to the observer
should have greater detail, smaller and closer polyigons than objects in a low
LOD sitting far appart, this should work, shouldn't it? Well, not always. This
is still a discreet scale, meaning that two objects sitting close (by "close"
I don't necessarily mean fisically close, but ones whose distances map to close
points in the log scale), but that are not in the same point could end up in
the Z buffer as being in the same fisical point due to round-off and
dicretizarion errors. What's worst during one frame one point belonging to a
primitive could appear to be closer than other point belonging to another
primitive, and since this is a discretization error, during the next frame,
where the observer and/or objects have move a bit, the situation reverses, and
then again. The effect would be pixels of both primitives fighting to get
displayed in the screen, which resembles a bit of your description of "ghost
polygons".
How can this be solved, two ways:
a) Get a visual (or a machine) with more Z bits, this increasing the
accuracy of the Z buffer. Since you said you were displaying in quad-buff mode
or something, then probably some bits previously used as Z buffer bits, are
being used in the frame buffers.
b) The log scale is not fixed, it depends on the far/near plane. This
is obvious, when you think about it. If you are using (as an example) 24 bits
of Z buffer (that is 16 million diferent "distances" can be told appart) and
you have a near plane of 1 and a far plane of 100000000, the Z buffer has to
use those 16 million combinations to represente all dsitances from 1 to
100000000. If as I said, a lot of those bits are used for near objects, then at
the end of the scale, two objects that are 200 meters appart won't be really
appart for the Z buffer, they will map to the same discreet distance. This is
specially true when having detailed objects for away (another reason to use
LODs). So what's the solution, change one of the planes, if you are flying up
high, then it could be a good idea to increase the near plane. If on the
contrary you are in a driving simulation, then bringing the far plane down is
the way to go (of course you can do both). The question is :How much? Well the
usually given recepy is that the far/near ratio should be arround 1000, but if
think this is too strict and as I said it depends on the number of Z bits
available, the kind of simulation (air, ground) and the complexity of the
scene. I can usualy get away with 10000 for fairly complex ground simulations.
Oops, this is way longer than it should've, but it's already done, so
good luck
--
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
Avda. Andres Bello 2777, Of. 602
E-mail: asaez++at++silicon.cl Providencia
Phone: +56 (2) 203 3371 Ext. 105 Santiago
Fax: +56 (2) 203 3370 Chile
------------------------------------------------------------------------
===================================List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:19 PDT