Re: Scene Density Requirements

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Wed, 15 Jan 1997 17:17:27 +0000

On Jan 15, 8:59am, Jude Anthony wrote:
> Subject: Re: Scene Density Requirements
> I'm getting some conflicting answers on this problem, so I'm asking for more
> opinions. (Majority rules? On a technical question? Hmmm...)
>
> In general, this is a question concerning draw speed, fill rate, and depth
> complexity.
>
> The machine is an RE2 with 2RM4s. The application runs in a 1024x768 screen.
> From all calculations I've seen so far, the test scene I'm trying to render
> should go at 30Hz; yet it has a draw time of 33.1ms, and runs no faster than
> 20Hz. (Statistics from perfly or vega application.)
>
> The scene consists of strips of tris, overlapped so that none are completely
> obscured, sometimes up to six deep. The scene was created with MultiGen,
> and I arranged the objects so that they are sorted back-to-front, since they
> all have the same Z. The strips are meshed for their entire length. In
> short, it looks something like this:
>
> +----------------+
> | +----------------+
> | | +----------------+
> + | | |
> + | |
> +----------------+
>
> The strips are placed at a distance from the observer such that one database
> unit is one pixel. The strips constitute the following numbers and sizes of
> triangles:
> 150 tris, 101x101
> 1350 tris, 51x51
> 1500 tris, 10x10
>
> None of the above is negotiable; it's all set out in the test document.
>
> Our average depth complexity for the scene is somewhere between 3.31 and
> 3.33. (Perfly/Vega statistics again.)
>
> 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, which is below the
> rated fill rate, so shouldn't be causing a problem.
>
> Question 1: Am I missing some important calculation here?
>
> From this calculation, this app should run 30Hz without even breathing
> hard. I must be missing something. Maybe I need to add the screen clearing
> and Z-buffer clearing pixels in here?

You should certainly factor in the time taken to clear the screen.
I've seen 1ms measured for 1280x1024 on iR.

>
> Question 2: Is there any way to increase the speed of this app to 30Hz?
>
> I found that by eliminating multisampling, turning off the Z-buffer
> altogether, or not clearing the Z-buffer, I can increase the iteration rate.
> Unfortunately, I'm not allowed to change those things, since the test app
> conditions are supposed to match the simulation conditions.
> I also find that moving the observer back just a little speeds things up.

Have you display listed the geometry which you draw?
Have you installed patch 1355?
Draw your larger polygons first if allowed and mix large and
small if you are able.
If texturing then use simpler internal formats like RGB 555.
Try flat shading if you can get away with it.
Make sure modes like blending are disabled.

>
> Question 3: In what way does depth complexity directly affect render speed?
>
> If every pixel of every polygon is compared against the Z-buffer before it
> is drawn, then it should make no difference to speed if I overlap several
> polygon strips or spread them out over the screen (as long as the number of
> pixels remains constant). In each case, every pixel gets compared against
> the Z-buffer once before it is drawn, resulting in the same number of
> comparisons ever time. Is there some other way that depth complexity affects
> render speed, or am I misiniformed with respect to the Z-buffer algorythm?

This is correct, z buffering isn't the only issue but on our systems your
reasoning is fine for a lot of cases. It may help to use simpler texture
filters, and does help to use smaller texture formats, blending & shading.
Small polygons will will not give good fill performance.

Cheers,
Angus
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:21 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.