>Sorry I didn't respond sooner; I've been on extended vacation.
>My apologies for not being about to help.
np,
tom, jason (ati) and a few others where pretty knowledgeable on this topic
("occlusion-detection circuitry") so we got some good feedback on the
technique and what the xbox could be doing.
peace.
akbar A.
"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.
-----Original Message-----
From: Mike Abrash [mailto:mi...@mi...]
Sent: Wednesday, August 23, 2000 4:17 PM
To: 'Akbar A.'; Algorithms List
Subject: RE: [algorithms] antiportals?occlusion
Sorry I didn't respond sooner; I've been on extended vacation.
I wish I could explain all the details, but I put as much into the article
as I could without running afoul of NDAs, and I had to push to get in as
much as I did. My apologies for not being about to help.
Eric, excellent book!
Regards,
Michael
-----Original Message-----
From: Akbar A. [mailto:sye...@ea...]
Sent: Tuesday, July 04, 2000 6:54 AM
To: Algorithms List
Cc: Mike Abrash
Subject: RE: [algorithms] antiportals?occlusion
>though I do wish there was a little more explanation there
well that's what we are waiting for :-) hopefully we will get some
feedback from abrash.
eric' maybe if you release a new edition of you book , the "design and
implemention of the hardware" on the xbox could make a good chapter :-)
hehe.
peace.
akbar A.
"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.
-----Original Message-----
From: Eric Haines [mailto:er...@ac...]
Sent: Tuesday, July 04, 2000 5:45 AM
To: Algorithms List
Subject: Re: [algorithms] antiportals?occlusion
> "There's also occlusion-detection circuitry that can increase fill rate by
> up to 4X; the effect varies depending on whether pixels are occluded when
> they're drawn, but tends to be greatest exactly when it's needed most"
Nice little article, though I do wish there was a little more explanation
there.
On a related note, ATI's announced Radeon has HyperZ, which ATI doesn't go
into
detail about, but from talking with Jason L. Mitchell this is essentially a
nice
trick to save on fill rate, as follows (from our page
http://www.realtimerendering.com/#speed): When rendering a polygon, the
screen
is split into tiles (e.g. 8x8 pixels or similar; ATI doesn't say the exact
size). Before any pixel Z-buffer testing is performed for a polygon and a
tile,
the highest z-value in the tile is compared to the lowest z-value for the
polygon. If the polygon is farther back than the tile's highest value, then
it
cannot be visible and so individual pixel testing can be avoided. ATI claims
a
20% fill-rate performance gain. How ATI tracks the tile's highest z-value
efficiently (i.e. when a new polygon does get rendered, how do you
efficiently
find the new highest z for the entire tile?) is a trade secret at this
point.
Eric
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list, send an e-mail to
"do...@3d..." with the following body:
leave algorithms
Web Archives of this list can be found at:
http://216.101.212.117/cgi/doweb.exe?list=algorithms
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
