I suspect that it's a neat trick that lots of people would find
great uses for. If you could nest iterators, it'd be really easy
to describe complex fractal trees and such in jsut a few lines.
> > if a Z-buffer is implemented AND the cubes are sorted FRONT to back, then
> > the front surface of the closest cube will be drawn and all of the cubes
> > that are "behind" those pixels will test as the z-values are further, so
> > they will fail the test of "should the pixel be drawn", which will avoid
> > drawing (which is an time consuming operation on most hardware.), and
> > will give the most significant speed up to those people with the slowest
>
> BZZT. This is wrong. If you're touching z, you've already blown
> performance. Specifically, you MUST: transform, light & clip,
> compute triangle edge slopes, walk triangle edges, walk spans,
> interpolate r, g, b, texture s, t, depth z. That's the majority
> of CPU time. Whether or not you actually plop a color into the frame
> buffer at this point is almost completely irrelevent. And you have to
> do all of the previous before you do the z-test.
Well not exactly, because if you co the z-test first, you then
don't have to compute the shade of pixels found to be obscured.
Your general point is well taken however.
> However, front-to-back is interesting if you DON'T z-buffer, and DO
> maintain a "visibility list". You draw front to back. You maintain
> a list of polygonal 2D clipping regions, at first empty. Every new
> thing you draw, you compute intersection against the clip list.
> If its visible, you draw it. If not, you discard the polygon (DON'T
> do lighting, don't do transform, don't rasterize, nothing). Evry thing
> that you drew, you add it to the clip list. Eventually, the clip list
> grows to fill the screen, and you are done -- nothing else can possibly
> be visible. In this way, you touch each & every pixel once and only
> once. Can be a good cpu saver on small/medium models (less than 50K
> polygons).
>
> --linas
Note that you can also perform visibility tests against your "visibility
list" with the bounding volumes of complex objects before attempting to
render those objects, and potentially benefit from trivial rejection
possibilities.
--- Daniel Green | Senior Programmer email: danielg@autodesk.com | Cyberspace Developer Kit tel: (415) 507-5745 | fax: (415) 507-5150 | Zen is not what you think.