Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!megatek!siesta!rgs
From: rgs@siesta.megatek.uucp (Rusty Sanders)
Newsgroups: comp.sys.sgi
Subject: Re: Z-buffering Problems...
Message-ID: <338@megatek.UUCP>
Date: 22 Apr 88 19:20:27 GMT
References: <8804211723.AA25090@nps-cs.arpa>
Sender: news@megatek.UUCP
Lines: 54

From article <8804211723.AA25090@nps-cs.arpa>, by zyda@NPS-CS.ARPA (michael zyda):
> IRIS 4D/70G Z-Buffering Problems...
> 
>   One of my students is having some problems with the z-buffering
> on the IRIS-4D.
[...]
> 
>   Problem: At the intersection of the sea and land you cannot 
> rely on the Z-buffer to always draw the land over the water 
> or even to consistently draw it the same. This is with near and 
> far clipping planes set to 100yds and 120000yds respectively.

The Z-buffer on the 4D is 24 bits deep, which would imply that the resolution
would be 1 part in 2^24 (1 part in 16777216). Your model (if accurate to the
.1 yard level) requires only one part in 1200000, which is about 2^20.195. One
would think that this would be easy to represent.

Unfortunately, it just ain't so. While there may be 24 bits to store the data,
nowhere near that many bits are accurate. The first bit of accuracy is obvious,
IEEE only has 23 bits of mantissa. Feeding the pipe in double precision may
help a little bit there, but I doubt it. SGI does it's math in the pipe in
some single precision form (not IEEE). Chances are it's only 23 bits of
mantissa in any case. Additionally, each math operation adds in a bit more
inaccuracy. By the time you've done a few rotations and translates you've
done several math operations. After all those you have to finally pass the
vector through the 4x4 to generate a screen space vector. After all that
math you probably only have 19 bits of precision, maybe 20 if you're really
being careful. That means somewhere between 2^19 (1 part in 524288) and 2^20
(1 part in 1048578) precision in the z buffer.

This is clearly not enough for your model (even if you're only modeling on
one tenth yards, smaller levels would be harder still). Something you can
try is to clean up your transformations (as an experiment). Do all the matrix
calculations in the CPU using double precision. Then just do a loadmatrix at
the end to set up the final viewing matrix. This would mean you can't use
any of those nice ortho, lookat, polarview, translate, scale, rotate, multmat,
or similar calls. Lookup what they do in the appendix to the reference manual
and do that matrix math in the host. All this work will probably buy you
2 bits of precision, giving you about 2^21 (1 part in 2097152). That would be
sufficient. It won't be as fast that way, and you won't be able to put
display manipulations in your display list (if you're using one). But it
should work.

Note that my imprecision calculations are not very precise themselves. And
it is really affected by just how many display manipulations you do. You're
mileage may very by quite a bit, and you could be as low as only 17 or 18
bits of precision by the time you get to the screen (in a really bad case).
All of this is mathematical conjecture on my part, having not worked with
a 24 bit Z buffer before. I would like to hear back if you can verify my
thoughts on this, however.

Rusty Sanders, Megatek Corp. --> rgs@megatek or...
         ...ucsd!
..hplabs!hp-sdd!megatek!jay
  ...ames!scubed!