CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

On 10/24/2012 03:18 PM, Richard Downe wrote:
> I'll take a look at that.
> Last night I wrote a fairly basic block of code that followed the
> halfedge_iterator from halfedge_begin() to halfedge_end(), calling
> join_vertex() any time the squared distance between two was smaller than
> numeric_limits<float>::epsilon().
> It did a fine job of pruning degenerate edges, but never converged (spit
> out a list of a dozen or so pruned edges, but ran all night at 100% cpu
> with no change in memory usage).
>
> So my assumption is that by calling join_vertex on a running loop I'm
> breaking something, or these iterators never converge somehow. Am I
> doing this wrong?
I guess the iterator became invalid. Joining two vertices means deleting 
a pair of halfedges.
If you ++ the iterator before joining it should be fine as the 
underlying data structure is a list by default.

Note that you might need to do this loop several time as you could have 
cascaded collapse with such a method.

Sebastien.

> -rd
>
> On 10/24/2012 02:16 AM, Sebastien Loriot (GeometryFactory) wrote:
> > You can try using the edge simplification algorithm [1]
> > There is an example given in this thread (second post) [2]
> >
> > Let us know if this does not solve the problem.
> >
> > Sebastien.
> >
> > [1]
> > http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Surface_mesh_simplification/Chapter_main.html
> >
> > [2]
> > http://cgal-discuss.949826.n4.nabble.com/understanding-edge-collapse-tt3248855.html
> >
> >
> > On 10/24/2012 01:51 AM, Richard Downe wrote:
> > > I have a program that uses Nef_Polyhedron_3 to merge several disjoint
> > > structured grids, and then remeshes the surface using a delaunay
> > > triangulation. Out of several surfaces I'm preparing, one has stubbornly
> > > refused to mesh. After a day or so of tweaking the parameters, I
> > > generated .off files to permit me to visualize the intermediate surface
> > > and troubleshoot.
> > >
> > > In examining the .off version of the troublesome surface, I noticed that
> > > there are several degenerate triangles (e.g., 2 coincident vertices, and
> > > therefore a zero-valued normal). I'm assuming this has to do with
> > > distances in the EPECK kernel that are too small to represent in the
> > > EPICK kernel, which therefore get rounded off.
> > >
> > > My question is this: does a filter exist which can remove these
> > > triangles *prior* to casting the polyhedron to an EPICK kernel? Or am I
> > > on my own (e.g., either filtering the inexact kernel version and simply
> > > erasing the degenerate triangles, or alternately, filtering the exact
> > > one and merging any triangle with a sufficiently high aspect ratio with
> > > an adjacent triangle in the hopes of avoiding degeneracy post-cast)?
> > >
> > > Any help would be very much appreciated.
> > >
> > > -Richard