CGAL users discussion list

[jpanetta <>]

1) I determined what triggered the assertion: an inconsistent floating point
roundoff in my feature curve generation code caused two endpoints that
should intersect to sometimes have coordinates differing by 1 bit. This led
to an integer overflow in CGAL/Mesh_3/Protect_edges_sizing_field.h:936 (in
insert_balls):

int n = static_cast<int>(std::floor(FT(2)*(d-sq) / (sp+sq))+.5);

because sp and sq were nearly zero. After fixing my curve generation so that
all intersections are exact, the protecting ball insertion succeeds.

2) In the cases that "hang" (when edge_size criterion falls below a
particular feature-curve-dependent threshold), CGAL is running surface
intersection queries on segments whose targets are *way* outside the
domain's bounding sphere (targets with components ~1e9 despite the bounding
sphere's radius of ~1). My signed distance function was very slow to
evaluate points far away from the origin. When I sped up my distance
evaluation in this case, the hang no longer happens.

This far-off sampling surprises me and seems inefficient--in all cases, it
appears CGAL samples points with components ~1e4). It also puzzles me that
this distance abruptly increases when edge_size falls below a particular
threshold.

Could someone please comment on whether this sampling is expected behavior?
Since the user is required to specify a valid bounding sphere containing the
geometry when creating an Implicit_mesh_domain_3, I don't see why it's
necessary.

Thanks,
Julian



--
View this message in context: 
http://cgal-discuss.949826.n4.nabble.com/Some-3D-Mesh-Generation-Problems-Sharp-Features-tp4660976p4661003.html
Sent from the cgal-discuss mailing list archive at Nabble.com.