Re: Scene Density Requirements
Rémi Arnaud (remi++at++remi.asd.sgi.com)
Fri, 10 Jan 1997 12:51:53 -0800 (PST)
Jude Anthony wrote:
>
> > Jude Anthony wrote:
> > >
> > > OK, I'm back again. This question goes to both Performer and Vega groups.
> > >
> > > Our TTPRR requires that we render, at 30Hz, a scene with:
> > > 150 tris, 101x101
> > > 1350 tris, 51x51
> > > 1500 tris, 10x10
> > >
> > > We're not getting 30Hz at 1024x768.
> > >
> > > When we bought the Onyx/RE2, we had 1 RM4. The salesman looked at our
> > > screen size, projected depth complexity, and iteration rate, and told us
> > > we'd need to upgrade to 2 RM4s to get the job done.
> > >
> > > Our average depth complexity for the scene is somewhere between 3.31 and
> > > 3.33. My manager tells me the threshold was around 3.1.
> > >
> > > The rated pixel fill rate for 2 RM4s is 110Mpix/sec. Our scene contains:
> > > 150 x 101 x 101 / 2 = 765,075
> > > + 1350 x 51 x 51 / 2 = 1,755,675
> > > + 1500 x 10 x 10 / 2 = 75,000
> > > --------------------------------
> > > 2,595,750 pixels.
> > > At 30Hz, that makes 2,595,750 * 30 = 77,872,500pix/sec.
> > >
> > > 77,872,500pix/sec is below the rated pixel fill rate. It's even below the
> > > 90Mpix/sec conservative fill rate on the salesman's sheets.
> > >
> > > The problem is to increase the iteration rate to 30Hz. My manager has me
> > > shifting polygons around, trying to decrease the depth complexity. I'm
> > > making the attempt, but my experience with renderers tells me this is not
> > > going to work; the depth complexity is calculated, and is only useful for
> > > culling and pixel fill estimates. Is this the case, or am I working with
> > > a different beast?
> > >
> > > The current thinking is that there is some Performer bottleneck. Any
> > > ideas on how to bring the iteration rate up?
> > >
> > > The scene is composed of strips of polygons. Perfly shows me that all the
> > > strips are meshed, all at more than 14 tris/strip. The strips are offset
> > > in such a way that no more than 6 are ever layered. Each strip is a
> > > different color than the one above it, so as to facilitate counting (6
> > > colors total). There are no textures. The whole thing eventually runs as
> > > a vega app.
> > >
> >
> > I'm confused. Is your polygon count is the part of the database that is
> > displayed ? a 10x10 triangle in the database can be full screen after
> > projection, if you have 6 layers, that makes a depth complexity of 6,
> > requiring 141 Mpixels/s.
>
> The polygons and the observer are placed in such a way that one database unit
> (meter) is one on-screen pixel. (The TTPRR specifies pixels.) They are
> layered more-or-less like this:
> +-----------+
> | +-----------+
> | | +------------+
> + | | |
> + | |
> +------------+
> So that the strips are never more than 6 deep.
If I understand correctly, you have a test, where all the polygons are on the
screen (no clipping, no culling). All polygons are facing the observer, so are
perfectly flat in screen space.
Using a perspective matrix, you place the polygons at some distance from the
observer so you exactly know the surface of all triangles in screen space.
If my understanding is OK, then what you could do, is to move back the observer
until the frame rate is 30Hz.
The displayed database will display the same number of polygons, but
the fill rate will be less, as you will use less than the screen.
If you never reach 30Hz with the same polygon count (performer stats)
then the problem is not fill rate.
If you reach 30HZ, then get the depth complexity factor at this point,
and calculate the Mpix/s your system gives you.
-- Remi
=======================================================================
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:54:19 PDT