CGAL users discussion list

[Giles Puckett <>]

Hi,

Thanks for the suggestion. Can you post a fragment of such an OFF file 
so I can see what it looks like?

It will be hard to change the kernel in the original program, because 
there are a few steps between the mesh and the OFF file writing. But I 
should be able to dig through the exact_points property map per vertex 
and get out the exact coordinates.

What format are the coordinate values in the 
Exact_predicates_exact_constructions_kernel ? (I confess I'm not very 
good with C++ especially with all the heavy template usage)

G.

On 6/02/2020 6:20 pm, Sebastien Loriot (GeometryFactory) wrote:
> If the error occurs after several operations, for debugging purpose 
> you can use CGAL::Simple_cartesian<CGAL::Gmpq> as kernel and I think when
> writing to OFF you will write the exact rational representation.
> Then I think I should be able to load them and reproduce the error.
>
> Note that it will be much slower.
>
> Best,
>
> Sebastien.
>
> PS: don't post output meshes as an attachment to the mailing list as
> the file will be large (use gist.github.com or whatever online storage 
> service).
>
>
> On 2/5/20 10:33 AM, Giles Puckett wrote:
> > Both meshes return true to does_bound_a_volume and false to 
> > does_self_intersect. They do not throw an exception for 
> > self-intersections. I can send the OFF files if you like, although 
> > they don't produce the error they show the shape of the meshes..
> >
> > G.
> >
> > On 5/02/2020 6:23 pm, Sebastien Loriot (GeometryFactory) wrote:
> > > Does one of you mesh has a boundary?
> > >
> > > The list of PRs that could have introduced a regression is here:
> > > https://github.com/CGAL/cgal/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+label%3AMerged_in_4.12.2++label%3APkg%3A%3APMP+ 
> > >
> > >
> > > I don't see anything suspicious. Is it deterministic?
> > >
> > > Best,
> > >
> > > Sebastien.
> > >
> > >
> > >
> > > On 2/4/20 11:59 PM, Giles Puckett wrote:
> > > > Bonjour,
> > > >
> > > > I have a CAD program that uses PMP to merge meshes. I moved from 
> > > > 4.12 to 5.0 in order to use the default visitor to keep attributes 
> > > > on faces through surface mesh unions. However, some previously 
> > > > working meshes now fail with an infinite loop. The problem also 
> > > > appears on 4.14.2.
> > > >
> > > > The infinite loop is in Corefinement::remove_unused_polylines at 
> > > > face_graph_utils.h, line 1634: (in 5.0)
> > > >
> > > > for(vertex_descriptor v: vertices_kept)
> > > >    {
> > > >      halfedge_descriptor h = halfedge(v, tm), 
> > > > start=GT::null_halfedge();
> > > >
> > > >      do{
> > > >        while ( !is_border(h, tm) || is_border(opposite(h, tm), tm) 
> > > > ) // This while loop never exits
> > > >          h = opposite(next(h, tm), tm);
> > > >        halfedge_descriptor in = h;
> > > >        if (start==GT::null_halfedge())
> > > >          start=in;
> > > >        else
> > > >          if (start==in)
> > > >            break;
> > > >        while ( is_border(h, tm) )
> > > >          h = opposite(next(h, tm), tm);
> > > >        set_next(in, opposite(h, tm), tm);
> > > >      }
> > > >      while(true);//this loop handles non-manifold vertices
> > > >    }
> > > >
> > > > One mesh is a simple convex shape, the other is the result of a 
> > > > previous union. All unions are done with exact predicates and 
> > > > constructions in the standard way for consecutive bool ops. Testing 
> > > > for self-intersections before and during the union reveals nothing.
> > > >
> > > > Sadly, I cannot reproduce it in a simple test example program (when 
> > > > writing the meshes to OFF file, precision is lost, and I get 
> > > > self-intersections or an assertion about collinear points). I 
> > > > suspect there may be zero-area triangles produced by the first union.
> > > >
> > > > Three questions:
> > > >
> > > > Have there been any changes in corefinement, PMP or surface meshes 
> > > > between 4.12 and 4.14.2 that might produce this, or any known 
> > > > regressions?
> > > > And is there any way I can write the meshes out with sufficient 
> > > > accuracy to submit a simple test case?
> > > > Lastly, is there any way I can get the functionality of the example 
> > > > program (corefinement_mesh_union_with_attributes) to work in 4.12?
> > > >
> > > > Thanks for any help and for reading on this far :-)
> > > >
> > > > Giles.