Re: Scenes with lots of simple objects

Linas Vepstas ([email protected])
Wed, 8 Mar 1995 15:49:17 -0600


> Date: Tue, 7 Mar 1995 22:08:00 -0500 (EST)
> From: Edward Hoffmeister <[email protected]>
> Subject: Re: Scenes with lots of simple objects
>
> On Tue, 7 Mar 1995, Gavin Bell wrote:
> > On Feb 28, 9:04am, Scott Nelson wrote:
> > > I'd appreciate any feedback on the following:
> > >
> > > I have a 50x50x50 block of cubes. This takes several minutes to
> >
> > I think it makes more sense to define new kinds of shapes that know how to
> > render large numbers of simple primitives, and that know how to optimize the
> > rendering. For example, a CubeSet could store the cubes in a spacial data
> > structure, figure out where the eyepoint is relative to the cubes, draw them
> > back to front, and (if it was really smart) avoid drawing invisible cubes.

Long ago, there was talk of having VRML support a non-proceedural
iterator (a kind of "make/draw n copies of this" primitive). The idea
behind the iterator is that you would specify a (translation) matrix
to iterate on. In very garbled syntax:

Iterator {
numRepeat 50,
{
Tranlate 0 0 1,
Cube {...}
}
}

would draw 50 cubes in a row, along z axis.
Would such a thing really be useful? Would it be of broad interest?
Or is it a neat trick that no one would use?

> 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.

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

Sincerely,
Linas Vepstas

^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
<a href="http://w3.austin.ibm.com/~linas">
Linas Vepstas Graphics Architecture
IBM PPS Zip 9260 Tie Line: 678-1116
11400 Burnet Road External Phone: 1-(512)-838-1116
Austin TX 78756-9260 mail: [email protected] </a>
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^