Re: [Algorithms] indexed face list efficiency
Brought to you by:
vexxed72
From: Jonathan G. <jon...@mi...> - 2004-02-03 06:18:43
|
To respond while squeaking by without crossing the "off topic" magic line, post transform caches do not have to be terribly large to be effective, as seen by the GeForce 3, for example, with the cache being a mere 16 vertices deep. Tristrippers that bias towards vertex reuse rather than the usual "longest strip" stuff can definately help a bit here, too. In my experience, if you give your artists a budget of tristripped vertices along with a decent stripper, rather than actual polygons, you'll generally get art out of them that tristrips quite well. We make the restrictions that affect us the artists' restrictions and that seems to work out well, as they arms race to see who can build the best looking art within the limitations. It's also worth remembering that if you've got an ideal plane of vertices, each with valence of 6 and tristrip perfectly, you'll get each vertex showing up twice in your infinite strip as you wrap back down the next row, so if your vertex cache was likewise infinite in size, your ideal tri-to-vert ratio would be 0.5. Or at least, so I recall the hand-waving arguement anyway. We extensively use post-transform caching on PS2 through a few different mechanisms (dest-indexing, inter-packet reuse, etc) and find that it greatly speeds things up and massively reduces our geometry bandwidth requirements. If you've got pretty expensive per-vertex processing (which we do), post-transform caches can really save your butt. And unless your world consists mainly of 12 triangle crates, it should be easy for any compentant artist to build art that tristrips reasonably well, and generally benefits from indexing. Jon ----- Original Message ----- From: "Tom van Dijck" <to...@mu...> To: <gda...@li...> Sent: Saturday, January 31, 2004 5:12 PM Subject: Re: [Algorithms] indexed face list efficiency > Uhm.... you just don't use it.... > The pre-processing pipeline should strip most of the geometry to reduce > vertex count. > > Otherwise, in case you really want to use it, you still have to do some > pre-processing, to make sure each batch does not use indices outside the > batch, and since batches are rather small, I think it is of no use to do > so... > > But my guess is, that this is kinda offtopic by now, since we are going to > discuss PS2 specifics, I guess we could better continue on the > ps2-newgroups, before Brian is kicking our butts.. > > > ----- Original Message ----- > From: "Jani Kajala" <ka...@ga...> > To: <gda...@li...> > Sent: Saturday, January 31, 2004 11:37 PM > Subject: Re: [Algorithms] indexed face list efficiency > > > > > VUs can use indices efficiently enough, as well as posttransform > caching. > > > The performance implications aren't exactly the same as on other > hardware > > > > How do you handle the VU1 memory limit when using indexing? > > > > > > Regards, > > Jani > > > > ----- Original Message ----- > > From: "Rok Erjavec" <ro...@si...> > > To: <gda...@li...> > > Sent: Friday, January 09, 2004 11:08 AM > > Subject: Re: [Algorithms] indexed face list efficiency > > > > > > > > Until you start coding on PS2 though... the damn machine doesn't even > > know > > > > what indices are... > > > VUs can use indices efficiently enough, as well as posttransform > caching. > > > The performance implications aren't exactly the same as on other > hardware > > > (ie. prelit or trivial shader geometry may actually run slower with > > > indexing) but it's still usefull. > > > > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |