Thread: Re: [Algorithms] Triangle strips still useful?
Brought to you by:
vexxed72
From: Alen L. <ale...@cr...> - 2006-09-04 07:08:46
|
Hi Eric, I was going to mention Universal Rendering Sequences, but I see Tom's FAQ already covers it a bit. Just to mention that, while I don't know of anyone who implemented this (besides the original authors), there was a discussion on some implementation possibilities in an old thread here. The tail of the thread is something like this: http://sourceforge.net/mailarchive/message.php?msg_id=7193196 Might find some info there. Alen Eric wrote: > Is stripification still useful when rendering meshes? That is, is it > worth turning a mesh into a set of triangle strips? |
From: Tom F. <tom...@ee...> - 2006-09-04 18:07:42
|
I assume Jon was talking about non-indexed strips. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Robert Dibley > Sent: 04 September 2006 07:25 > To: 'Game Development Algorithms' > Subject: Re: [Algorithms] Triangle strips still useful? > > > Jon Watte said: > > > If the vertices and indices live in VRAM, then strips are > > always a loss. > > On a large, regular mesh, the best you can do with a strip is 1 > > transformed vertex to generate one triangle (and you actually > > do worse, because of stitching). > > I don't understand this ... > Why should being in strip order prevent the post-transform cache from > working ? > > Surely for a real world scenario, with a non-regular mesh, > and thus with > lots of short strips, it is still quite easy to optimize for > locality and > hence make good use of the post-transform cache while using > indexed strips ? |
From: Tom F. <tom...@ee...> - 2006-09-05 05:34:36
|
> PS Of course, if a hardware manufacturer ever > implemented something like this in hardware and used > the edge stack to keep a cache primed... well that > would be crazy talk. Most high-end rasterisers these days are plane-equation based rather than trapezoid-walk things (much easier to parallelise), so the edge equations aren't as expensive as they used to be. Interesting idea though. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Conor Stokes > Sent: 04 September 2006 20:44 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? > > > I've found I get pretty good performance out of meshes > reproduced from compression. > > About 3 years ago I wrote a mesh compression library > that used something similar to the cut-border machine > (http://www.gris.uni-tuebingen.de/~sgumhold/MeshComp/index.html), > but with a lot of modifications (I use a different > set of operators, mainly by making connect forwards > and connect back more powerful). > > Generally early on in the triangle stream it produces > something like interconnected fans that loop back on > themselves... then later on it tends to produce > closing or spiralling rings. > > Of course, one day I intend to get back to this > project and get it the stage of something I can > release and stand behind... but that's one of those > pipe dreams ;-). > > Cheers, > Conor > > PS Of course, if a hardware manufacturer ever > implemented something like this in hardware and used > the edge stack to keep a cache primed... well that > would be crazy talk. > > --- Martin Slater <ms...@ne...> wrote: > > > > > > >http://sourceforge.net/mailarchive/message.php?msg_id=7193196 > > > > > >Might find some info there. > > > > > >Alen > > > > > > > I never got round to posting the results but from > > memory it gave results > > something like 20-30% worse than using > > DXDXOptimiseMesh which is cache > > size aware, i'll see if I can dig up the original > > results in the office > > tommorow. The biggest downside was that its very > > slow to run which can > > impact on your toolchain turnaround time quite a > > lot. > > > > Martin > > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.1.405 / Virus Database: 268.11.7/436 - > > Release Date: 1/09/2006 > > > > > > > -------------------------------------------------------------- > ----------- > > Using Tomcat but need to do more? Need to support > > web services, security? > > Get stuff done quickly with pre-integrated > > technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 > > based on Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Conor S. <bor...@ya...> - 2006-09-05 05:54:29
|
The edge stack in this case is part of the (de)compression algorithm - you maintain a stack of "open" edges to add triangles to. You are always adding a triangle to the edge at the top of the stack. A new triangle is either a link from the edge on top of the stack to a new vertice (that hasn't previously been touched) or one of the other edges (usually the connected forward edge). Cheers, Conor --- Tom Forsyth <tom...@ee...> wrote: > > PS Of course, if a hardware manufacturer ever > > implemented something like this in hardware and > used > > the edge stack to keep a cache primed... well that > > would be crazy talk. > > Most high-end rasterisers these days are > plane-equation based rather than > trapezoid-walk things (much easier to parallelise), > so the edge equations > aren't as expensive as they used to be. Interesting > idea though. > > TomF. > > > > -----Original Message----- > > From: > gda...@li... > > > [mailto:gda...@li...] > On > > Behalf Of Conor Stokes > > Sent: 04 September 2006 20:44 > > To: Game Development Algorithms > > Subject: Re: [Algorithms] Triangle strips still > useful? > > > > > > I've found I get pretty good performance out of > meshes > > reproduced from compression. > > > > About 3 years ago I wrote a mesh compression > library > > that used something similar to the cut-border > machine > > > (http://www.gris.uni-tuebingen.de/~sgumhold/MeshComp/index.html), > > but with a lot of modifications (I use a > different > > set of operators, mainly by making connect > forwards > > and connect back more powerful). > > > > Generally early on in the triangle stream it > produces > > something like interconnected fans that loop back > on > > themselves... then later on it tends to produce > > closing or spiralling rings. > > > > Of course, one day I intend to get back to this > > project and get it the stage of something I can > > release and stand behind... but that's one of > those > > pipe dreams ;-). > > > > Cheers, > > Conor > > > > PS Of course, if a hardware manufacturer ever > > implemented something like this in hardware and > used > > the edge stack to keep a cache primed... well that > > would be crazy talk. > > > > --- Martin Slater <ms...@ne...> wrote: > > > > > > > > > > > >http://sourceforge.net/mailarchive/message.php?msg_id=7193196 > > > > > > > >Might find some info there. > > > > > > > >Alen > > > > > > > > > > I never got round to posting the results but > from > > > memory it gave results > > > something like 20-30% worse than using > > > DXDXOptimiseMesh which is cache > > > size aware, i'll see if I can dig up the > original > > > results in the office > > > tommorow. The biggest downside was that its very > > > slow to run which can > > > impact on your toolchain turnaround time quite a > > > lot. > > > > > > Martin > > > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.1.405 / Virus Database: 268.11.7/436 > - > > > Release Date: 1/09/2006 > > > > > > > > > > > > -------------------------------------------------------------- > > ----------- > > > Using Tomcat but need to do more? Need to > support > > > web services, security? > > > Get stuff done quickly with pre-integrated > > > technology to make your job easier > > > Download IBM WebSphere Application Server > v.1.0.1 > > > based on Apache Geronimo > > > > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& > dat=121642 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support > web services, security? > Get stuff done quickly with pre-integrated > technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 > based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support > web services, security? > Get stuff done quickly with pre-integrated > technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 > based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: <c.s...@ph...> - 2006-09-05 09:44:47
|
Just going to concor on this point. A single run on over the index buffer reassingning vertex indices in the = order they are encountered (which our exporter does anyway) is = sufficient to optimize most meshes to get to peak vertex throughput. -----Urspr=FCngliche Nachricht----- Von: gda...@li... [mailto:gda...@li...]Im Auftrag von Tom Forsyth Gesendet: Montag, 4. September 2006 02:07 An: 'Game Development Algorithms' Betreff: Re: [Algorithms] Triangle strips still useful? > I was wondering if people were using the Hoppe Hilbert curve research I actually think Hoppe's stuff is somewhat of a dead end. It's good if = you know everything about your target hardware - cache size, replacement = policy, etc. So it's useful for consoles where they tell you those things (on = some consoles it's still a secret!). But if you don't know, I can't see a way = to extend it to include unknowns without the Hilbert-curve stuff then = working better. In practice, I've found the simple greedy non-lookahead reorderer I did = for the big G gets you within 10% of either Hoppe or the Hilbert stuff, = works for a large range of cache sizes and types, and is really fast to run = (no lookahead!), which gets quite important now we're looking at = million-poly meshes and the like. Once you throw in the randomness of real-world = meshes (which are not nice regular planes), the difference is almost lost in = noise. When unified shader hardware arrives (any decade now *sigh*), the = percentage devoted to vertex processing seems like it will be fairly small anyway, = so all this research, while obviously fascinating, may well be completely = moot, because we're trying to get that last few percent of an already small = amount of work. I have another rant about stripping on another blog which may amuse: http://www.eelpi.gotdns.org/blog.wiki.html#Strippers This was prompted by me seeing a paper published on stripping *last = year*. Smart people wasting their time... Eric wrote: >Anyway, my question is whether stripification is something we can = mostly=20 >cut from the next edition. Yes. Maybe a few notes on why indexing has replaced it, but nothing in-depth. >In one sense stripification could give you=20 >lists of triangles to use to order your index buffers. Not sure what you mean by this. Indexing works best when you give it a = wide, connected area to deal with - then it can create Hilbertish patterns in = it. Stripification tends to produce long thin structures that can't be = Hilberted very well and have many vertices that are only used by a few triangles. >We'll still cover triangle strips=20 >themselves, of course: they certainly have their use, e.g. drawing = thick=20 >lines or other data where an index buffer is superfluous. The concept of strips is also perfectly useful *for specifying indices*. = If hardware has a restart index (e.g. -1) then specifying your indexed primitives as strips rather than lists is a good idea. As a simple = example, if just two triangles share an edge, a list would be 0,1,2,2,1,3, = whereas a strip would be -1,0,1,2,3 - which saves an index. And of course = sometimes you can make strips longer than two. So that's a fairly obvious win even = for moderately convoluted triangle orderings. Again, the important thing is = not to change the order of the triangles when you do this stripping! Without a restart index you need to add degenerate triangles and the = picture is less clear, and depends on the hardware (how fast it deals with degenerate tris) and the mesh itself. I recommend doing the mesh both = ways and seeing which generates the fewest indices. TomF. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of = Eric Haines Sent: 03 September 2006 13:33 To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? Aras, Excellent info, thanks! Lots to chew on in Tom's blog, but just the sort = of thing I want. I was wondering if people were using the Hoppe Hilbert = curve research - looks like they do. I'll be interested to hear answers from others to see if people actually go this route or not. Eric Aras Pranckevicius wrote:=20 Anyway, my question is whether stripification is something we can mostly cut from the next edition. In one sense stripification could give you lists of triangles to use to order your index buffers. But it's kind-of overkill for this, and most index buffers that get formed usually have sharing of some sort in them. We'll still cover triangle strips themselves, of course: they certainly have their use, e.g. drawing thick lines or other data where an index buffer is superfluous. =20 On a PC and most other hardware, much more important is vertex cache optimization. You optimize for the vertex cache first, _then_ you can try strips that follow this optimized order. If you get less indices in the end, then maybe use the strips. Strips make more sense on hardware that supports "restart strip" indices. But still, vertex cache is the first optimization. TomF has some good info on this topic: http://tomsdxfaq.blogspot.com/2005_12_01_tomsdxfaq_archive.html#113546436= 585 770597 Also check out DirectX mailing list archives from 2005 december, subject "stripping": http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512c&L=3Dd= irectxd ev#11 and http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512d&L=3Dd= irectxd ev#9 =20 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Tom F. <tom...@ee...> - 2006-09-05 10:02:04
|
Well that's an orthogonal point. You should always do this after = creating the optimal index ordering. But it's optimising for the pre-transform = cache (which is usually just a dumb memory cache) and AGP/PCIE transfer burst size. Those are significant, but it does not reduce load on the vertex shader at all, just on the memory system. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Christian Sch=FCler > Sent: 05 September 2006 02:44 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? >=20 >=20 >=20 > Just going to concor on this point. > A single run on over the index buffer reassingning vertex=20 > indices in the order they are encountered (which our exporter=20 > does anyway) is sufficient to optimize most meshes to get to=20 > peak vertex throughput. >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: gda...@li... > [mailto:gda...@li...]Im Auftrag von > Tom Forsyth > Gesendet: Montag, 4. September 2006 02:07 > An: 'Game Development Algorithms' > Betreff: Re: [Algorithms] Triangle strips still useful? >=20 >=20 > > I was wondering if people were using the Hoppe Hilbert=20 > curve research >=20 > I actually think Hoppe's stuff is somewhat of a dead end.=20 > It's good if you > know everything about your target hardware - cache size,=20 > replacement policy, > etc. So it's useful for consoles where they tell you those=20 > things (on some > consoles it's still a secret!). But if you don't know, I=20 > can't see a way to > extend it to include unknowns without the Hilbert-curve stuff=20 > then working > better. >=20 > In practice, I've found the simple greedy non-lookahead=20 > reorderer I did for > the big G gets you within 10% of either Hoppe or the Hilbert=20 > stuff, works > for a large range of cache sizes and types, and is really=20 > fast to run (no > lookahead!), which gets quite important now we're looking at=20 > million-poly > meshes and the like. Once you throw in the randomness of=20 > real-world meshes > (which are not nice regular planes), the difference is almost=20 > lost in noise. > When unified shader hardware arrives (any decade now *sigh*),=20 > the percentage > devoted to vertex processing seems like it will be fairly=20 > small anyway, so > all this research, while obviously fascinating, may well be=20 > completely moot, > because we're trying to get that last few percent of an=20 > already small amount > of work. >=20 > I have another rant about stripping on another blog which may amuse: > http://www.eelpi.gotdns.org/blog.wiki.html#Strippers > This was prompted by me seeing a paper published on stripping=20 > *last year*. > Smart people wasting their time... >=20 >=20 > Eric wrote: > >Anyway, my question is whether stripification is something=20 > we can mostly=20 > >cut from the next edition. >=20 > Yes. Maybe a few notes on why indexing has replaced it, but nothing > in-depth. >=20 > >In one sense stripification could give you=20 > >lists of triangles to use to order your index buffers. >=20 > Not sure what you mean by this. Indexing works best when you=20 > give it a wide, > connected area to deal with - then it can create Hilbertish=20 > patterns in it. > Stripification tends to produce long thin structures that=20 > can't be Hilberted > very well and have many vertices that are only used by a few=20 > triangles. >=20 > >We'll still cover triangle strips=20 > >themselves, of course: they certainly have their use, e.g.=20 > drawing thick=20 > >lines or other data where an index buffer is superfluous. >=20 > The concept of strips is also perfectly useful *for=20 > specifying indices*. If > hardware has a restart index (e.g. -1) then specifying your indexed > primitives as strips rather than lists is a good idea. As a=20 > simple example, > if just two triangles share an edge, a list would be=20 > 0,1,2,2,1,3, whereas a > strip would be -1,0,1,2,3 - which saves an index. And of=20 > course sometimes > you can make strips longer than two. So that's a fairly=20 > obvious win even for > moderately convoluted triangle orderings. Again, the=20 > important thing is not > to change the order of the triangles when you do this stripping! >=20 > Without a restart index you need to add degenerate triangles=20 > and the picture > is less clear, and depends on the hardware (how fast it deals with > degenerate tris) and the mesh itself. I recommend doing the=20 > mesh both ways > and seeing which generates the fewest indices. >=20 >=20 > TomF. >=20 >=20 > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On=20 > Behalf Of Eric > Haines > Sent: 03 September 2006 13:33 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? >=20 >=20 > Aras, >=20 > Excellent info, thanks! Lots to chew on in Tom's blog, but=20 > just the sort of > thing I want. I was wondering if people were using the Hoppe=20 > Hilbert curve > research - looks like they do. I'll be interested to hear answers from > others to see if people actually go this route or not. >=20 > Eric >=20 >=20 > Aras Pranckevicius wrote:=20 > Anyway, my question is whether stripification is something we=20 > can mostly > cut from the next edition. In one sense stripification could give you > lists of triangles to use to order your index buffers. But=20 > it's kind-of > overkill for this, and most index buffers that get formed usually have > sharing of some sort in them. We'll still cover triangle strips > themselves, of course: they certainly have their use, e.g.=20 > drawing thick > lines or other data where an index buffer is superfluous. > =20 >=20 > On a PC and most other hardware, much more important is vertex cache > optimization. You optimize for the vertex cache first, _then_ you can > try strips that follow this optimized order. If you get less indices > in the end, then maybe use the strips. Strips make more sense on > hardware that supports "restart strip" indices. But still, vertex > cache is the first optimization. >=20 > TomF has some good info on this topic: > http://tomsdxfaq.blogspot.com/2005_12_01_tomsdxfaq_archive.htm l#113546436585 770597 Also check out DirectX mailing list archives from 2005 december, subject "stripping": http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512c&L=3Dd= irectxd ev#11 and http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512d&L=3Dd= irectxd ev#9 =20 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Warrick B. <war...@fi...> - 2006-09-05 10:07:21
|
I noticed that the overdraw optimisations that ATI's tootle tool does = hasn't been mentioned - although obviously that's more of a pixel shader = throughput thing but obviously incorporating that kind of optimisation = does affect your vertex ordering and thus vertex cache usage- no idea = what affect that has on the original question about strips though at the = moment. -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Christian Sch=FCler Sent: 05 September 2006 10:44 To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? Just going to concor on this point. A single run on over the index buffer reassingning vertex indices in the = order they are encountered (which our exporter does anyway) is = sufficient to optimize most meshes to get to peak vertex throughput. -----Urspr=FCngliche Nachricht----- Von: gda...@li... [mailto:gda...@li...]Im Auftrag von Tom Forsyth Gesendet: Montag, 4. September 2006 02:07 An: 'Game Development Algorithms' Betreff: Re: [Algorithms] Triangle strips still useful? > I was wondering if people were using the Hoppe Hilbert curve research I actually think Hoppe's stuff is somewhat of a dead end. It's good if = you know everything about your target hardware - cache size, replacement = policy, etc. So it's useful for consoles where they tell you those things (on = some consoles it's still a secret!). But if you don't know, I can't see a way = to extend it to include unknowns without the Hilbert-curve stuff then = working better. In practice, I've found the simple greedy non-lookahead reorderer I did = for the big G gets you within 10% of either Hoppe or the Hilbert stuff, = works for a large range of cache sizes and types, and is really fast to run = (no lookahead!), which gets quite important now we're looking at = million-poly meshes and the like. Once you throw in the randomness of real-world = meshes (which are not nice regular planes), the difference is almost lost in = noise. When unified shader hardware arrives (any decade now *sigh*), the = percentage devoted to vertex processing seems like it will be fairly small anyway, = so all this research, while obviously fascinating, may well be completely = moot, because we're trying to get that last few percent of an already small = amount of work. I have another rant about stripping on another blog which may amuse: http://www.eelpi.gotdns.org/blog.wiki.html#Strippers This was prompted by me seeing a paper published on stripping *last = year*. Smart people wasting their time... Eric wrote: >Anyway, my question is whether stripification is something we can = mostly=20 >cut from the next edition. Yes. Maybe a few notes on why indexing has replaced it, but nothing in-depth. >In one sense stripification could give you=20 >lists of triangles to use to order your index buffers. Not sure what you mean by this. Indexing works best when you give it a = wide, connected area to deal with - then it can create Hilbertish patterns in = it. Stripification tends to produce long thin structures that can't be = Hilberted very well and have many vertices that are only used by a few triangles. >We'll still cover triangle strips=20 >themselves, of course: they certainly have their use, e.g. drawing = thick=20 >lines or other data where an index buffer is superfluous. The concept of strips is also perfectly useful *for specifying indices*. = If hardware has a restart index (e.g. -1) then specifying your indexed primitives as strips rather than lists is a good idea. As a simple = example, if just two triangles share an edge, a list would be 0,1,2,2,1,3, = whereas a strip would be -1,0,1,2,3 - which saves an index. And of course = sometimes you can make strips longer than two. So that's a fairly obvious win even = for moderately convoluted triangle orderings. Again, the important thing is = not to change the order of the triangles when you do this stripping! Without a restart index you need to add degenerate triangles and the = picture is less clear, and depends on the hardware (how fast it deals with degenerate tris) and the mesh itself. I recommend doing the mesh both = ways and seeing which generates the fewest indices. TomF. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of = Eric Haines Sent: 03 September 2006 13:33 To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? Aras, Excellent info, thanks! Lots to chew on in Tom's blog, but just the sort = of thing I want. I was wondering if people were using the Hoppe Hilbert = curve research - looks like they do. I'll be interested to hear answers from others to see if people actually go this route or not. Eric Aras Pranckevicius wrote:=20 Anyway, my question is whether stripification is something we can mostly cut from the next edition. In one sense stripification could give you lists of triangles to use to order your index buffers. But it's kind-of overkill for this, and most index buffers that get formed usually have sharing of some sort in them. We'll still cover triangle strips themselves, of course: they certainly have their use, e.g. drawing thick lines or other data where an index buffer is superfluous. =20 On a PC and most other hardware, much more important is vertex cache optimization. You optimize for the vertex cache first, _then_ you can try strips that follow this optimized order. If you get less indices in the end, then maybe use the strips. Strips make more sense on hardware that supports "restart strip" indices. But still, vertex cache is the first optimization. TomF has some good info on this topic: http://tomsdxfaq.blogspot.com/2005_12_01_tomsdxfaq_archive.html#113546436= 585 770597 Also check out DirectX mailing list archives from 2005 december, subject "stripping": http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512c&L=3Dd= irectxd ev#11 and http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A1=3Dind0512d&L=3Dd= irectxd ev#9 =20 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Aras P. <ne...@gm...> - 2006-09-05 11:06:50
|
> I noticed that the overdraw optimisations that ATI's tootle tool > does hasn't been mentioned - although obviously that's more of > a pixel shader throughput thing but obviously incorporating that > kind of optimisation does affect your vertex ordering and thus > vertex cache usage- no idea what affect that has on the original > question about strips though at the moment. For vertex cache, the Tootle library itself just uses D3DX vertex cache optimizer (separately for each patch on the mesh). Of course any other optimizer can be used, the paper is just concerned about finding the set and ordering of patches to minimize overdraw. -- Aras Pranckevicius work: www.unity3d.com home: nesnausk.org/nearaz |
From: Warrick B. <war...@fi...> - 2006-09-05 11:15:39
|
Yup I know that. I just wasn't sure if doing that kind of optimisation would have any significant affect on the strips v lists question - which I doubt it would that much but you know its now another constraint to consider when optimising your meshes... -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Aras Pranckevicius Sent: 05 September 2006 12:07 To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? > I noticed that the overdraw optimisations that ATI's tootle tool > does hasn't been mentioned - although obviously that's more of > a pixel shader throughput thing but obviously incorporating that > kind of optimisation does affect your vertex ordering and thus > vertex cache usage- no idea what affect that has on the original > question about strips though at the moment. For vertex cache, the Tootle library itself just uses D3DX vertex cache optimizer (separately for each patch on the mesh). Of course any other optimizer can be used, the paper is just concerned about finding the set and ordering of patches to minimize overdraw. --=20 Aras Pranckevicius work: www.unity3d.com home: nesnausk.org/nearaz ------------------------------------------------------------------------ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Tom F. <tom...@ee...> - 2006-09-06 04:49:26
|
Yes. There's a vertex->triangle map, and obviously there's a triangle->vertex map (indices), but there's no lookahead - at each = stage, the algorithm looks at the history of which triangles it already added, = the adjacency info, and then decides on the next triangle to add, and that's = it - it never backtracks or changes its mind. So fundamentally the = algorithm is O(n) (ignoring the effects of CPU data caches on the adjacency map). TomF. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of = Matt J Sent: 05 September 2006 12:15 To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? Hi Tom, When you say non-lookahead, do you mean your reordering the indices = based soley on data from an adjacency buffer? Thanks, Matthew In practice, I've found the simple greedy non-lookahead reorderer I did = for=20 the big G gets you within 10% of either Hoppe or the Hilbert stuff, = works for a large range of cache sizes and types, and is really fast to run = (no lookahead!), which gets quite important now we're looking at = million-poly=20 meshes and the like. Once you throw in the randomness of real-world = meshes |
From: Eric H. <er...@ac...> - 2006-09-11 15:55:20
|
First, now that this thread has calmed down, thanks very much to everyone answering my question. I'll do my best to sum things up in the book, though I'll probably have to leave out some of the subtleties discussed here. Tom Forsyth wrote about his greedy algorithm (full post at bottom): > Yes. There's a vertex->triangle map, and obviously there's a triangle->vertex map (indices), but there's no lookahead Interesting, I was thinking more along the lines of a triangle->triangle neighbor list and labelling the vertices as to when they were last placed in the cache. Starting with an unprocessed triangle, examine its neighbors and choose the one (if any) whose third (non-shared) vertex has the highest vertex label number (i.e. whose third vertex was put in the cache latest). Then update the vertex label numbers, and put the other neighbors on a stack for possible processing later (when a triangle has no neighbors that have not already been processed). Continue with the new triangle you just added, checking its neighbors, etc. Of course, I haven't coded it up... Whatever the case, it seems to me that a greedy approach will probably give a back-and-forth pattern on a regular grid of triangles, right? That is, left-to-right along one row, then right to left on the next, and so on. You won't normally get anything like a Hilbert curve, which seems to be more ideal, at least judging from the papers out there. That said, it's way easier to code such methods vs. the more involved algorithms out there. Speaking of which, I was asking Sung-Eui Yoon about his research on cache-oblivious mesh layouts, http://gamma.cs.unc.edu/COL/. Code (non-commercial use only, sigh) is at http://gamma.cs.unc.edu/COL/OpenCCL/. I thought I'd pass on this tidbit, in case it's of interest. I wrote him: Have you compared it with the D3DXOptimizeFaces function provided by Microsoft in DirectX? His reply: Yes. The cache miss ratio of our cache-oblivious layout was around 10% higher than that of D3DXOptimizeFaces when we set a cache size 16 during rendering the bunny. But, if we set cache size 8 or 64, our cache-oblivious layout showed a better cache miss ratio. (Hoppe mentioned that D3DXOptimizeFaces was optimized at cache sizes 12 or 16.) But, for very irregular models such as power plant model, our layout showed better performance even at cache size 16. Probably, the method employed in the D3DXOptimizeFaces is not that good for such types of models. You can check out some detail info about comparison at page 6 and 7 of http://gamma.cs.unc.edu/COL/mesh-layouts-block-based-caches.pdf ---- Eric Tom Forsyth wrote: > Yes. There's a vertex->triangle map, and obviously there's a > triangle->vertex map (indices), but there's no lookahead - at each stage, > the algorithm looks at the history of which triangles it already added, the > adjacency info, and then decides on the next triangle to add, and that's it > - it never backtracks or changes its mind. So fundamentally the algorithm is > O(n) (ignoring the effects of CPU data caches on the adjacency map). > > TomF. > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of Matt J > Sent: 05 September 2006 12:15 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? > > > Hi Tom, > > When you say non-lookahead, do you mean your reordering the indices based > soley on data from an adjacency buffer? > > Thanks, > > Matthew > > > In practice, I've found the simple greedy non-lookahead reorderer I did for > the big G gets you within 10% of either Hoppe or the Hilbert stuff, works > for a large range of cache sizes and types, and is really fast to run (no > lookahead!), which gets quite important now we're looking at million-poly > meshes and the like. Once you throw in the randomness of real-world meshes > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > |
From: Tom F. <tom...@ee...> - 2006-09-30 06:18:42
|
I finally got around to writing up this algorithm. The paper itself is = here: http://www.eelpi.gotdns.org/papers/fast_vert_cache_opt.html ...and my rather less formal blog entry is here: http://www.eelpi.gotdns.org/blog.wiki.html If there's anything that needs clarifying, just ask and I'll add it to whichever is appropriate. I'd like to get hold of some of the meshes = used in the other papers referenced and do an actual apples-to-apples. > You won't normally get anything like a Hilbert=20 > curve, which seems to be more ideal, at least judging from > the papers out there. Curiously, you can get something surprisingly close, and the = experimental cache simulation results say that it's very close. I was pleasantly surprisied at how well this fairly dumb (but fast!) algorithm did. > Speaking of which, I was asking Sung-Eui Yoon about his research on=20 > cache-oblivious mesh layouts, http://gamma.cs.unc.edu/COL/. Code=20 > (non-commercial use only, sigh) is at=20 Oops - I missed this reference, sorry Eric. I'll have a read of it and = see if my paper needs updating to include a comparison with these numbers. = At the very least I should mention them. Frankly, *all* of the papers so = far are so close to being perfect that people probably don't care about the slight difference in results. We're really not vertex-processing bound = at the moment (maybe tri-setup-bound - that's a different problem), so = fussing over a few percent here and there might just be us geeks indulging our inappropriate optimisation fetishes :-) TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Eric Haines > Sent: 11 September 2006 08:57 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? >=20 >=20 > First, now that this thread has calmed down, thanks very much to=20 > everyone answering my question. I'll do my best to sum things=20 > up in the=20 > book, though I'll probably have to leave out some of the subtleties=20 > discussed here. >=20 > Tom Forsyth wrote about his greedy algorithm (full post at bottom): > > Yes. There's a vertex->triangle map, and obviously there's a=20 > triangle->vertex map (indices), but there's no lookahead >=20 > Interesting, I was thinking more along the lines of a=20 > triangle->triangle=20 > neighbor list and labelling the vertices as to when they were last=20 > placed in the cache. Starting with an unprocessed triangle,=20 > examine its=20 > neighbors and choose the one (if any) whose third (non-shared) vertex=20 > has the highest vertex label number (i.e. whose third vertex=20 > was put in=20 > the cache latest). Then update the vertex label numbers, and put the=20 > other neighbors on a stack for possible processing later (when a=20 > triangle has no neighbors that have not already been processed).=20 > Continue with the new triangle you just added, checking its=20 > neighbors,=20 > etc. Of course, I haven't coded it up... >=20 > Whatever the case, it seems to me that a greedy approach will=20 > probably=20 > give a back-and-forth pattern on a regular grid of triangles, right?=20 > That is, left-to-right along one row, then right to left on the next,=20 > and so on. You won't normally get anything like a Hilbert=20 > curve, which=20 > seems to be more ideal, at least judging from the papers out=20 > there. That=20 > said, it's way easier to code such methods vs. the more involved=20 > algorithms out there. >=20 > Speaking of which, I was asking Sung-Eui Yoon about his research on=20 > cache-oblivious mesh layouts, http://gamma.cs.unc.edu/COL/. Code=20 > (non-commercial use only, sigh) is at=20 > http://gamma.cs.unc.edu/COL/OpenCCL/. I thought I'd pass on=20 > this tidbit,=20 > in case it's of interest. >=20 > I wrote him: Have you compared it with the D3DXOptimizeFaces function=20 > provided by Microsoft in DirectX? >=20 > His reply: >=20 > Yes. The cache miss ratio of our cache-oblivious layout was=20 > around 10%=20 > higher than that of D3DXOptimizeFaces when we set a cache=20 > size 16 during=20 > rendering the bunny. But, if we set cache size 8 or 64, our=20 > cache-oblivious layout showed a better cache miss ratio. (Hoppe=20 > mentioned that D3DXOptimizeFaces was optimized at cache sizes=20 > 12 or 16.) >=20 > But, for very irregular models such as power plant model, our layout=20 > showed better performance even at cache size 16. Probably, the method=20 > employed in the D3DXOptimizeFaces is not that good for such types of=20 > models. >=20 > You can check out some detail info about comparison at page 6=20 > and 7 of=20 > http://gamma.cs.unc.edu/COL/mesh-layouts-block-based-caches.pdf >=20 > ---- >=20 > Eric >=20 >=20 > Tom Forsyth wrote: > > Yes. There's a vertex->triangle map, and obviously there's a > > triangle->vertex map (indices), but there's no lookahead -=20 > at each stage, > > the algorithm looks at the history of which triangles it=20 > already added, the > > adjacency info, and then decides on the next triangle to=20 > add, and that's it > > - it never backtracks or changes its mind. So fundamentally=20 > the algorithm is > > O(n) (ignoring the effects of CPU data caches on the adjacency map). > > > > TomF. > > > > > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On=20 > Behalf Of Matt J > > Sent: 05 September 2006 12:15 > > To: Game Development Algorithms > > Subject: Re: [Algorithms] Triangle strips still useful? > > > > > > Hi Tom, > > > > When you say non-lookahead, do you mean your reordering the=20 > indices based > > soley on data from an adjacency buffer? > > > > Thanks, > > > > Matthew > > > > > > In practice, I've found the simple greedy non-lookahead=20 > reorderer I did for=20 > > the big G gets you within 10% of either Hoppe or the=20 > Hilbert stuff, works > > for a large range of cache sizes and types, and is really=20 > fast to run (no > > lookahead!), which gets quite important now we're looking=20 > at million-poly=20 > > meshes and the like. Once you throw in the randomness of=20 > real-world meshes > > > > > >=20 > -------------------------------------------------------------- > ----------- > > Using Tomcat but need to do more? Need to support web=20 > services, security? > > Get stuff done quickly with pre-integrated technology to=20 > make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on=20 > Apache Geronimo > >=20 > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& dat=3D121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > =20 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Juhani H. <ju...@al...> - 2006-10-09 05:52:58
|
Thanks a lot Tom~! I had implemented a similar algorithm based on your notes earlier, but never had time to fine tune a vertex scoring system so the results were not that perfect. Now I just reimplemented that vertex scoring part according to your paper and the results are much better - I'm now getting vertex/tri ratio about ~0.75 for irregular meshes when it was close to ~0.9 earlier. Juhani Tom Forsyth wrote: >I finally got around to writing up this algorithm. The paper itself is here: >http://www.eelpi.gotdns.org/papers/fast_vert_cache_opt.html > >...and my rather less formal blog entry is here: >http://www.eelpi.gotdns.org/blog.wiki.html > >If there's anything that needs clarifying, just ask and I'll add it to >whichever is appropriate. I'd like to get hold of some of the meshes used in >the other papers referenced and do an actual apples-to-apples. > > > >>You won't normally get anything like a Hilbert >>curve, which seems to be more ideal, at least judging from >>the papers out there. >> >> > >Curiously, you can get something surprisingly close, and the experimental >cache simulation results say that it's very close. I was pleasantly >surprisied at how well this fairly dumb (but fast!) algorithm did. > > > >>Speaking of which, I was asking Sung-Eui Yoon about his research on >>cache-oblivious mesh layouts, http://gamma.cs.unc.edu/COL/. Code >>(non-commercial use only, sigh) is at >> >> > >Oops - I missed this reference, sorry Eric. I'll have a read of it and see >if my paper needs updating to include a comparison with these numbers. At >the very least I should mention them. Frankly, *all* of the papers so far >are so close to being perfect that people probably don't care about the >slight difference in results. We're really not vertex-processing bound at >the moment (maybe tri-setup-bound - that's a different problem), so fussing >over a few percent here and there might just be us geeks indulging our >inappropriate optimisation fetishes :-) > > >TomF. > > > > >>-----Original Message----- >>From: gda...@li... >>[mailto:gda...@li...] On >>Behalf Of Eric Haines >>Sent: 11 September 2006 08:57 >>To: Game Development Algorithms >>Subject: Re: [Algorithms] Triangle strips still useful? >> >> >>First, now that this thread has calmed down, thanks very much to >>everyone answering my question. I'll do my best to sum things >>up in the >>book, though I'll probably have to leave out some of the subtleties >>discussed here. >> >>Tom Forsyth wrote about his greedy algorithm (full post at bottom): >> > Yes. There's a vertex->triangle map, and obviously there's a >>triangle->vertex map (indices), but there's no lookahead >> >>Interesting, I was thinking more along the lines of a >>triangle->triangle >>neighbor list and labelling the vertices as to when they were last >>placed in the cache. Starting with an unprocessed triangle, >>examine its >>neighbors and choose the one (if any) whose third (non-shared) vertex >>has the highest vertex label number (i.e. whose third vertex >>was put in >>the cache latest). Then update the vertex label numbers, and put the >>other neighbors on a stack for possible processing later (when a >>triangle has no neighbors that have not already been processed). >>Continue with the new triangle you just added, checking its >>neighbors, >>etc. Of course, I haven't coded it up... >> >>Whatever the case, it seems to me that a greedy approach will >>probably >>give a back-and-forth pattern on a regular grid of triangles, right? >>That is, left-to-right along one row, then right to left on the next, >>and so on. You won't normally get anything like a Hilbert >>curve, which >>seems to be more ideal, at least judging from the papers out >>there. That >>said, it's way easier to code such methods vs. the more involved >>algorithms out there. >> >>Speaking of which, I was asking Sung-Eui Yoon about his research on >>cache-oblivious mesh layouts, http://gamma.cs.unc.edu/COL/. Code >>(non-commercial use only, sigh) is at >>http://gamma.cs.unc.edu/COL/OpenCCL/. I thought I'd pass on >>this tidbit, >>in case it's of interest. >> >>I wrote him: Have you compared it with the D3DXOptimizeFaces function >>provided by Microsoft in DirectX? >> >>His reply: >> >>Yes. The cache miss ratio of our cache-oblivious layout was >>around 10% >>higher than that of D3DXOptimizeFaces when we set a cache >>size 16 during >>rendering the bunny. But, if we set cache size 8 or 64, our >>cache-oblivious layout showed a better cache miss ratio. (Hoppe >>mentioned that D3DXOptimizeFaces was optimized at cache sizes >>12 or 16.) >> >>But, for very irregular models such as power plant model, our layout >>showed better performance even at cache size 16. Probably, the method >>employed in the D3DXOptimizeFaces is not that good for such types of >>models. >> >>You can check out some detail info about comparison at page 6 >>and 7 of >>http://gamma.cs.unc.edu/COL/mesh-layouts-block-based-caches.pdf >> >>---- >> >>Eric >> >> >>Tom Forsyth wrote: >> >> >>>Yes. There's a vertex->triangle map, and obviously there's a >>>triangle->vertex map (indices), but there's no lookahead - >>> >>> >>at each stage, >> >> >>>the algorithm looks at the history of which triangles it >>> >>> >>already added, the >> >> >>>adjacency info, and then decides on the next triangle to >>> >>> >>add, and that's it >> >> >>>- it never backtracks or changes its mind. So fundamentally >>> >>> >>the algorithm is >> >> >>>O(n) (ignoring the effects of CPU data caches on the adjacency map). >>> >>>TomF. >>> >>> >>>-----Original Message----- >>>From: gda...@li... >>>[mailto:gda...@li...] On >>> >>> >>Behalf Of Matt J >> >> >>>Sent: 05 September 2006 12:15 >>>To: Game Development Algorithms >>>Subject: Re: [Algorithms] Triangle strips still useful? >>> >>> >>>Hi Tom, >>> >>>When you say non-lookahead, do you mean your reordering the >>> >>> >>indices based >> >> >>>soley on data from an adjacency buffer? >>> >>>Thanks, >>> >>>Matthew >>> >>> >>>In practice, I've found the simple greedy non-lookahead >>> >>> >>reorderer I did for >> >> >>>the big G gets you within 10% of either Hoppe or the >>> >>> >>Hilbert stuff, works >> >> >>>for a large range of cache sizes and types, and is really >>> >>> >>fast to run (no >> >> >>>lookahead!), which gets quite important now we're looking >>> >>> >>at million-poly >> >> >>>meshes and the like. Once you throw in the randomness of >>> >>> >>real-world meshes >> >> >>> >>> >>> >>-------------------------------------------------------------- >>----------- >> >> >>>Using Tomcat but need to do more? Need to support web >>> >>> >>services, security? >> >> >>>Get stuff done quickly with pre-integrated technology to >>> >>> >>make your job easier >> >> >>>Download IBM WebSphere Application Server v.1.0.1 based on >>> >>> >>Apache Geronimo >> >> >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& >> >> >dat=121642 > > >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >> >> >> > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job >easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > |
From: Tomas A. @ Z. <ta...@ze...> - 2006-10-07 19:21:12
|
First of all I want to acknowledge the Sony guys for doing it right in the PS2. The ADC bit should be the right way to do this. I have ask people to incorporate A feature like that in the DX but they came back with a user definable index that will terminate the strip, which is very ugly. The ADC bit equivalent in DX should have been that any negative index will terminate The strip while the actual abs value of the index will be valid. This will allow to create strips without wasting any indices at all unlike the current Implementation of DX. This will have merge the concept of strips and list into a single one but ho well... Strips vs List I think people got it right. You want to optimize the vertex cache with the Minimum amount of indices/vertices possible. Which usually turns out to just be lists. I think thought the problem with strips and list and vertex caches is that is only one part of the equation. By itself ignores the rest of the pipe line which could have also impact in the final performance of the mesh. This is when we enter the fuzzy world of what if. For instance vertex locality may be important for texture fetches coherency in the pixel shader. They may be also important for back buffer pixel cache issues. I know of a least one hardware sensitive to those. Also ordering of vertices in patches may reduce the overall pixel overdraw. By making sure that convex objects get render from the outside to the inner size. I think there is a paper about this in this siggraph-2006... don't remember thought so many papers... ;-) And finally with DX10 is going to make this hold thing even more confusing when you will have to deal with the geometry pipe line in hardware. Then what do you optimize for? The vertex shader or the geometry shader? So I agree with don't over think the problem. And Strips and List should have gone away and merge into a single concept by now. Tomas |
From: Eric H. <er...@ac...> - 2006-10-10 02:57:19
|
Tomas Arce @ ZenXTech wrote: > Also ordering of vertices in patches may reduce the overall pixel overdraw. > By making sure that convex objects get render from the outside to the inner > size. I think there is a paper about this in this siggraph-2006... don't > remember thought so many papers... ;-) Someone pointed out this paper to me recently: "Triangle order optimization for graphics hardware computation culling", Diego Nehab et al., Symposium on Interactive 3D Graphics 2006 (a.k.a. I3D), http://www.cse.ust.hk/~psander/docs/too.pdf. Interesting concept, one I never would have thought of, but it seems like a fair bit of work - has anyone else used anything like this successfully? Eric |
From: Tom F. <tom...@ee...> - 2006-10-10 05:41:38
|
It was recently pointed out to me by Michiel van der Leeuw that some profiles show the pixel shaders and rasterisers starved during long = periods of backface culling. It is possible that by interleaving two streams of triangles, each with roughly opposite normals to each other, you could = at least halve this dead time. I thought about heuristics to do this, but = they seem tricky. A simple way would be to simply optimise each of the = clusters in the Nehab paper, then interleave pairs of them with moderately = opposing aggregate normals. Very simple, and would get a decent proportion of the benefit, as well as getting a lot of the early-Z stuff (culled tris are irrelevant to that question). The problem is that you effectively halve your vertex cache of course, = since the two streams generally have zero sharing with each other. However, if = you start with a largish 32-vertex cache, you do still have a 16-vertex = cache for each stream, which is a reasonable size and still gets decent performance. Maybe that's worth the benefit. It's a good question what the balance between the factors is though. If = the rasteriser and pixel shaders are really stagnant, for example for models with really really high triangle counts, it might even be worth = interleaving three or four streams, giving effective vertex caches of 10 or 8, in = order to keep the rasteriser busy. The problem as always is knowing your = target hardware, which is notoriously difficult in the PC arena. It's not all = that easy on consoles either. Looks like there's still some interesting work left here :-) TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Eric Haines > Sent: 09 October 2006 19:59 > To: Game Development Algorithms > Subject: Re: [Algorithms] Triangle strips still useful? >=20 >=20 > Tomas Arce @ ZenXTech wrote: > > Also ordering of vertices in patches may reduce the overall=20 > pixel overdraw. > > By making sure that convex objects get render from the=20 > outside to the inner > > size. I think there is a paper about this in this=20 > siggraph-2006... don't > > remember thought so many papers... ;-) > Someone pointed out this paper to me recently: "Triangle order=20 > optimization for graphics hardware computation culling",=20 > Diego Nehab et=20 > al., Symposium on Interactive 3D Graphics 2006 (a.k.a. I3D),=20 > http://www.cse.ust.hk/~psander/docs/too.pdf. Interesting=20 > concept, one I=20 > never would have thought of, but it seems like a fair bit of=20 > work - has=20 > anyone else used anything like this successfully? >=20 > Eric >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys -- and=20 > earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Robert D. <bli...@go...> - 2006-10-10 10:25:09
|
What counts as a "long period of backface culling" ? I would have expected that, since BFC is done at the triangle level, and the whole triangle is rejected very quickly, for a moderate to highly complex set of shaders, there would be time to BFC dozens of triangles just for the cost of rendering a single one that was forward facing. It might even be the case that this issue only arises when hundreds or thousands of triangles are BFCd together. Did Michiel give any kind of figures for the quantities involved before starving was noticeable ? > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Tom Forsyth > Sent: 10 October 2006 06:43 > To: 'Game Development Algorithms' > Subject: Re: [Algorithms] Triangle strips still useful? > > It was recently pointed out to me by Michiel van der Leeuw that some > profiles show the pixel shaders and rasterisers starved > during long periods > of backface culling. It is possible that by interleaving two > streams of > triangles, each with roughly opposite normals to each other, > you could at > least halve this dead time. I thought about heuristics to do > this, but they > seem tricky. A simple way would be to simply optimise each of > the clusters > in the Nehab paper, then interleave pairs of them with > moderately opposing > aggregate normals. Very simple, and would get a decent > proportion of the > benefit, as well as getting a lot of the early-Z stuff > (culled tris are > irrelevant to that question). > > The problem is that you effectively halve your vertex cache > of course, since > the two streams generally have zero sharing with each other. > However, if you > start with a largish 32-vertex cache, you do still have a > 16-vertex cache > for each stream, which is a reasonable size and still gets decent > performance. Maybe that's worth the benefit. > > It's a good question what the balance between the factors is > though. If the > rasteriser and pixel shaders are really stagnant, for example > for models > with really really high triangle counts, it might even be > worth interleaving > three or four streams, giving effective vertex caches of 10 > or 8, in order > to keep the rasteriser busy. The problem as always is knowing > your target > hardware, which is notoriously difficult in the PC arena. > It's not all that > easy on consoles either. > > Looks like there's still some interesting work left here :-) > > > TomF. > > > > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On > > Behalf Of Eric Haines > > Sent: 09 October 2006 19:59 > > To: Game Development Algorithms > > Subject: Re: [Algorithms] Triangle strips still useful? > > > > > > Tomas Arce @ ZenXTech wrote: > > > Also ordering of vertices in patches may reduce the overall > > pixel overdraw. > > > By making sure that convex objects get render from the > > outside to the inner > > > size. I think there is a paper about this in this > > siggraph-2006... don't > > > remember thought so many papers... ;-) > > Someone pointed out this paper to me recently: "Triangle order > > optimization for graphics hardware computation culling", > > Diego Nehab et > > al., Symposium on Interactive 3D Graphics 2006 (a.k.a. I3D), > > http://www.cse.ust.hk/~psander/docs/too.pdf. Interesting > > concept, one I > > never would have thought of, but it seems like a fair bit of > > work - has > > anyone else used anything like this successfully? > > > > Eric > > > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the > > chance to share your > > opinions on IT & business topics through brief surveys -- and > > earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys -- and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Tom F. <tom...@ee...> - 2006-10-10 20:33:04
|
Yeah, I don't know how long that FIFO is in real hardware these days, or what the variation from chip to chip is. I assume IHVs make it quite = long, but at a certain amount of tessellation, you're going to overwhelm it. > Did Michiel give any kind of figures for the quantities=20 > involved before starving was noticeable ? No - it's likely to be a proprietary platform :-) Hmmm... as well as a straight 1:1 interleave of "opposing" triangles, = you could interleave small runs, e.g. 16 tris of each. Then you get the full cache for the whole 16. Except... 16 tris doesn't benefit from a larger cache, i.e. if your hardware cache is 32 verts, a 1:1 interleave gets = you an effective 16-vert cache. So now if you feed a 16-tri blob to it, that = 16-tri blob will probably only use about 16 *verts*. So you get no benefit, and = all you've done is dirty the cache. It does mean you can use a restartable-indexed-strip topology though. = With a 1:1 interleave, you would always use indexed-lists. Slight win there. I wonder if you could: -Break into clusters like the Nehab/ATI stuff. -Optimise each cluster's tri order. -Turn each into restartable-indexed-strip primitives. -Pick two roughly "opposing" clusters. -Interleave them, but only switch between them when your restartable-indexed-strip actually used a restart. This would give a moderately fine interleave of ~4 tris or so, which is small enough not to scare the cache or blow out the trisetup FIFO, but = also not generate any more indices than before, AND get any early-Z-reject benefits. But as the ATI guys said, whether any of this actually helps depends on = such a huge number of factors. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Robert Dibley > Sent: 10 October 2006 03:25 > To: 'Game Development Algorithms' > Subject: Re: [Algorithms] Triangle strips still useful? >=20 >=20 > What counts as a "long period of backface culling" ? >=20 > I would have expected that, since BFC is done at the triangle=20 > level, and the > whole triangle is rejected very quickly, for a moderate to=20 > highly complex > set of shaders, there would be time to BFC dozens of=20 > triangles just for the > cost of rendering a single one that was forward facing. It=20 > might even be > the case that this issue only arises when hundreds or=20 > thousands of triangles > are BFCd together. >=20 > Did Michiel give any kind of figures for the quantities=20 > involved before > starving was noticeable ? >=20 >=20 > > -----Original Message----- > > From: gda...@li...=20 > > [mailto:gda...@li...] On=20 > > Behalf Of Tom Forsyth > > Sent: 10 October 2006 06:43 > > To: 'Game Development Algorithms' > > Subject: Re: [Algorithms] Triangle strips still useful? > >=20 > > It was recently pointed out to me by Michiel van der Leeuw that some > > profiles show the pixel shaders and rasterisers starved=20 > > during long periods > > of backface culling. It is possible that by interleaving two=20 > > streams of > > triangles, each with roughly opposite normals to each other,=20 > > you could at > > least halve this dead time. I thought about heuristics to do=20 > > this, but they > > seem tricky. A simple way would be to simply optimise each of=20 > > the clusters > > in the Nehab paper, then interleave pairs of them with=20 > > moderately opposing > > aggregate normals. Very simple, and would get a decent=20 > > proportion of the > > benefit, as well as getting a lot of the early-Z stuff=20 > > (culled tris are > > irrelevant to that question). > >=20 > > The problem is that you effectively halve your vertex cache=20 > > of course, since > > the two streams generally have zero sharing with each other.=20 > > However, if you > > start with a largish 32-vertex cache, you do still have a=20 > > 16-vertex cache > > for each stream, which is a reasonable size and still gets decent > > performance. Maybe that's worth the benefit. > >=20 > > It's a good question what the balance between the factors is=20 > > though. If the > > rasteriser and pixel shaders are really stagnant, for example=20 > > for models > > with really really high triangle counts, it might even be=20 > > worth interleaving > > three or four streams, giving effective vertex caches of 10=20 > > or 8, in order > > to keep the rasteriser busy. The problem as always is knowing=20 > > your target > > hardware, which is notoriously difficult in the PC arena.=20 > > It's not all that > > easy on consoles either. > >=20 > > Looks like there's still some interesting work left here :-) > >=20 > >=20 > > TomF. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: gda...@li...=20 > > > [mailto:gda...@li...] On=20 > > > Behalf Of Eric Haines > > > Sent: 09 October 2006 19:59 > > > To: Game Development Algorithms > > > Subject: Re: [Algorithms] Triangle strips still useful? > > >=20 > > >=20 > > > Tomas Arce @ ZenXTech wrote: > > > > Also ordering of vertices in patches may reduce the overall=20 > > > pixel overdraw. > > > > By making sure that convex objects get render from the=20 > > > outside to the inner > > > > size. I think there is a paper about this in this=20 > > > siggraph-2006... don't > > > > remember thought so many papers... ;-) > > > Someone pointed out this paper to me recently: "Triangle order=20 > > > optimization for graphics hardware computation culling",=20 > > > Diego Nehab et=20 > > > al., Symposium on Interactive 3D Graphics 2006 (a.k.a. I3D),=20 > > > http://www.cse.ust.hk/~psander/docs/too.pdf. Interesting=20 > > > concept, one I=20 > > > never would have thought of, but it seems like a fair bit of=20 > > > work - has=20 > > > anyone else used anything like this successfully? > > >=20 > > > Eric > > >=20 > > > -------------------------------------------------------------- > > > ----------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the=20 > > > chance to share your > > > opinions on IT & business topics through brief surveys -- and=20 > > > earn cash > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDEV > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the=20 > > chance to share your > > opinions on IT & business topics through brief surveys -- and=20 > > earn cash > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys -- and=20 > earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Joshua B. <jba...@at...> - 2006-10-10 15:21:34
|
That is probably the paper Tomas is thinking of. It was presented at I3D, and also at the I3D reprise sketch at SIGGRAPH. The ATI 3DARG just released a library that implements the algorithms from this paper. (http://www.ati.com/developer/tootle.html) We've also integrated this library into the preprocessing pipeline for our internal demo engine and seen some solid reductions in overdraw on real models (see the example on the above link). If the pixel shaders are expensive, then this will translate to a performance improvement. If they aren't, then it won't do much, but it's not going to hurt either, and you can still optimize for vertex cache coherence. =20 Unfortunately, we haven't been using it for long enough to see a big payoff, so we don't have very much data apart from what was published in the paper. If anybody has used our library and had any success stories, I'd love to hear about them (and I'm sure that our devrel people (de...@at...) would as well). JB =20 -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Eric Haines Sent: Monday, October 09, 2006 10:59 PM To: Game Development Algorithms Subject: Re: [Algorithms] Triangle strips still useful? Tomas Arce @ ZenXTech wrote: > Also ordering of vertices in patches may reduce the overall pixel overdraw. > By making sure that convex objects get render from the outside to the=20 > inner size. I think there is a paper about this in this=20 > siggraph-2006... don't remember thought so many papers... ;-) Someone pointed out this paper to me recently: "Triangle order optimization for graphics hardware computation culling", Diego Nehab et al., Symposium on Interactive 3D Graphics 2006 (a.k.a. I3D), http://www.cse.ust.hk/~psander/docs/too.pdf. Interesting concept, one I never would have thought of, but it seems like a fair bit of work - has anyone else used anything like this successfully? Eric ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Tomas A. @ Z. <ta...@ze...> - 2006-10-12 16:44:35
|
Another way to think about the triangle strips lists, etc. It is just a way to represent a patch object. Where the patch is already been texelated for you. Then it will be worth adding a CULL cone-sphere. Cone-sphere I define it as a sphere that can become a cone such you will have a normal and a parametric value that will go from [1,-1] along the normal which will describe the uni-sphere extent. Such if you do the dot product between the camera and the normal you can reject base on the parametric value. The hardware could use this cone-sphere to skip a hold batch of triangles. But there is a good chance that triangles are going to just become a specialize primitive as pixel shader becomes better at giving good parallax and the geometry shader may be able to improve the silhouette. The hardware guys just need to add a new texture format that will allow for real time raytracing of it. Similar to the http://www.ati.com/developer/gdc/2006/GDC06-Tatarchuk-Parallax_Occlusion_Map ping.pdf. It will be a good first step towards a more robust raytracer. But I guess I am changing the subject here. Tomas |
From: Tom F. <tom...@ee...> - 2006-10-13 05:45:33
|
Triangle-batch cone-culling is used quite a lot on hardware such as PS2 where small batch sizes are a fact of life. As there's no practical way = to increase the batch sizes (in most engines - depends how you code up your = VU1 pipeline), you might as well cull each batch and get all the benefit you can. > towards a more robust r*******r. Oh dear, he said the "R" word. Burn the witch! :-) TomF. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of = Tomas Arce @ ZenXTech Sent: 12 October 2006 09:44 To: gda...@li... Subject: Re: [Algorithms] Triangle strips still useful? Another way to think about the triangle strips lists, etc. It is just a = way to represent a patch object. Where the patch is already been texelated = for you. Then it will be worth adding a CULL cone-sphere. Cone-sphere I = define it as a sphere that can become a cone such you will have a normal and a parametric value that will go from [1,-1] along the normal which will describe the uni-sphere extent. Such if you do the dot product between = the camera and the normal you can reject base on the parametric value. The hardware could use this cone-sphere to skip a hold batch of triangles.=20 =20 But there is a good chance that triangles are going to just become a specialize primitive as pixel shader becomes better at giving good = parallax and the geometry shader may be able to improve the silhouette. The = hardware guys just need to add a new texture format that will allow for real time raytracing of it. Similar to the http://www.ati.com/developer/gdc/2006/GDC06-Tatarchuk-Parallax_Occlusion_= Map ping.pdf. It will be a good first step towards a more robust raytracer.=20 =20 But I guess I am changing the subject here. Tomas =20 |
From: Martin S. <ms...@ne...> - 2006-09-04 08:07:10
|
>http://sourceforge.net/mailarchive/message.php?msg_id=7193196 > >Might find some info there. > >Alen > I never got round to posting the results but from memory it gave results something like 20-30% worse than using DXDXOptimiseMesh which is cache size aware, i'll see if I can dig up the original results in the office tommorow. The biggest downside was that its very slow to run which can impact on your toolchain turnaround time quite a lot. Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/436 - Release Date: 1/09/2006 |
From: Conor S. <bor...@ya...> - 2006-09-05 03:43:50
|
I've found I get pretty good performance out of meshes reproduced from compression. About 3 years ago I wrote a mesh compression library that used something similar to the cut-border machine (http://www.gris.uni-tuebingen.de/~sgumhold/MeshComp/index.html), but with a lot of modifications (I use a different set of operators, mainly by making connect forwards and connect back more powerful). Generally early on in the triangle stream it produces something like interconnected fans that loop back on themselves... then later on it tends to produce closing or spiralling rings. Of course, one day I intend to get back to this project and get it the stage of something I can release and stand behind... but that's one of those pipe dreams ;-). Cheers, Conor PS Of course, if a hardware manufacturer ever implemented something like this in hardware and used the edge stack to keep a cache primed... well that would be crazy talk. --- Martin Slater <ms...@ne...> wrote: > > >http://sourceforge.net/mailarchive/message.php?msg_id=7193196 > > > >Might find some info there. > > > >Alen > > > > I never got round to posting the results but from > memory it gave results > something like 20-30% worse than using > DXDXOptimiseMesh which is cache > size aware, i'll see if I can dig up the original > results in the office > tommorow. The biggest downside was that its very > slow to run which can > impact on your toolchain turnaround time quite a > lot. > > Martin > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.405 / Virus Database: 268.11.7/436 - > Release Date: 1/09/2006 > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support > web services, security? > Get stuff done quickly with pre-integrated > technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 > based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |