## [Algorithms] indexed face list efficiency

 [Algorithms] indexed face list efficiency From: De Boer - 2004-01-08 06:47:45 ```Say you either were going to represent an object as a list of verticies or a vertexlist & facelist. If no verticies are gained by using a facelist is it less efficient? That is, if the facelist looks like {1, 2, 3, 4, 5, 6, 7, 8, 9..}. (I know results may vary on different architecture, but I am just talking in general). If so is a good metric to use if sizeof(vertexed saved) > sizeof(facelist} then use facelist, otherwise just use a vertexlist. I am including cases where verticies have multiple texture UV, so it is possible to have an object with 100% distinct verticies. For example a tetrahedron with different textures on each side. -Ryan De Boer ```

 [Algorithms] indexed face list efficiency From: De Boer - 2004-01-08 06:47:45 ```Say you either were going to represent an object as a list of verticies or a vertexlist & facelist. If no verticies are gained by using a facelist is it less efficient? That is, if the facelist looks like {1, 2, 3, 4, 5, 6, 7, 8, 9..}. (I know results may vary on different architecture, but I am just talking in general). If so is a good metric to use if sizeof(vertexed saved) > sizeof(facelist} then use facelist, otherwise just use a vertexlist. I am including cases where verticies have multiple texture UV, so it is possible to have an object with 100% distinct verticies. For example a tetrahedron with different textures on each side. -Ryan De Boer ```
 RE: [Algorithms] indexed face list efficiency From: Jon Watte - 2004-01-08 17:23:53 ```> I am including cases where verticies have multiple texture UV, so it is > possible to have an object with 100% distinct verticies. For example a > tetrahedron with different textures on each side. I can see it now: Wild Tetrahedron Madness! Now with Fully Unique Vertices! :-) Anyway, yes, it's more efficient to use non-indexed primitives when you have no sharing, as you send more data. As for exactly where the cross-over point is, where saving transform outweighs the cost of indices, varies wildly. Choosing based on overall size seems a mechanism as good as any, if you're not willing to profile your target hardware (or you need "ONE" solution for "MANY" targets). Cheers, / h+ ```
 RE: [Algorithms] indexed face list efficiency From: Tom Forsyth - 2004-01-08 23:39:05 ```IMHO, the extra cost for using indices where they are not needed is trivial - it's also a really rare occasion. But the extra complication in the rendering pipeline to handle both indexed and non-indexed is a hassle. I decided to just always use indexed primitives. Makes life so much simpler. TomF. > -----Original Message----- > From: gdalgorithms-list-admin@... > [mailto:gdalgorithms-list-admin@...] On > Behalf Of Jon Watte > Sent: 08 January 2004 17:22 > To: gdalgorithms-list@... > Subject: RE: [Algorithms] indexed face list efficiency > > > > > I am including cases where verticies have multiple texture > UV, so it is > > possible to have an object with 100% distinct verticies. > For example a > > tetrahedron with different textures on each side. > > I can see it now: Wild Tetrahedron Madness! Now with Fully > Unique Vertices! > :-) > > Anyway, yes, it's more efficient to use non-indexed > primitives when you have > no sharing, as you send more data. As for exactly where the > cross-over point > is, where saving transform outweighs the cost of indices, > varies wildly. > Choosing based on overall size seems a mechanism as good as > any, if you're > not willing to profile your target hardware (or you need > "ONE" solution for > "MANY" targets). > > Cheers, > > / h+ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ```
 Re: [Algorithms] indexed face list efficiency From: Tom van Dijck - 2004-01-09 08:49:53 ```Until you start coding on PS2 though... the damn machine doesn't even know what indices are... ----- Original Message ----- From: "Tom Forsyth" To: Sent: Friday, January 09, 2004 12:39 AM Subject: RE: [Algorithms] indexed face list efficiency > IMHO, the extra cost for using indices where they are not needed is trivial > - it's also a really rare occasion. But the extra complication in the > rendering pipeline to handle both indexed and non-indexed is a hassle. I > decided to just always use indexed primitives. Makes life so much simpler. > > TomF. > > > > -----Original Message----- > > From: gdalgorithms-list-admin@... > > [mailto:gdalgorithms-list-admin@...] On > > Behalf Of Jon Watte > > Sent: 08 January 2004 17:22 > > To: gdalgorithms-list@... > > Subject: RE: [Algorithms] indexed face list efficiency > > > > > > > > > I am including cases where verticies have multiple texture > > UV, so it is > > > possible to have an object with 100% distinct verticies. > > For example a > > > tetrahedron with different textures on each side. > > > > I can see it now: Wild Tetrahedron Madness! Now with Fully > > Unique Vertices! > > :-) > > > > Anyway, yes, it's more efficient to use non-indexed > > primitives when you have > > no sharing, as you send more data. As for exactly where the > > cross-over point > > is, where saving transform outweighs the cost of indices, > > varies wildly. > > Choosing based on overall size seems a mechanism as good as > > any, if you're > > not willing to profile your target hardware (or you need > > "ONE" solution for > > "MANY" targets). > > > > Cheers, > > > > / h+ > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDAlgorithms-list@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```
 RE: [Algorithms] indexed face list efficiency From: Tom Forsyth - 2004-01-09 09:04:50 ```It's always the annoying case :-) But we used indices on that as well = for most of the pipeline. For static models it's an intermediate format = before the meshes (in preprocess) get stripified and turned into non-indexed = data, then into a raw DMA list. For dynamic objects (lightning, HUD graphics, other mesh effects) the indices are retained right til the end, then de-indexed by software. The GameCube also has some fairly funky indexing support - again, it was = all done in the mesh preprocessing and right at the end of the dynamic-tri pipeline. As far as the rest of the pipe knew, everything is always = indexed trilists. TomF. > -----Original Message----- > From: gdalgorithms-list-admin@...=20 > [mailto:gdalgorithms-list-admin@...] On=20 > Behalf Of Tom van Dijck > Sent: 09 January 2004 08:50 > To: gdalgorithms-list@... > Subject: Re: [Algorithms] indexed face list efficiency >=20 >=20 > Until you start coding on PS2 though... the damn machine=20 > doesn't even know > what indices are... >=20 >=20 > ----- Original Message -----=20 > From: "Tom Forsyth" > To: > Sent: Friday, January 09, 2004 12:39 AM > Subject: RE: [Algorithms] indexed face list efficiency >=20 >=20 > > IMHO, the extra cost for using indices where they are not needed is > trivial > > - it's also a really rare occasion. But the extra=20 > complication in the > > rendering pipeline to handle both indexed and non-indexed=20 > is a hassle. I > > decided to just always use indexed primitives. Makes life=20 > so much simpler. > > > > TomF. > > > > > > > -----Original Message----- > > > From: gdalgorithms-list-admin@... > > > [mailto:gdalgorithms-list-admin@...] On > > > Behalf Of Jon Watte > > > Sent: 08 January 2004 17:22 > > > To: gdalgorithms-list@... > > > Subject: RE: [Algorithms] indexed face list efficiency > > > > > > > > > > > > > I am including cases where verticies have multiple texture > > > UV, so it is > > > > possible to have an object with 100% distinct verticies. > > > For example a > > > > tetrahedron with different textures on each side. > > > > > > I can see it now: Wild Tetrahedron Madness! Now with Fully > > > Unique Vertices! > > > :-) > > > > > > Anyway, yes, it's more efficient to use non-indexed > > > primitives when you have > > > no sharing, as you send more data. As for exactly where the > > > cross-over point > > > is, where saving transform outweighs the cost of indices, > > > varies wildly. > > > Choosing based on overall size seems a mechanism as good as > > > any, if you're > > > not willing to profile your target hardware (or you need > > > "ONE" solution for > > > "MANY" targets). > > > > > > Cheers, > > > > > > / h+ > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Perforce Software. > > > Perforce is the Fast Software Configuration Management=20 > System offering > > > advanced branching capabilities and atomic changes on 50+=20 > platforms. > > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDAlgorithms-list@... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management=20 > System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDAlgorithms-list@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 ```
 Re: [Algorithms] indexed face list efficiency From: Rok Erjavec - 2004-01-09 09:08:46 ```> 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. > > ----- Original Message ----- > From: "Tom Forsyth" > To: > Sent: Friday, January 09, 2004 12:39 AM > Subject: RE: [Algorithms] indexed face list efficiency > > > > IMHO, the extra cost for using indices where they are not needed is > trivial > > - it's also a really rare occasion. But the extra complication in the > > rendering pipeline to handle both indexed and non-indexed is a hassle. I > > decided to just always use indexed primitives. Makes life so much simpler. > > > > TomF. > > > > > > > -----Original Message----- > > > From: gdalgorithms-list-admin@... > > > [mailto:gdalgorithms-list-admin@...] On > > > Behalf Of Jon Watte > > > Sent: 08 January 2004 17:22 > > > To: gdalgorithms-list@... > > > Subject: RE: [Algorithms] indexed face list efficiency > > > > > > > > > > > > > I am including cases where verticies have multiple texture > > > UV, so it is > > > > possible to have an object with 100% distinct verticies. > > > For example a > > > > tetrahedron with different textures on each side. > > > > > > I can see it now: Wild Tetrahedron Madness! Now with Fully > > > Unique Vertices! > > > :-) > > > > > > Anyway, yes, it's more efficient to use non-indexed > > > primitives when you have > > > no sharing, as you send more data. As for exactly where the > > > cross-over point > > > is, where saving transform outweighs the cost of indices, > > > varies wildly. > > > Choosing based on overall size seems a mechanism as good as > > > any, if you're > > > not willing to profile your target hardware (or you need > > > "ONE" solution for > > > "MANY" targets). > > > > > > Cheers, > > > > > > / h+ > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Perforce Software. > > > Perforce is the Fast Software Configuration Management System offering > > > advanced branching capabilities and atomic changes on 50+ platforms. > > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDAlgorithms-list@... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDAlgorithms-list@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```
 Re: [Algorithms] indexed face list efficiency From: Jani Kajala - 2004-01-31 22:37:48 ```> 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" To: 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. > ```
 RE: [Algorithms] indexed face list efficiency From: Jamie Fowlston - 2004-01-31 23:09:12 ```chop your model up :) jamie -----Original Message----- From: gdalgorithms-list-admin@... [mailto:gdalgorithms-list-admin@...]On Behalf Of Jani Kajala Sent: 31 January 2004 22:37 To: gdalgorithms-list@... 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" To: 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 GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```
 Re: [Algorithms] indexed face list efficiency From: Tom van Dijck - 2004-01-31 23:12:44 ```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" To: 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" > To: > 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 > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ```
 Re: [Algorithms] indexed face list efficiency From: Jonathan Greenberg - 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: 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" > To: > 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" > > To: > > 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 > > GDAlgorithms-list@... > > 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 > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```