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 ; 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: X-Comment: OpenGL Game Developers Mailing List X-Sender: Steve Baker 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 Sender: root@fatcity.com To: Multiple recipients of list OPENGL-GAMEDEV-L 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" "" "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 ; 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 ; Sun, 16 Aug 1998 00:55:12 -0500 (CDT) X-Sender: steve@lechter.bgm.link.com Reply-To: Steve Baker In-Reply-To: <199808152138.QAA27557@kenai.me.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker To: "Curtis L. Olson" 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 ; 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 ; Tue, 18 Aug 1998 08:56:48 -0500 (CDT) X-Sender: steve@samantha.bgm.link.com Reply-To: Steve Baker In-Reply-To: <199808172109.QAA25296@kenai.me.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker To: "Curtis L. Olson" 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