Thread: RE: [Algorithms] Mesh Decimation with Attributes.
Brought to you by:
vexxed72
From: Tom F. <to...@mu...> - 2003-02-20 16:52:45
|
Hoppe's concept of "wedges" is what most of us think of as a "vertex", i.e. psoition, normal, UVs, etc all rolled into one object. The way I do stuff is that you don't store verts/wedges, you store a bunch of vertices with duplicate positions, and store notes between all of them that they're "proximal" (it's just a circular linked list, each vertex points to the next). I never try to find "optimal midpoints" at all. They usually don't improve the image quality significantly, and they completely break any VIPM scheme you have going on. Just pick one the of vertices to bin, and collapse it onto the other one. Keeps things simple. The range of collapses that can be performed with proximal verts is very limited, as you've discovered. Basically, the operations that can be performed are: -Any non-prox vert can be collapsed onto a vert with proxes. -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be collapsed onto a vertex (V2) with a proximal vertex (Vp2) _that shares a triangle edge with Vp1_. Because then you can work out how to pair them up. And that's it. Any other collapses lead you scratching your head wondering how to calculate the error metric and how to match texture coordinates up. It does mean artists have to be careful about the number of seams they have in models, because although collapses can be done _along_ seams, you can't ever get rid of seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 16:27 > To: gda...@li... > Subject: [Algorithms] Mesh Decimation with Attributes. > > > Hi, > > I'm currently trying to implement a mesh decimation system based on > error-quadrics, specifically, those defined in "New Quadric > Error Metric > for Simplifying Meshes with Appearance Attributes" by Hughes Hoppe. > I'm using the mesh representation from the paper, i.e. you > have lists of > vertices, wedges and triangles, each triangles holds indices to 3 > wedges, each wedge holds an index to a vertex. A vertex is just a > position while a wedge contains all the attribute information, normal, > colour, uvs etc... > > I completely understand the basic system described in most of the > papers, where you just have a position to worry about, but > I'm getting a > bit stuck working out where the wedges might fit in... > > As I understand it, a solving a quadric will give you an approximation > to the optimal (in some sense) position and set of attributes for the > vertex that you are collapsing an edge to. > But...If, as is quite often the case, I have multiple wedges > surrounding > a vertex pair that I want to contract, solving the relevant quadric > gives me a vertex position and attribs (essentially a vertex and a > wedge). > This implies that the new vertex has only one wedge, yet before I > contracted the vertex pair, they might have had many different wedges? > > Hope that's clear - not sure how else to describe it!! > > What am I doing/thinking wrong? > > TIA, > > Andrew Vidler. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > 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: Christopher P. <cph...@re...> - 2003-02-20 17:00:05
|
I'm trying to implement the same thing.. I actually started before I found the paper, so I've actually been using wide 'vertices' that each have UV, normal, material ID and a reference to a position that may be shared between multiple vertices. At the moment my mesh reducer refuses to modify edges that have vertices sharing their position with others (so my material boundaries remain overtesselated), but my plan is to build a quadric that is a function of (position, (uv, normal), (uv, normal)', (uv,normal)'' ...) - ie one set of attributes for each vertex or {pair of vertices on a collapsing triangles}. Not working on it directly at the moment as I'm elsewhere in the toolchain this week. ----------------------------- > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 16:27 > To: gda...@li... > Subject: [Algorithms] Mesh Decimation with Attributes. > > > Hi, > > I'm currently trying to implement a mesh decimation system based on > error-quadrics, specifically, those defined in "New Quadric > Error Metric > for Simplifying Meshes with Appearance Attributes" by Hughes Hoppe. > I'm using the mesh representation from the paper, i.e. you > have lists of > vertices, wedges and triangles, each triangles holds indices to 3 > wedges, each wedge holds an index to a vertex. A vertex is just a > position while a wedge contains all the attribute information, normal, > colour, uvs etc... > > I completely understand the basic system described in most of the > papers, where you just have a position to worry about, but > I'm getting a > bit stuck working out where the wedges might fit in... > > As I understand it, a solving a quadric will give you an approximation > to the optimal (in some sense) position and set of attributes for the > vertex that you are collapsing an edge to. > But...If, as is quite often the case, I have multiple wedges > surrounding > a vertex pair that I want to contract, solving the relevant quadric > gives me a vertex position and attribs (essentially a vertex and a > wedge). > This implies that the new vertex has only one wedge, yet before I > contracted the vertex pair, they might have had many different wedges? > > Hope that's clear - not sure how else to describe it!! > > What am I doing/thinking wrong? > > TIA, > > Andrew Vidler. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > -Virus scanned and cleared ok |
From: Tom F. <to...@mu...> - 2003-02-20 17:42:19
|
That's the problem - getting rid of discontinuities sounds "acceptable" when you're talking about normals and vertex colours, but it's fatal if you're talking about textures - you end up rendering with bits of texture that the artists haven't drawn any pixels on, or some multiple-wrapping nightmare. I do discard differences in normals after a while (we don't have vertex colours, but I would do the same with those if we did), especially as most of our lighting uses normal maps rather than the vertex normals, but you absolutely can't ignore texture discontinuities - they basically hang around forever. In some special cases you might know that you won't be bringing in untextured areas, but in general that seems pretty tough to figure out. Better to just tweak the original models to avoid too many texture seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 17:09 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I > guess the > option might be nice... > > Ok, so for vertices surrounded by a single wedge, it all > works fine, but > for vertices with multiple wedges, what about just saying that for a > given collapse, calculate the new vertex pos and wedge using > the quadric > (or picking one of the existing ones, whatever), and just setting all > the faces that share the vertex to use that single wedge? > This way you can get rid of discontinuities (although you may not want > to...) > > Any idea if that would look any good?! > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Tom > Forsyth > Sent: 20 February 2003 16:47 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Hoppe's concept of "wedges" is what most of us think of as a "vertex", > i.e. psoition, normal, UVs, etc all rolled into one object. > > The way I do stuff is that you don't store verts/wedges, you store a > bunch of vertices with duplicate positions, and store notes > between all > of them that they're "proximal" (it's just a circular linked > list, each > vertex points to the next). > > I never try to find "optimal midpoints" at all. They usually don't > improve the image quality significantly, and they completely break any > VIPM scheme you have going on. Just pick one the of vertices > to bin, and > collapse it onto the other one. Keeps things simple. > > The range of collapses that can be performed with proximal > verts is very > limited, as you've discovered. Basically, the operations that can be > performed are: > > -Any non-prox vert can be collapsed onto a vert with proxes. > > -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be > collapsed onto a vertex (V2) with a proximal vertex (Vp2) > _that shares a > triangle edge with Vp1_. Because then you can work out how to > pair them > up. > > And that's it. Any other collapses lead you scratching your head > wondering how to calculate the error metric and how to match texture > coordinates up. It does mean artists have to be careful about > the number > of seams they have in models, because although collapses can be done > _along_ seams, you can't ever get rid of seams. > > > Tom Forsyth - Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > -----Original Message----- > > From: Andrew Vidler [mailto:av...@in...] > > Sent: 20 February 2003 16:27 > > To: gda...@li... > > Subject: [Algorithms] Mesh Decimation with Attributes. > > > > > > Hi, > > > > I'm currently trying to implement a mesh decimation system based on > > error-quadrics, specifically, those defined in "New Quadric Error > > Metric for Simplifying Meshes with Appearance Attributes" by Hughes > > Hoppe. I'm using the mesh representation from the paper, i.e. you > > have lists of > > vertices, wedges and triangles, each triangles holds indices to 3 > > wedges, each wedge holds an index to a vertex. A vertex is just a > > position while a wedge contains all the attribute > information, normal, > > colour, uvs etc... > > > > I completely understand the basic system described in most of the > > papers, where you just have a position to worry about, but > I'm getting > > > a bit stuck working out where the wedges might fit in... > > > > As I understand it, a solving a quadric will give you an > approximation > > > to the optimal (in some sense) position and set of > attributes for the > > vertex that you are collapsing an edge to. But...If, as is > quite often > > > the case, I have multiple wedges surrounding > > a vertex pair that I want to contract, solving the relevant quadric > > gives me a vertex position and attribs (essentially a vertex and a > > wedge). > > This implies that the new vertex has only one wedge, yet before I > > contracted the vertex pair, they might have had many > different wedges? > > > > Hope that's clear - not sure how else to describe it!! > > > > What am I doing/thinking wrong? > > > > TIA, > > > > Andrew Vidler. > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop > an edge. The > > > most comprehensive and flexible code editor you can use. > Code faster. > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > GDAlgorithms-list mailing list > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > 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: Andrew V. <av...@in...> - 2003-02-20 18:02:07
|
Ok, I think, if I understand this all correctly, that the only real problem is combining the wedges when that would mean combining a uv discontinuity (or a texture/material discontinuity - not necessarily the same thing.) So the only contractions I need to forbid are those that would combine a uv or material discontinuity? -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: 20 February 2003 17:36 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. That's the problem - getting rid of discontinuities sounds "acceptable" when you're talking about normals and vertex colours, but it's fatal if you're talking about textures - you end up rendering with bits of texture that the artists haven't drawn any pixels on, or some multiple-wrapping nightmare. I do discard differences in normals after a while (we don't have vertex colours, but I would do the same with those if we did), especially as most of our lighting uses normal maps rather than the vertex normals, but you absolutely can't ignore texture discontinuities - they basically hang around forever. In some special cases you might know that you won't be bringing in untextured areas, but in general that seems pretty tough to figure out. Better to just tweak the original models to avoid too many texture seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. |
From: Christopher P. <cph...@re...> - 2003-02-20 17:48:03
|
> -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 17:31 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Actually, scrap that, call me pedantic, but I'm sure this must be > possible... > > I've just found a paragraph from Hoppe's paper that says (paraphrase): > > "Unify the wedges w1, w2 after the collapse if they both extended into > one of the now degenerate triangles." > > So, why can't I do something like this - sorry, can't draw > this in ascii art, so I've attached a small picture > Yup - that's exactly what you need to do. Not only for maintaining edges, but also consider that each of the arcs you've drawn in the picture may be using a different material/texture. ----------------------------- -Virus scanned and cleared ok |
From: Ville M. <wi...@hy...> - 2003-02-20 18:06:54
|
Tom, there's an interesting new paper by Williams et al. ("Perceptually Guided Simplification of Lit, Textured Meshes", http://www.cs.virginia.edu/~luebke/publications/pdf/I3D2003.perceptual.simp. pdf ). Although the approach is view-dependent (and not directly applicable to the problem discussed in this thread), the paper contains some nice ideas on preserving the textures (and normal maps) when simplification is performed. cheers, -wili Ville Miettinen Hybrid Graphics, Ltd. http://www.hybrid.fi -----Original Message----- From: Tom Forsyth [mailto:to...@mu...] Sent: 20. helmikuuta 2003 19:36 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. That's the problem - getting rid of discontinuities sounds "acceptable" when you're talking about normals and vertex colours, but it's fatal if you're talking about textures - you end up rendering with bits of texture that the artists haven't drawn any pixels on, or some multiple-wrapping nightmare. I do discard differences in normals after a while (we don't have vertex colours, but I would do the same with those if we did), especially as most of our lighting uses normal maps rather than the vertex normals, but you absolutely can't ignore texture discontinuities - they basically hang around forever. In some special cases you might know that you won't be bringing in untextured areas, but in general that seems pretty tough to figure out. Better to just tweak the original models to avoid too many texture seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 17:09 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I > guess the > option might be nice... > > Ok, so for vertices surrounded by a single wedge, it all > works fine, but > for vertices with multiple wedges, what about just saying that for a > given collapse, calculate the new vertex pos and wedge using > the quadric > (or picking one of the existing ones, whatever), and just setting all > the faces that share the vertex to use that single wedge? > This way you can get rid of discontinuities (although you may not want > to...) > > Any idea if that would look any good?! > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Tom > Forsyth > Sent: 20 February 2003 16:47 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Hoppe's concept of "wedges" is what most of us think of as a "vertex", > i.e. psoition, normal, UVs, etc all rolled into one object. > > The way I do stuff is that you don't store verts/wedges, you store a > bunch of vertices with duplicate positions, and store notes > between all > of them that they're "proximal" (it's just a circular linked > list, each > vertex points to the next). > > I never try to find "optimal midpoints" at all. They usually don't > improve the image quality significantly, and they completely break any > VIPM scheme you have going on. Just pick one the of vertices > to bin, and > collapse it onto the other one. Keeps things simple. > > The range of collapses that can be performed with proximal > verts is very > limited, as you've discovered. Basically, the operations that can be > performed are: > > -Any non-prox vert can be collapsed onto a vert with proxes. > > -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be > collapsed onto a vertex (V2) with a proximal vertex (Vp2) > _that shares a > triangle edge with Vp1_. Because then you can work out how to > pair them > up. > > And that's it. Any other collapses lead you scratching your head > wondering how to calculate the error metric and how to match texture > coordinates up. It does mean artists have to be careful about > the number > of seams they have in models, because although collapses can be done > _along_ seams, you can't ever get rid of seams. > > > Tom Forsyth - Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > -----Original Message----- > > From: Andrew Vidler [mailto:av...@in...] > > Sent: 20 February 2003 16:27 > > To: gda...@li... > > Subject: [Algorithms] Mesh Decimation with Attributes. > > > > > > Hi, > > > > I'm currently trying to implement a mesh decimation system based on > > error-quadrics, specifically, those defined in "New Quadric Error > > Metric for Simplifying Meshes with Appearance Attributes" by Hughes > > Hoppe. I'm using the mesh representation from the paper, i.e. you > > have lists of > > vertices, wedges and triangles, each triangles holds indices to 3 > > wedges, each wedge holds an index to a vertex. A vertex is just a > > position while a wedge contains all the attribute > information, normal, > > colour, uvs etc... > > > > I completely understand the basic system described in most of the > > papers, where you just have a position to worry about, but > I'm getting > > > a bit stuck working out where the wedges might fit in... > > > > As I understand it, a solving a quadric will give you an > approximation > > > to the optimal (in some sense) position and set of > attributes for the > > vertex that you are collapsing an edge to. But...If, as is > quite often > > > the case, I have multiple wedges surrounding > > a vertex pair that I want to contract, solving the relevant quadric > > gives me a vertex position and attribs (essentially a vertex and a > > wedge). > > This implies that the new vertex has only one wedge, yet before I > > contracted the vertex pair, they might have had many > different wedges? > > > > Hope that's clear - not sure how else to describe it!! > > > > What am I doing/thinking wrong? > > > > TIA, > > > > Andrew Vidler. > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop > an edge. The > > > most comprehensive and flexible code editor you can use. > Code faster. > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > GDAlgorithms-list mailing list > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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. <to...@mu...> - 2003-02-20 18:07:38
|
The blue/cyan case is actually one of "allowed" ones I mentioned - that's a collapse along a seam (you can tell, because both blue and cyan share the red edge, so there's obviously a sensible way to interpolate from blue to cyan in the original mesh, because that's what you do when you draw that triangle!), and is just fine. It's the green/purple/dark green side that is the problem for us, and which we forbid. I guess what Hoppe is saying with those is that you don't try to change those wedges to some "average" - you just leave them as they are. The problem is that the vertex position has changed, but the texture coordinates haven't. So that's going to change the appearance of the original triangles. Whereas you'd usually do some sort of average that wouldn't change the appearange of the original triangles (much). I'm groping for words to why that sort of collapse is Evil. It just is OK? :-) If you're doing VIPM (I know you're not, but...), then the problem with doing this collapse is that you can't collapse either vertex to the other without creating a new vertex - no existing vertex has both dark and light green data. Whereas you can do that on the blue/cyan side, because cyan can be sensibly merged to blue (along the red edge) and vice versa. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 17:31 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Actually, scrap that, call me pedantic, but I'm sure this must be > possible... > > I've just found a paragraph from Hoppe's paper that says (paraphrase): > > "Unify the wedges w1, w2 after the collapse if they both extended into > one of the now degenerate triangles." > > So, why can't I do something like this - sorry, can't draw > this in ascii > art, so I've attached a small picture - sorry! > > Er...having just drawn the picture it's not the best in the world! :) > Explaination: > > The red edge in the middle of picture A is being collapsed, > picture B is > the result after the collapse. > The different coloured arcs represent the extents of the different > wedges of the vertex. > You can see that 2 of the wedges can be carried through without any > problem because they don't extend into either of the degenerate > triangles (the bright green and kind-of-khaki coloured one :) ). > Also, the two purple wedges can be disregarded because they are solely > in degenerate triangles. > The problem wedges are the blue and dark cyan ones (the ones > that extend > partially into a degenerate triangle, on the left hand side of picture > A). > Can't these wedges be averaged together or something and the resultant > edge used for the merged triangles (the red wedge in picture B). > > Hopefully that's explained it ok - sorry about the picture! > > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of > Andrew Vidler > Sent: 20 February 2003 17:09 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I > guess the > option might be nice... > > Ok, so for vertices surrounded by a single wedge, it all > works fine, but > for vertices with multiple wedges, what about just saying that for a > given collapse, calculate the new vertex pos and wedge using > the quadric > (or picking one of the existing ones, whatever), and just setting all > the faces that share the vertex to use that single wedge? This way you > can get rid of discontinuities (although you may not want > to...) > > Any idea if that would look any good?! > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Tom > Forsyth > Sent: 20 February 2003 16:47 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Hoppe's concept of "wedges" is what most of us think of as a "vertex", > i.e. psoition, normal, UVs, etc all rolled into one object. > > The way I do stuff is that you don't store verts/wedges, you store a > bunch of vertices with duplicate positions, and store notes > between all > of them that they're "proximal" (it's just a circular linked > list, each > vertex points to the next). > > I never try to find "optimal midpoints" at all. They usually don't > improve the image quality significantly, and they completely break any > VIPM scheme you have going on. Just pick one the of vertices > to bin, and > collapse it onto the other one. Keeps things simple. > > The range of collapses that can be performed with proximal > verts is very > limited, as you've discovered. Basically, the operations that can be > performed are: > > -Any non-prox vert can be collapsed onto a vert with proxes. > > -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be > collapsed onto a vertex (V2) with a proximal vertex (Vp2) > _that shares a > triangle edge with Vp1_. Because then you can work out how to > pair them > up. > > And that's it. Any other collapses lead you scratching your head > wondering how to calculate the error metric and how to match texture > coordinates up. It does mean artists have to be careful about > the number > of seams they have in models, because although collapses can be done > _along_ seams, you can't ever get rid of seams. > > > Tom Forsyth - Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > -----Original Message----- > > From: Andrew Vidler [mailto:av...@in...] > > Sent: 20 February 2003 16:27 > > To: gda...@li... > > Subject: [Algorithms] Mesh Decimation with Attributes. > > > > > > Hi, > > > > I'm currently trying to implement a mesh decimation system based on > > error-quadrics, specifically, those defined in "New Quadric Error > > Metric for Simplifying Meshes with Appearance Attributes" by Hughes > > Hoppe. I'm using the mesh representation from the paper, > i.e. you have > > > lists of vertices, wedges and triangles, each triangles > holds indices > > to 3 wedges, each wedge holds an index to a vertex. A > vertex is just a > > position while a wedge contains all the attribute > information, normal, > > colour, uvs etc... > > > > I completely understand the basic system described in most of the > > papers, where you just have a position to worry about, but > I'm getting > > > a bit stuck working out where the wedges might fit in... > > > > As I understand it, a solving a quadric will give you an > approximation > > > to the optimal (in some sense) position and set of > attributes for the > > vertex that you are collapsing an edge to. But...If, as is > quite often > > > the case, I have multiple wedges surrounding > > a vertex pair that I want to contract, solving the relevant quadric > > gives me a vertex position and attribs (essentially a vertex and a > > wedge). This implies that the new vertex has only one wedge, yet > > before I contracted the vertex pair, they might have had many > > different wedges? > > > > Hope that's clear - not sure how else to describe it!! > > > > What am I doing/thinking wrong? > > > > TIA, > > > > Andrew Vidler. > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop > an edge. The > > > most comprehensive and flexible code editor you can use. > Code faster. > > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > GDAlgorithms-list mailing list > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > 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. <to...@mu...> - 2003-02-20 18:22:26
|
Yes. Though combining discontinuity in normals and colours isn't fatal, just costly, because there is a sane way to interpolate any two normals/colours. You can probably just wrap that "badness" into the error metric. What I do before finding my mesh collapses is insert degenerate triangles along edges between vertices that only differ by normals. That way I don't have to deal with it - the collapse of one "wedge" to another just becomes a matter of collapsing a standard edge (although it's a zero-length one), and the error metric Just Works and makes those collapses suitably bad. Obviously I take these degenerates out again before rendering the data :-) UV discontinuities I just restrict in the way I mentioned. Those don't even get as far calculating an error metric - they're just never considered. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 18:01 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Ok, I think, if I understand this all correctly, that the only real > problem is combining the wedges when that would mean combining a uv > discontinuity (or a texture/material discontinuity - not > necessarily the > same thing.) > > So the only contractions I need to forbid are those that > would combine a > uv or material discontinuity? > > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Tom > Forsyth > Sent: 20 February 2003 17:36 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > That's the problem - getting rid of discontinuities sounds > "acceptable" > when you're talking about normals and vertex colours, but > it's fatal if > you're talking about textures - you end up rendering with bits of > texture that the artists haven't drawn any pixels on, or some > multiple-wrapping nightmare. > > I do discard differences in normals after a while (we don't > have vertex > colours, but I would do the same with those if we did), especially as > most of our lighting uses normal maps rather than the vertex normals, > but you absolutely can't ignore texture discontinuities - > they basically > hang around forever. > > In some special cases you might know that you won't be bringing in > untextured areas, but in general that seems pretty tough to > figure out. > Better to just tweak the original models to avoid too many texture > seams. > > > Tom Forsyth - Muckyfoot bloke and Microsoft MVP. > > This email is the product of your deranged imagination, > and does not in any way imply existence of the author. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > 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: Andrew V. <av...@in...> - 2003-02-21 11:22:24
|
Right, here's what I think I'm going to do: Disallow any contraction that would either; 1) involve a texture seam, or 2) contract across a material change. All the other types I'll allow and deal with - I'll probably end up adding in an additional quadric to each discontinuity edge to weight against contracting it. Thanks for all the help guys - I understand this much better now, cheers! -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: 20 February 2003 18:16 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. Yes. Though combining discontinuity in normals and colours isn't fatal, just costly, because there is a sane way to interpolate any two normals/colours. You can probably just wrap that "badness" into the error metric. What I do before finding my mesh collapses is insert degenerate triangles along edges between vertices that only differ by normals. That way I don't have to deal with it - the collapse of one "wedge" to another just becomes a matter of collapsing a standard edge (although it's a zero-length one), and the error metric Just Works and makes those collapses suitably bad. Obviously I take these degenerates out again before rendering the data :-) UV discontinuities I just restrict in the way I mentioned. Those don't even get as far calculating an error metric - they're just never considered. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 18:01 > To: gda...@li... > Subject: RE: [Algorithms] Mesh Decimation with Attributes. > > > Ok, I think, if I understand this all correctly, that the only real > problem is combining the wedges when that would mean combining a uv > discontinuity (or a texture/material discontinuity - not necessarily > the same thing.) > > So the only contractions I need to forbid are those that > would combine a > uv or material discontinuity? > > |
From: Andrew V. <av...@in...> - 2003-02-21 12:33:13
|
Actually, I do have one more question! :) If I perform an edge collapse, evaluating the vertex quadric gives me a position and a set of attributes, but I may have a number of attributes, on the face of things, it seems like I have to force the resulting vertex to just have one set of attributes (or wedge) whereas beforehand it had many. That's fine, because doing a contraction like this would be weighted so other contractions were considered first, but it occurs to me that I could also evaluate the individual wedge quadrics to give me a set of attributes for each resultant wedge and just use the vertex quadric (sum of wedge quadrics) to give me the position. Obviously the stuff about uv discontinuities still applies - you can't do them, so I'm ignoring that case as I'll just never touch any collapse that would involve a uv seam. Any thoughts on how well this might work? |
From: Jon W. <hp...@mi...> - 2003-02-21 18:57:01
|
> Disallow any contraction that would either; > 1) involve a texture seam, You can contract along a texture seam, as long as you make sure to contract both the "exploded" vertices involved at the same time, and possibly re-calculate UV coordinates to minimize stretching. Cheers, / h+ |
From: Doug R. <DR...@nv...> - 2003-02-20 19:23:37
|
What I do is to find all the the discontinuitues of edges and label them as seams. The seams define a border and within each seam border, I assign an "attribute group" that corresponds to a shared attributes section. The mesh is decimated, the seams are weighted the same as boundaries. After simplifaction, the material attritbute are resampled from the original mesh and no need to worries about mesh attributes during simplification. This has worked quite well. I am considering adding some texture deviation metric, but I haven't done that yet. -Doug -----Original Message----- From: Andrew Vidler [mailto:av...@in...] Sent: Thursday, February 20, 2003 10:01 AM To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. Ok, I think, if I understand this all correctly, that the only real problem is combining the wedges when that would mean combining a uv discontinuity (or a texture/material discontinuity - not necessarily the same thing.) So the only contractions I need to forbid are those that would combine a uv or material discontinuity? -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: 20 February 2003 17:36 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. That's the problem - getting rid of discontinuities sounds "acceptable" when you're talking about normals and vertex colours, but it's fatal if you're talking about textures - you end up rendering with bits of texture that the artists haven't drawn any pixels on, or some multiple-wrapping nightmare. I do discard differences in normals after a while (we don't have vertex colours, but I would do the same with those if we did), especially as most of our lighting uses normal maps rather than the vertex normals, but you absolutely can't ignore texture discontinuities - they basically hang around forever. In some special cases you might know that you won't be bringing in untextured areas, but in general that seems pretty tough to figure out. Better to just tweak the original models to avoid too many texture seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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: Doug R. <DR...@nv...> - 2003-02-21 18:04:16
|
Each wedge has one set of attributes, you may have multiple positions assigned to each wedge. The faces with common wedges will have one quadric. Other faces that share the same position, but have different attibutes (and wedges) will have a different quadric. -Doug -----Original Message----- From: Andrew Vidler [mailto:av...@in...] Sent: Friday, February 21, 2003 4:32 AM To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. Actually, I do have one more question! :) If I perform an edge collapse, evaluating the vertex quadric gives me a position and a set of attributes, but I may have a number of attributes, on the face of things, it seems like I have to force the resulting vertex to just have one set of attributes (or wedge) whereas beforehand it had many. That's fine, because doing a contraction like this would be weighted so other contractions were considered first, but it occurs to me that I could also evaluate the individual wedge quadrics to give me a set of attributes for each resultant wedge and just use the vertex quadric (sum of wedge quadrics) to give me the position. Obviously the stuff about uv discontinuities still applies - you can't do them, so I'm ignoring that case as I'll just never touch any collapse that would involve a uv seam. Any thoughts on how well this might work? ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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: Andrew V. <av...@in...> - 2003-02-20 17:10:05
|
I don't really need a VIPM scheme, just something that generates discrete lods - the lods don't have to be related, although I guess the option might be nice... Ok, so for vertices surrounded by a single wedge, it all works fine, but for vertices with multiple wedges, what about just saying that for a given collapse, calculate the new vertex pos and wedge using the quadric (or picking one of the existing ones, whatever), and just setting all the faces that share the vertex to use that single wedge? This way you can get rid of discontinuities (although you may not want to...) Any idea if that would look any good?! -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: 20 February 2003 16:47 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. Hoppe's concept of "wedges" is what most of us think of as a "vertex", i.e. psoition, normal, UVs, etc all rolled into one object. The way I do stuff is that you don't store verts/wedges, you store a bunch of vertices with duplicate positions, and store notes between all of them that they're "proximal" (it's just a circular linked list, each vertex points to the next). I never try to find "optimal midpoints" at all. They usually don't improve the image quality significantly, and they completely break any VIPM scheme you have going on. Just pick one the of vertices to bin, and collapse it onto the other one. Keeps things simple. The range of collapses that can be performed with proximal verts is very limited, as you've discovered. Basically, the operations that can be performed are: -Any non-prox vert can be collapsed onto a vert with proxes. -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be collapsed onto a vertex (V2) with a proximal vertex (Vp2) _that shares a triangle edge with Vp1_. Because then you can work out how to pair them up. And that's it. Any other collapses lead you scratching your head wondering how to calculate the error metric and how to match texture coordinates up. It does mean artists have to be careful about the number of seams they have in models, because although collapses can be done _along_ seams, you can't ever get rid of seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 16:27 > To: gda...@li... > Subject: [Algorithms] Mesh Decimation with Attributes. > > > Hi, > > I'm currently trying to implement a mesh decimation system based on > error-quadrics, specifically, those defined in "New Quadric Error > Metric for Simplifying Meshes with Appearance Attributes" by Hughes > Hoppe. I'm using the mesh representation from the paper, i.e. you > have lists of > vertices, wedges and triangles, each triangles holds indices to 3 > wedges, each wedge holds an index to a vertex. A vertex is just a > position while a wedge contains all the attribute information, normal, > colour, uvs etc... > > I completely understand the basic system described in most of the > papers, where you just have a position to worry about, but I'm getting > a bit stuck working out where the wedges might fit in... > > As I understand it, a solving a quadric will give you an approximation > to the optimal (in some sense) position and set of attributes for the > vertex that you are collapsing an edge to. But...If, as is quite often > the case, I have multiple wedges surrounding > a vertex pair that I want to contract, solving the relevant quadric > gives me a vertex position and attribs (essentially a vertex and a > wedge). > This implies that the new vertex has only one wedge, yet before I > contracted the vertex pair, they might have had many different wedges? > > Hope that's clear - not sure how else to describe it!! > > What am I doing/thinking wrong? > > TIA, > > Andrew Vidler. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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: Andrew V. <av...@in...> - 2003-02-20 17:32:53
Attachments:
edgecol.png
|
Actually, scrap that, call me pedantic, but I'm sure this must be possible... I've just found a paragraph from Hoppe's paper that says (paraphrase): "Unify the wedges w1, w2 after the collapse if they both extended into one of the now degenerate triangles." So, why can't I do something like this - sorry, can't draw this in ascii art, so I've attached a small picture - sorry! Er...having just drawn the picture it's not the best in the world! :) Explaination: The red edge in the middle of picture A is being collapsed, picture B is the result after the collapse. The different coloured arcs represent the extents of the different wedges of the vertex. You can see that 2 of the wedges can be carried through without any problem because they don't extend into either of the degenerate triangles (the bright green and kind-of-khaki coloured one :) ). Also, the two purple wedges can be disregarded because they are solely in degenerate triangles. The problem wedges are the blue and dark cyan ones (the ones that extend partially into a degenerate triangle, on the left hand side of picture A). Can't these wedges be averaged together or something and the resultant edge used for the merged triangles (the red wedge in picture B). Hopefully that's explained it ok - sorry about the picture! -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Andrew Vidler Sent: 20 February 2003 17:09 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. I don't really need a VIPM scheme, just something that generates discrete lods - the lods don't have to be related, although I guess the option might be nice... Ok, so for vertices surrounded by a single wedge, it all works fine, but for vertices with multiple wedges, what about just saying that for a given collapse, calculate the new vertex pos and wedge using the quadric (or picking one of the existing ones, whatever), and just setting all the faces that share the vertex to use that single wedge? This way you can get rid of discontinuities (although you may not want to...) Any idea if that would look any good?! -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: 20 February 2003 16:47 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. Hoppe's concept of "wedges" is what most of us think of as a "vertex", i.e. psoition, normal, UVs, etc all rolled into one object. The way I do stuff is that you don't store verts/wedges, you store a bunch of vertices with duplicate positions, and store notes between all of them that they're "proximal" (it's just a circular linked list, each vertex points to the next). I never try to find "optimal midpoints" at all. They usually don't improve the image quality significantly, and they completely break any VIPM scheme you have going on. Just pick one the of vertices to bin, and collapse it onto the other one. Keeps things simple. The range of collapses that can be performed with proximal verts is very limited, as you've discovered. Basically, the operations that can be performed are: -Any non-prox vert can be collapsed onto a vert with proxes. -Any vertex (V1) that has exactly one prox vert (call it Vp1) can be collapsed onto a vertex (V2) with a proximal vertex (Vp2) _that shares a triangle edge with Vp1_. Because then you can work out how to pair them up. And that's it. Any other collapses lead you scratching your head wondering how to calculate the error metric and how to match texture coordinates up. It does mean artists have to be careful about the number of seams they have in models, because although collapses can be done _along_ seams, you can't ever get rid of seams. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andrew Vidler [mailto:av...@in...] > Sent: 20 February 2003 16:27 > To: gda...@li... > Subject: [Algorithms] Mesh Decimation with Attributes. > > > Hi, > > I'm currently trying to implement a mesh decimation system based on > error-quadrics, specifically, those defined in "New Quadric Error > Metric for Simplifying Meshes with Appearance Attributes" by Hughes > Hoppe. I'm using the mesh representation from the paper, i.e. you have > lists of vertices, wedges and triangles, each triangles holds indices > to 3 wedges, each wedge holds an index to a vertex. A vertex is just a > position while a wedge contains all the attribute information, normal, > colour, uvs etc... > > I completely understand the basic system described in most of the > papers, where you just have a position to worry about, but I'm getting > a bit stuck working out where the wedges might fit in... > > As I understand it, a solving a quadric will give you an approximation > to the optimal (in some sense) position and set of attributes for the > vertex that you are collapsing an edge to. But...If, as is quite often > the case, I have multiple wedges surrounding > a vertex pair that I want to contract, solving the relevant quadric > gives me a vertex position and attribs (essentially a vertex and a > wedge). This implies that the new vertex has only one wedge, yet > before I contracted the vertex pair, they might have had many > different wedges? > > Hope that's clear - not sure how else to describe it!! > > What am I doing/thinking wrong? > > TIA, > > Andrew Vidler. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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: Jon W. <hp...@mi...> - 2003-02-20 17:45:39
|
> I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I guess the > option might be nice... I've found that for discrete LODs, artists are much better at deciding where a new texture or new mapping is needed, than computers. Personally I view auto-collapse and/or VIPM as useful for meshes that are substantially richer in vertices than in material boundaries. If this is for a tool for mesh creation, then could you consider outputting only vertices with position, no mapping channels? That'd significantly simplify the problem :-) Cheers, / h+ |
From: Andrew V. <av...@in...> - 2003-02-20 17:58:45
|
I think the meshes are fairly rich in "normal" vertices, i.e. those with only one wedge/attribute set. But I'd really like to try and have a consistent framework that works for everything and not just for these vertices, but it doesn't seem like I'm going to find one, oh well - I guess disallowing certain collapes makes things easier anyway :) -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Jon Watte Sent: 20 February 2003 17:44 To: gda...@li... Subject: RE: [Algorithms] Mesh Decimation with Attributes. > I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I guess > the option might be nice... I've found that for discrete LODs, artists are much better at deciding where a new texture or new mapping is needed, than computers. Personally I view auto-collapse and/or VIPM as useful for meshes that are substantially richer in vertices than in material boundaries. If this is for a tool for mesh creation, then could you consider outputting only vertices with position, no mapping channels? That'd significantly simplify the problem :-) Cheers, / h+ ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ 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: Paul F. <pf...@at...> - 2003-02-20 17:57:46
|
> I don't really need a VIPM scheme, just something that generates > discrete lods - the lods don't have to be related, although I guess the > option might be nice... Especially because your discrete LOD's would then simply become different index lists into the same set of vertices. Cheers, Paul. |