Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Thatcher Ulrich <tu@tu...>  20050112 18:06:25

On Jan 12, 2005 at 04:39 0000, Bob Dowland wrote: > > On the other hand, I can't help wondering whether PM isn't overkill > for the application  I've no need for the "progressive"ness either > for LOD or anything else and secondly I can't have any loss of > detail in boundary features eg "facet" verts and edges. Are there no > "boundary walking" approaches for just the planar stuff..(?) Hm. If you have a planar polygon with N boundary verts, and you don't specifically need interior verts (for color/texture attributes or whatever), then the minimum number of faces in the mesh is N2, and you can tesselate it without using any interior verts. So, if you can't get rid of any boundary verts, and you don't need any interior verts, then you could just keep collapsing interior verts until they're all gone. On the other hand, if you don't have any interior verts to start with, and you can't get rid of boundary verts, then there's nothing you can do; you should already be at the minimal mesh. If you are allowed to get rid of boundary verts, then you can go ahead and apply error metrics etc.  Thatcher Ulrich http://tulrich.com 
From: Bob Dowland <Bob.Dowland@bl...>  20050112 16:39:23

Thanks Paul, Interesting, you came up with this  I looked at Stan Melax's bunny = software recently and got a bit of a feel for the general idea and = curvature cost/metric thing. It's pretty amazing how nicely it all works =  except if you just give it a tesselated quad in which case it just = screws it up and gives you the finger. There seem to be two really nice ideas in PM (1) use of a single = operation  edge collapse. (2) use of a metric to guage the cost and = hence order of application. Now if I'm going down this route then a = curvature metric is obviously no good to me coz that's established and = same for all (tris are coplanar) but edge collapse is attractive so = maybe I just need to think about this metric a bit more carefully. On the other hand, I can't help wondering whether PM isn't overkill for = the application  I've no need for the "progressive"ness either for LOD = or anything else and secondly I can't have any loss of detail in = boundary features eg "facet" verts and edges. Are there no "boundary = walking" approaches for just the planar stuff..(?) Thanks again tho, :) Bob. btw if anyone's interested in SM's "bunnylod" the article is here http://docs.happycoders.org/orgadoc/graphics/rendering/prog_mesh_and_poly= _simpl/gdmag.pdf > Original Message > From: Paul_Firth@... [mailto:Paul_Firth@...] > Sent: 12 January 2005 13:38 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] mesh optimisation/simplification >=20 >=20 > On 12/01/2005 13:01:23 gdalgorithmslistadmin wrote:=20 >=20 > >Hi all, > > I'm looking for sources of info/ideas on tri mesh=20 > simplification/optimisation =20 > > mostly 2D, for use in a preprocess. The objective is to be able to=20 > identify and=20 > > optimise over triangulated planar regions, tidy them up and=20 > return a=20 > mesh with=20 > > erhh.. fewer tris. Does anyone know of any good references=20 > for this sort=20 > of=20 > > poly bashing. >=20 > Hi Bob, >=20 > The basic idea is that you collapse edges within your mesh=20 > based on the=20 > "cost" of performing the collapse, with cheapest first,=20 > obviously. There=20 > are many different cost metrics out there, but for something=20 > simple like=20 > removing over triangulation, you could base it on the abs dot product=20 > between neighbour faces of a candidate edge, say. >=20 > The classic reference is huges hoppe's paper >=20 > http://research.microsoft.com/~hoppe/pm.pdf >=20 > Cheers, Paul. >=20 >=20 > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... >=20 > This footnote also confirms that this email message has been checked > for all known viruses. >=20 > ********************************************************************** > Sony Computer Entertainment Europe >=20 >=20 >=20 >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 
From: Bob Dowland <Bob.Dowland@bl...>  20050113 09:55:42

Okay  a picture is beginning to form.. :) I begin to think that a good start would simply be: find the connected = sets, discard everything but the boundary contours, retriangulate = between contours  ie what Erin said. I think we're all agreed that PM = isn't for flat things but some form of "progressivecontour" LOD = (2DPMLOD ;) on verts and edges could be applied to those contours. = Garland's phd stuff looks really nice. Thank you all for the excellent input. Bob. > Original Message > From: Paul_Firth@... [mailto:Paul_Firth@...] > Sent: 12 January 2005 16:54 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] mesh optimisation/simplification >=20 >=20 > gdalgorithmslistadmin@... wrote on 12/01/2005=20 > 16:39:14: >=20 > > Thanks Paul, > >=20 > > Interesting, you came up with this  I looked at Stan Melax's bunny=20 > > software recently and got a bit of a feel for the general idea and=20 >=20 > Yeah, i think thats were everyone starts when looking at this=20 > stuff ;) >=20 > > There seem to be two really nice ideas in PM (1) use of a single=20 > > operation  edge collapse. (2) use of a metric to guage the cost and > > hence order of application. Now if I'm going down this route then a=20 > > curvature metric is obviously no good to me coz that's established=20 > > and same for all (tris are coplanar) but edge collapse is attractive > > so maybe I just need to think about this metric a bit more=20 > carefully. > >=20 > > On the other hand, I can't help wondering whether PM isn't overkill=20 > > for the application  I've no need for the "progressive"ness either > > for LOD or anything else and secondly I can't have any loss of=20 > > detail in boundary features eg "facet" verts and edges. Are there no > > "boundary walking" approaches for just the planar stuff..(?) >=20 > You can weight boundary edges collapses heavily so that they=20 > don't happen=20 > until every other internal edge has been collapsed, and then=20 > you could=20 > simply stop when there are no nonboundary edges left. >=20 > PM does look like overkill, but I thought that paper was=20 > clearer about the=20 > preprocess than his straight mesh optimisation paper. >=20 > There might well be some specialised technique for handling=20 > just planar=20 > surfaces, but I've not heard of one... >=20 > Cheers, Paul. >=20 >=20 >=20 >=20 > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... >=20 > This footnote also confirms that this email message has been checked > for all known viruses. >=20 > ********************************************************************** > Sony Computer Entertainment Europe >=20 >=20 >=20 >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 
From: PeterPike Sloan <ppsloan@wi...>  20050113 21:39:37

QEM won't work well with planar meshes without attributes  since the error is zero for everything but the boundaries. One hacky way to make it work would be to add a quadric for every edge in the mesh (not just the boundary edges), this will cause the planar regions to be reduced in a more reasonable fashion (ie: kind of hierarchically...) You might want to have a small weight associated with these "internal edge quadrics" so they only kick in on planar regions... This is a hack because you are preserving structure from some initial tessellation that probably isn't important. PeterPike (Boundary edge quadrics are just planes that contain the given edge and the plane normal lies inside the triangle...) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Jerome Liard Sent: Thursday, January 13, 2005 12:09 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] mesh optimisation/simplification Did someone actually try it (qslim) on planar meshes? (since the questions is about " mostly 2D"...) I remember being very happy with Garland's method on well tesselated 3d models, I also liked the possibility of being able to take into account extra attributes like vertex color. But when simplifying a simple 2d grid I vaguely remember not getting very nice results (I mean I got a few long, thin triangles here and there, even though the input was a perfect regular grid...). Simplifiying a vertex colored chess board gave better result, because the color discontinuities would "guide" simplification locally. I remember thinking to myself "if I had to simplifiy planar meshes, I would try something else..." But that was a few years ago and maybe it was just a problem in my implementation.  Original Message  From: "Alex Mohr" <amohr@...> To: <gdalgorithmslist@...> Sent: Thursday, January 13, 2005 2:59 AM Subject: Re: [Algorithms] mesh optimisation/simplification > You might check out Michael Garland's qslim. Very fast, very > straightforward, very good quality, and free code. > > http://graphics.cs.uiuc.edu/~garland/software/qslim.html > > Alex > > >>Hi all, >>I'm looking for sources of info/ideas on tri mesh=20 >>simplification/optimisation  mostly 2D, for use in a preprocess. The=20 >>objective is to be able to identify and optimise over triangulated planar=20 >>regions, tidy them up and return a mesh with erhh.. fewer tris. Does=20 >>anyone know of any good references for this sort of poly bashing. >> >>Many thanks, >> >>:) >> >>Bob. >> >> >> >>The SF.Net email is sponsored by: Beat the postholiday blues >>Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. >>It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt >>_______________________________________________ >>GDAlgorithmslist mailing list >>GDAlgorithmslist@... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >  Outgoing mail is certified Virus Free. Checked by AVG antivirus system (http://www.grisoft.com). Version: 6.0.789 / Virus Database: 534  Release Date: 2004/11/07=20  The SF.Net email is sponsored by: Beat the postholiday blues Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Bob Dowland <Bob.Dowland@bl...>  20050114 11:45:49

> (Boundary edge quadrics are just planes that contain the=20 > given edge and > the plane normal lies inside the triangle...) I tried something like this  manually  after seeing what the bunnylod = programme did to a tesselated quad. It did collapse "better". > This is a hack because you are preserving structure from some initial > tessellation that probably isn't important. Yes it's not a way to select the structure you want to preserve just = (perhaps) a way to "pin it" ie make error spikes just where they're = needed to hold back the LOD pixies. > Original Message > From: PeterPike Sloan [mailto:ppsloan@...] > Sent: 13 January 2005 21:39 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] mesh optimisation/simplification >=20 >=20 > QEM won't work well with planar meshes without attributes  since the > error is zero for everything but the boundaries. One hacky=20 > way to make > it work would be to add a quadric for every edge in the mesh (not just > the boundary edges), this will cause the planar regions to be=20 > reduced in > a more reasonable fashion (ie: kind of hierarchically...) You might > want to have a small weight associated with these "internal edge > quadrics" so they only kick in on planar regions... >=20 > This is a hack because you are preserving structure from some initial > tessellation that probably isn't important. >=20 > PeterPike >=20 > (Boundary edge quadrics are just planes that contain the=20 > given edge and > the plane normal lies inside the triangle...) >=20 > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of > Jerome Liard > Sent: Thursday, January 13, 2005 12:09 AM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] mesh optimisation/simplification >=20 > Did someone actually try it (qslim) on planar meshes? (since the > questions is about " mostly 2D"...) >=20 > I remember being very happy with Garland's method on well=20 > tesselated 3d > models, I also liked the possibility of being able to take=20 > into account > extra attributes like vertex color. >=20 > But when simplifying a simple 2d grid I vaguely remember not getting > very nice results (I mean I got a few long, thin triangles here and > there, even though the input was a perfect regular grid...). > Simplifiying a vertex colored chess board gave better result, because > the color discontinuities would "guide" simplification locally. I > remember thinking to myself "if I had to simplifiy planar meshes, I > would try something else..." But that was a few years ago and maybe it > was just a problem in my implementation. >=20 >  Original Message  > From: "Alex Mohr" <amohr@...> > To: <gdalgorithmslist@...> > Sent: Thursday, January 13, 2005 2:59 AM > Subject: Re: [Algorithms] mesh optimisation/simplification >=20 >=20 > > You might check out Michael Garland's qslim. Very fast, very > > straightforward, very good quality, and free code. > > > > http://graphics.cs.uiuc.edu/~garland/software/qslim.html > > > > Alex > > > > > >>Hi all, > >>I'm looking for sources of info/ideas on tri mesh=20 > >>simplification/optimisation  mostly 2D, for use in a=20 > preprocess. The=20 > >>objective is to be able to identify and optimise over triangulated > planar=20 > >>regions, tidy them up and return a mesh with erhh.. fewer=20 > tris. Does=20 > >>anyone know of any good references for this sort of poly bashing. > >> > >>Many thanks, > >> > >>:) > >> > >>Bob. > >> > >> > >> > >>The SF.Net email is sponsored by: Beat the postholiday blues > >>Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > >>It's fun and FREE  well,=20 > almost....http://www.thinkgeek.com/sfshirt > >>_______________________________________________ > >>GDAlgorithmslist mailing list > >>GDAlgorithmslist@... > >>https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >>Archives: > >>http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > > >  > > The SF.Net email is sponsored by: Beat the postholiday blues > > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > > It's fun and FREE  well,=20 > almost....http://www.thinkgeek.com/sfshirt > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > >=20 >=20 >  > Outgoing mail is certified Virus Free. > Checked by AVG antivirus system (http://www.grisoft.com). > Version: 6.0.789 / Virus Database: 534  Release Date: 2004/11/07=20 >=20 >=20 >=20 >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 
From: <Paul_Firth@sc...>  20050112 16:57:20

gdalgorithmslistadmin@... wrote on 12/01/2005 16:39:14: > Thanks Paul, > > Interesting, you came up with this  I looked at Stan Melax's bunny > software recently and got a bit of a feel for the general idea and Yeah, i think thats were everyone starts when looking at this stuff ;) > There seem to be two really nice ideas in PM (1) use of a single > operation  edge collapse. (2) use of a metric to guage the cost and > hence order of application. Now if I'm going down this route then a > curvature metric is obviously no good to me coz that's established > and same for all (tris are coplanar) but edge collapse is attractive > so maybe I just need to think about this metric a bit more carefully. > > On the other hand, I can't help wondering whether PM isn't overkill > for the application  I've no need for the "progressive"ness either > for LOD or anything else and secondly I can't have any loss of > detail in boundary features eg "facet" verts and edges. Are there no > "boundary walking" approaches for just the planar stuff..(?) You can weight boundary edges collapses heavily so that they don't happen until every other internal edge has been collapsed, and then you could simply stop when there are no nonboundary edges left. PM does look like overkill, but I thought that paper was clearer about the preprocess than his straight mesh optimisation paper. There might well be some specialised technique for handling just planar surfaces, but I've not heard of one... Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** Sony Computer Entertainment Europe 
From: Thatcher Ulrich <tu@tu...>  20050112 18:06:25

On Jan 12, 2005 at 04:39 0000, Bob Dowland wrote: > > On the other hand, I can't help wondering whether PM isn't overkill > for the application  I've no need for the "progressive"ness either > for LOD or anything else and secondly I can't have any loss of > detail in boundary features eg "facet" verts and edges. Are there no > "boundary walking" approaches for just the planar stuff..(?) Hm. If you have a planar polygon with N boundary verts, and you don't specifically need interior verts (for color/texture attributes or whatever), then the minimum number of faces in the mesh is N2, and you can tesselate it without using any interior verts. So, if you can't get rid of any boundary verts, and you don't need any interior verts, then you could just keep collapsing interior verts until they're all gone. On the other hand, if you don't have any interior verts to start with, and you can't get rid of boundary verts, then there's nothing you can do; you should already be at the minimal mesh. If you are allowed to get rid of boundary verts, then you can go ahead and apply error metrics etc.  Thatcher Ulrich http://tulrich.com 
From: Erin Catto <erincatto@sb...>  20050113 07:25:27

Right, just identify the boundary of the planar region and retriangulate. This will leave the geometry of the mesh unchanged and it removes all interior vertices. There is some free triangulation code over on flipcode. I haven't tested it yet. http://www.flipcode.com/cgibin/fcarticles.cgi?show=63943 I think you could develop a simple algorithm to reduce the number of boundary vertices. First identify all flat polygons and mark collinear boundary vertices for deletion. In the second pass, delete all interior vertices that have been marked twice. Then retriangulation can begin. Erin Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Thatcher Ulrich Sent: Wednesday, January 12, 2005 10:05 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] mesh optimisation/simplification On Jan 12, 2005 at 04:39 0000, Bob Dowland wrote: > > On the other hand, I can't help wondering whether PM isn't overkill > for the application  I've no need for the "progressive"ness either > for LOD or anything else and secondly I can't have any loss of > detail in boundary features eg "facet" verts and edges. Are there no > "boundary walking" approaches for just the planar stuff..(?) Hm. If you have a planar polygon with N boundary verts, and you don't specifically need interior verts (for color/texture attributes or whatever), then the minimum number of faces in the mesh is N2, and you can tesselate it without using any interior verts. So, if you can't get rid of any boundary verts, and you don't need any interior verts, then you could just keep collapsing interior verts until they're all gone. On the other hand, if you don't have any interior verts to start with, and you can't get rid of boundary verts, then there's nothing you can do; you should already be at the minimal mesh. If you are allowed to get rid of boundary verts, then you can go ahead and apply error metrics etc.  Thatcher Ulrich http://tulrich.com  The SF.Net email is sponsored by: Beat the postholiday blues Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tom Forsyth <tom.forsyth@ee...>  20050113 07:04:12

The original PM paper is rather simplistic, and the error metric is only good for geometry (and slow). A variety of better geometric metrics are the Quadric Error Metric = family by Garland & Heckbert. Google will find them. Hoppe has also done some further work on these, as well as an = interesting metric for attributes, which may be what you want (http://research.microsoft.com/~hoppe/newqem.pdf  or just go to http://research.microsoft.com/~hoppe/ and look at the abstracts  there = a couple of papers on related topics). But there are a huge number of error metrics  which one is "best" is = very subjective. This paper = http://meshdev.sourceforge.net/files/RoyIcip02.pdf gives a fairly good roundup of the field in its introduction. TomF. > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Bob Dowland > Sent: 12 January 2005 08:39 > To: gdalgorithmslist@... > Subject: RE: [Algorithms] mesh optimisation/simplification >=20 >=20 > Thanks Paul, >=20 > Interesting, you came up with this  I looked at Stan Melax's=20 > bunny software recently and got a bit of a feel for the=20 > general idea and curvature cost/metric thing. It's pretty=20 > amazing how nicely it all works  except if you just give it=20 > a tesselated quad in which case it just screws it up and=20 > gives you the finger. >=20 > There seem to be two really nice ideas in PM (1) use of a=20 > single operation  edge collapse. (2) use of a metric to=20 > guage the cost and hence order of application. Now if I'm=20 > going down this route then a curvature metric is obviously no=20 > good to me coz that's established and same for all (tris are=20 > coplanar) but edge collapse is attractive so maybe I just=20 > need to think about this metric a bit more carefully. >=20 > On the other hand, I can't help wondering whether PM isn't=20 > overkill for the application  I've no need for the=20 > "progressive"ness either for LOD or anything else and=20 > secondly I can't have any loss of detail in boundary features=20 > eg "facet" verts and edges. Are there no "boundary walking"=20 > approaches for just the planar stuff..(?) >=20 > Thanks again tho, >=20 > :) >=20 > Bob. >=20 > btw if anyone's interested in SM's "bunnylod" the article is here > http://docs.happycoders.org/orgadoc/graphics/rendering/prog_me > sh_and_poly_simpl/gdmag.pdf >=20 > > Original Message > > From: Paul_Firth@... [mailto:Paul_Firth@...] > > Sent: 12 January 2005 13:38 > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] mesh optimisation/simplification > >=20 > >=20 > > On 12/01/2005 13:01:23 gdalgorithmslistadmin wrote:=20 > >=20 > > >Hi all, > > > I'm looking for sources of info/ideas on tri mesh=20 > > simplification/optimisation =20 > > > mostly 2D, for use in a preprocess. The objective is to=20 > be able to=20 > > identify and=20 > > > optimise over triangulated planar regions, tidy them up and=20 > > return a=20 > > mesh with=20 > > > erhh.. fewer tris. Does anyone know of any good references=20 > > for this sort=20 > > of=20 > > > poly bashing. > >=20 > > Hi Bob, > >=20 > > The basic idea is that you collapse edges within your mesh=20 > > based on the=20 > > "cost" of performing the collapse, with cheapest first,=20 > > obviously. There=20 > > are many different cost metrics out there, but for something=20 > > simple like=20 > > removing over triangulation, you could base it on the abs=20 > dot product=20 > > between neighbour faces of a candidate edge, say. > >=20 > > The classic reference is huges hoppe's paper > >=20 > > http://research.microsoft.com/~hoppe/pm.pdf > >=20 > > Cheers, Paul. > >=20 > >=20 > >=20 > ********************************************************************** > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error=20 > please notify > > postmaster@... > >=20 > > This footnote also confirms that this email message has been checked > > for all known viruses. > >=20 > >=20 > ********************************************************************** > > Sony Computer Entertainment Europe > >=20 > >=20 > >=20 > >  > > The SF.Net email is sponsored by: Beat the postholiday blues > > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > > It's fun and FREE  well,=20 > almost....http://www.thinkgeek.com/sfshirt > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 >=20 >=20 >  > The SF.Net email is sponsored by: Beat the postholiday blues > Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. > It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 
From: Jon Watte <hplus@mi...>  20050113 20:34:26

> Are there no "boundary walking" approaches for just the planar stuff..(?) If you have a boundary which makes a polygon in a plane, then you just want to tesselate that polygon, which can be done for example using "ear clipping" (which works on concave polygons, too). You really can't do much better without also affecting the boundary, which you say is a nono. Cheers, / h+ 
From: Alex Mohr <amohr@cs...>  20050113 21:29:53

>If you have a boundary which makes a polygon in a plane, then you >just want to tesselate that polygon, which can be done for example >using "ear clipping" (which works on concave polygons, too). You >really can't do much better without also affecting the boundary, >which you say is a nono. You can perhaps make a "nicer" triangulation, like constrained Delaunay, but yeah you can't reduce the number of triangles without modifying the boundary. Alex 
Sign up for the SourceForge newsletter:
No, thanks