Jude Anthony (jude++at++p3.enzian.com)
Wed, 15 Jan 1997 11:08:02 EST
In general, this is a question concerning draw speed, fill rate, and depth
complexity.
I've been asked to repost this question, including whether or not I'm using
a pfESky, and how the screen is cleared. When this thing actually runs,
it's a Vega app; I'm not certain how they use pfESky. I've got a sky color,
and my envrionment is enabled; I believe it's PFES_FAST. Lynx doesn't
mention an option for screen clearing; the closest I've seen is "Buffer
Clearing" which is set with the Z-Buffer and Frame Buffer buttons checked,
but not the Stencil or MS Buffer buttons. I've sent this to the Vega group
as well, to get answers for these questions (I hope).
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?
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.
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?
Any help would be greatly appreciated.
Thanks,
Jude Anthony
jude++at++p3.enzian.com
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
=======================================================================
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:20 PDT