CGAL users discussion list

[Richard Downe <>]

Couldn't get it to work right manipulating the iterators directly, but I took your original advice, used the triangulated surface mesh simplification stuff (I used the edge_length cost, and set the stopping condition to 0.99*nEdges).

This completely eliminates the degenerate triangles I had with coincident points (I'm able to feed the .off intermediate output into my program for building STL files without errors/zero-valued normals being detected).

Unfortunately, this surface is still stubbornly refusing remeshing.  I've attached a dropbox link to the .off output (post-surface simplification, pre-remeshing) on the off chance that something about it might catch your eye.

(The really long edges at the flow extensions are not my doing -- these invariably appear *post* Nef_polyhedron.)

Thanks.
-rd

http://dl.dropbox.com/u/66958528/cgal.off

On 10/24/2012 08:22 AM, Sebastien Loriot (GeometryFactory) wrote:

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