252 lines
12 KiB
Text
252 lines
12 KiB
Text
|
From fatcity!root@news.cts.com Sun Apr 12 22:32:55 1998
|
||
|
|
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||
|
|
["2122" "Sun" "12" "April" "1998" "19:50:31" "-0800" "Steve Baker" "sbaker@link.com" nil "47" "Re: Strips vs Fans ..." "^From:" nil nil "4" nil nil nil nil nil]
|
||
|
|
nil)
|
||
|
|
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||
|
|
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id WAA20847
|
||
|
|
for <curt@me.umn.edu>; Sun, 12 Apr 1998 22:32:52 -0500 (CDT)
|
||
|
|
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id UAA22193; Sun, 12 Apr 1998 20:31:45 -0700 (PDT)
|
||
|
|
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||
|
|
by king.cts.com (8.8.7/8.8.7) with SMTP id UAA00319;
|
||
|
|
Sun, 12 Apr 1998 20:31:43 -0700 (PDT)
|
||
|
|
Received: from fatcity by donews.cts.com with uucp
|
||
|
|
(Smail3.1.29.1 #5) id m0yOZX9-00000Wa; Sun, 12 Apr 98 20:03 PDT
|
||
|
|
Received: by fatcity.com (10-Feb-1998/v1.0f-b64/bab) via UUCP id 0001C21E; Sun, 12 Apr 1998 19:50:31 -0800
|
||
|
|
Message-ID: <F001.0001C21E.19980412195031@fatcity.com>
|
||
|
|
X-Comment: OpenGL Game Developers Mailing List
|
||
|
|
X-Sender: Steve Baker <sbaker@link.com>
|
||
|
|
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||
|
|
Errors-To: ML-ERRORS@fatcity.com
|
||
|
|
Organization: Fat City Network Services, San Diego, California
|
||
|
|
X-ListServer: v1.0f, build 64; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||
|
|
Precedence: bulk
|
||
|
|
Mime-Version: 1.0
|
||
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
|
|
Content-Transfer-Encoding: 7bit
|
||
|
|
From: Steve Baker <sbaker@link.com>
|
||
|
|
Sender: root@fatcity.com
|
||
|
|
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||
|
|
Subject: Re: Strips vs Fans ...
|
||
|
|
Date: Sun, 12 Apr 1998 19:50:31 -0800
|
||
|
|
|
||
|
|
On Sat, 11 Apr 1998, Edward M Povazan wrote:
|
||
|
|
|
||
|
|
> I've been following threads here about auto strip generation, and am
|
||
|
|
> starting to wonder, why not do fans. I did a small paper test ... a regular
|
||
|
|
> triangle grid.
|
||
|
|
> case : transforms per case : percentage less than seperate triangles
|
||
|
|
> seperate triangles : 144 : 0
|
||
|
|
> fans : 77 : 53%
|
||
|
|
> strips : 56 : 39%
|
||
|
|
>
|
||
|
|
> OK so strips win here. But on a general mesh (especially one optimized for
|
||
|
|
> rt3d) the strip runs are not as long. In fact, there are cases when fans
|
||
|
|
> produce less transforms than strips (this is the case in my landscape
|
||
|
|
> engine).
|
||
|
|
|
||
|
|
The other thing that leads me to get more excited about fans than
|
||
|
|
strips is that they tend to be more compact - spatially that is -
|
||
|
|
becuase they are all sharing that one vertex.
|
||
|
|
|
||
|
|
This is useful for pre-OpenGL culling since it greatly increases the
|
||
|
|
probablility that a fan will cleanly come out wither entirely inside
|
||
|
|
or entirely outside the view frustum. If (like me) you are using a
|
||
|
|
bounding sphere test to accept or reject entire strip/fan primitives
|
||
|
|
then it's easy to visualise how fans fit better into a neat sphere
|
||
|
|
than those long wandering strips.
|
||
|
|
|
||
|
|
I'm still struggling to convert an old terrain system which was based
|
||
|
|
around IRISGL primitives (alas, no fans) - and the wins for fans
|
||
|
|
seem pretty significant.
|
||
|
|
|
||
|
|
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||
|
|
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||
|
|
Work: SBaker@link.com http://www.hti.com
|
||
|
|
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||
|
|
|
||
|
|
--
|
||
|
|
Author: Steve Baker
|
||
|
|
INET: sbaker@link.com
|
||
|
|
|
||
|
|
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||
|
|
San Diego, California -- Public Internet access / Mailing Lists
|
||
|
|
--------------------------------------------------------------------
|
||
|
|
To REMOVE yourself from this mailing list, send an E-Mail message
|
||
|
|
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||
|
|
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||
|
|
(or the name of mailing list you want to be removed from). You may
|
||
|
|
also send the HELP command for other information (like subscribing).
|
||
|
|
|
||
|
|
From sbaker@link.com Sun Aug 16 00:55:44 1998
|
||
|
|
X-VM-v5-Data: ([nil nil nil t t nil nil nil nil]
|
||
|
|
["1920" "Sun" "16" "August" "1998" "00:52:12" "-0500" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980816003848.24029A-100000@lechter.bgm.link.com>" "41" "Re: strips vs. fans" "^From:" nil nil "8" nil nil nil nil nil]
|
||
|
|
nil)
|
||
|
|
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||
|
|
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id AAA14434
|
||
|
|
for <curt@me.umn.edu>; Sun, 16 Aug 1998 00:55:43 -0500 (CDT)
|
||
|
|
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.63.22])
|
||
|
|
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
|
||
|
|
id AAA05219 for <curt@me.umn.edu>; Sun, 16 Aug 1998 00:55:12 -0500 (CDT)
|
||
|
|
X-Sender: steve@lechter.bgm.link.com
|
||
|
|
Reply-To: Steve Baker <sbaker@link.com>
|
||
|
|
In-Reply-To: <199808152138.QAA27557@kenai.me.umn.edu>
|
||
|
|
Message-ID: <Pine.SGI.3.96.980816003848.24029A-100000@lechter.bgm.link.com>
|
||
|
|
MIME-Version: 1.0
|
||
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
|
|
From: Steve Baker <sbaker@link.com>
|
||
|
|
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||
|
|
Subject: Re: strips vs. fans
|
||
|
|
Date: Sun, 16 Aug 1998 00:52:12 -0500 (CDT)
|
||
|
|
|
||
|
|
On Sat, 15 Aug 1998, Curtis L. Olson wrote:
|
||
|
|
|
||
|
|
> At one point did you suggest that I might have comperable performance
|
||
|
|
> with fans vs. tri-strips?
|
||
|
|
|
||
|
|
Yes. We went down the path of changing our terrain tools to use
|
||
|
|
fans - the performance was essentially unchanged.
|
||
|
|
|
||
|
|
In the end, it depends on the average number of vertices per triangle.
|
||
|
|
For very long tristrips, or for very large fans, the average tends
|
||
|
|
towards 1 vertex per triangle. In this respect, there is no performance
|
||
|
|
difference between strips and fans. However, there are two reasons
|
||
|
|
to prefer strips and one reason to prefer fans:
|
||
|
|
|
||
|
|
1) Strips are allegedly implemented in hardware for Voodoo-2, and
|
||
|
|
when Mesa supports that, there could be some savings to be had
|
||
|
|
in triangle setup times. I have not heard that the same is true
|
||
|
|
for tri-fans - but it's possible.
|
||
|
|
|
||
|
|
2) Strips can potentially contain more triangles than fans because
|
||
|
|
they are not limited to having all their triangles share that
|
||
|
|
one start vertex. If you can actually make your strips longer
|
||
|
|
for practical data then strips should win. However, it's quite
|
||
|
|
hard to get an average strip strip length more than four or
|
||
|
|
five when your terrain has features like lakes, rivers, forest,
|
||
|
|
etc embedded in it.
|
||
|
|
|
||
|
|
3) Fans have one theoretical advantage - since all the triangles
|
||
|
|
share that first vertex, fans tend to be spatially compact.
|
||
|
|
This means that crude bounding sphere culling will be more
|
||
|
|
effective at reducing the number of triangles sent to OpenGL
|
||
|
|
than it might be with tri-strips.
|
||
|
|
|
||
|
|
My practical experience so far seems to suggest that these
|
||
|
|
various effects are either so tiny as to make no difference - or
|
||
|
|
somehow cancel out. However, it's work-in-progress.
|
||
|
|
|
||
|
|
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||
|
|
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||
|
|
Work: SBaker@link.com http://www.hti.com
|
||
|
|
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||
|
|
|
||
|
|
From sbaker@link.com Tue Aug 18 08:57:29 1998
|
||
|
|
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||
|
|
["4108" "Tue" "18" "August" "1998" "08:56:05" "-0500" "Steve Baker" "sbaker@link.com" nil "87" "Re: strips vs. fans" "^From:" nil nil "8" nil nil nil nil nil]
|
||
|
|
nil)
|
||
|
|
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||
|
|
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id IAA10259
|
||
|
|
for <curt@me.umn.edu>; Tue, 18 Aug 1998 08:57:27 -0500 (CDT)
|
||
|
|
Received: from samantha.bgm.link.com (samantha.bgm.link.com [130.210.65.19])
|
||
|
|
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
|
||
|
|
id IAA11753 for <curt@me.umn.edu>; Tue, 18 Aug 1998 08:56:48 -0500 (CDT)
|
||
|
|
X-Sender: steve@samantha.bgm.link.com
|
||
|
|
Reply-To: Steve Baker <sbaker@link.com>
|
||
|
|
In-Reply-To: <199808172109.QAA25296@kenai.me.umn.edu>
|
||
|
|
Message-ID: <Pine.SGI.3.96.980818074747.24918A-100000@samantha.bgm.link.com>
|
||
|
|
MIME-Version: 1.0
|
||
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
|
|
From: Steve Baker <sbaker@link.com>
|
||
|
|
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||
|
|
Subject: Re: strips vs. fans
|
||
|
|
Date: Tue, 18 Aug 1998 08:56:05 -0500 (CDT)
|
||
|
|
|
||
|
|
On Mon, 17 Aug 1998, Curtis L. Olson wrote:
|
||
|
|
|
||
|
|
> So do just use a "greedy" algorithm to build fans, or do you do
|
||
|
|
> something more sophisticated?
|
||
|
|
|
||
|
|
Well, we have to consider the larger issues.
|
||
|
|
|
||
|
|
* From the point of view of OpenGL, the more triangles in the strip/fan
|
||
|
|
the better.
|
||
|
|
* From the point of view of FOV culling, the more compact the strip/fan
|
||
|
|
the better.
|
||
|
|
* From the point of view of intersection testing, the shorter the strip/fan
|
||
|
|
the better.
|
||
|
|
|
||
|
|
We use a variety of stripping algorithms depending on the cicumstance.
|
||
|
|
Sometimes we just do the 'greedy' algorithm, sometimes we impose a limit
|
||
|
|
on the maximum strip length which tends to cut down on the number of
|
||
|
|
single triangles (which are especially costly on SGI hardware for some
|
||
|
|
reason). Sometimes we use an algorithm that has an estimate of the
|
||
|
|
relative costs of transforming strips of length 1, 2, 3, 4, ... which
|
||
|
|
tries many different ways to strip/fan until it finds one with a cost
|
||
|
|
per-triangle that is less than some user-specified limit - and the
|
||
|
|
ultimate algorithm simply does a totally exhaustive search for the cheapest
|
||
|
|
overall set of strips.
|
||
|
|
|
||
|
|
The last few algorithms can take days to run on even relatively simple
|
||
|
|
objects - and we use those only for the simplest of objects when that object
|
||
|
|
is re-used a gazillion times in the database. For example, we did a
|
||
|
|
model of Yellowstone national park where the customer needed the highest
|
||
|
|
possible density of single, individual trees. We built a set of tree
|
||
|
|
cluster models and ran the tri-stripper at maximum optimisation on them
|
||
|
|
all to get down the cost of transforming all those thousands of trees to
|
||
|
|
the absolute minimum.
|
||
|
|
|
||
|
|
However, when we have the whole of North America to tstrip, we can't
|
||
|
|
afford the CPU hours to do anything much more than the very basic
|
||
|
|
limited-length-greedy algorithm.
|
||
|
|
|
||
|
|
Limiting the maximum strip length helps the FOV culling so much that
|
||
|
|
we pretty much always limit the length to a dozen of so triangles.
|
||
|
|
That's principally due to SGI hardware which gains performance as the
|
||
|
|
strip length increases - up to about 10 triangles - beyond which it
|
||
|
|
doesn't really help any.
|
||
|
|
|
||
|
|
It's MUCH better (on SGI ONYX hardware) to generate two strips of 5
|
||
|
|
triangles each than it is to generate one strip of 9 and one single
|
||
|
|
triangle.
|
||
|
|
|
||
|
|
For us, there are yet other considerations. We don't currently drive
|
||
|
|
OpenGL directly - we use the Performer scene graph API as a layer on
|
||
|
|
top. Performer can optimise the case where all the triangles in the
|
||
|
|
strip share the same surface normal and/or colour. In that case, it
|
||
|
|
generates just one glNormal and glColor command for each strip. These
|
||
|
|
are called 'Flat-Tri-strips'. For man-made objects, we can often win
|
||
|
|
by having shorter strips that are flat rather than longer strips that
|
||
|
|
are non-flat because the cost of transforming the normals is not
|
||
|
|
negligable.
|
||
|
|
|
||
|
|
Some of the SGI machines also optimise for the case when there is only
|
||
|
|
a single, infinite light source by only doing illumination per-normal
|
||
|
|
rather than per-vertex - this also makes flat strips worth having.
|
||
|
|
|
||
|
|
Some of these optimisations are actually pessimisations on some machines,
|
||
|
|
so you have to optimise the database for the hardware.
|
||
|
|
|
||
|
|
As you can see, this is another incredibly complicated issue if you
|
||
|
|
want to get absolutely *ALL* the performance you can.
|
||
|
|
|
||
|
|
It's unreasonable to expect FGFS to do this with the limited effort
|
||
|
|
available. We have two or three full-time staff thinking about
|
||
|
|
database tools - and we have been working with OpenGL for five
|
||
|
|
years now.
|
||
|
|
|
||
|
|
> > 1) Strips are allegedly implemented in hardware for Voodoo-2, and
|
||
|
|
> > when Mesa supports that, there could be some savings to be had in
|
||
|
|
> > triangle setup times. I have not heard that the same is true for
|
||
|
|
> > tri-fans - but it's possible.
|
||
|
|
>
|
||
|
|
> I would think that if they did strips, they could easily do fans ...
|
||
|
|
|
||
|
|
I just asked the question on the 3Dfx newsgroup - we'll get a definitive
|
||
|
|
answer there.
|
||
|
|
|
||
|
|
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||
|
|
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||
|
|
Work: SBaker@link.com http://www.hti.com
|
||
|
|
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||
|
|
|