CGAL users discussion list

["Laurent Rineau (CGAL/GeometryFactory)" <>]

Le Wednesday 17 June 2015 12:28:08 Phil Weir a écrit :
> A very late follow on, but just wanted to ping the list to express
> thanks for Laurent's input on 3D meshing in discussion at the FEniCS
> workshop last year (Paris). For a number of reasons, we have only just
> finished incorporating his suggestion today, but have noticed a
> significant improvement.

Thanks.

> In summary: as part of the Go-Smart EU-FP7 project,

For information, for the other readers: http://www.gosmart-project.eu/

> we are doing
> polyhedral meshing prior to Elmer simulation - this may be relevant to a
> couple of earlier posts this week, e.g. 'Best approach to create
> Mesh_Domain_3 from multiple Polyhedral_3' and 3D-mesh creation
> (Mesh_complex_3_in_triangulation_3) from *multiple* polyhedral surface
> meshes...'. It sounds like Jane's suggestion has covered the use-case
> there, but if intersection is required, such as in our case, I think
> Polyhedral_mesh_domain_3 would need some wrapping, at least (if I
> understand the documentation and remember previous experience correctly?).

I agree. Since the beginnings of Mesh_3, I have modified a lot the class 
templates Polyhedral_mesh_domain_3 and 
Polyhedral_mesh_domain_with_features_3, 
but several features of them are not documented, because:
  - either a lack of time,
  - or because I am not really satisfied by the experimental API I have added,
  - or because I know that the API cannot be compatible with the new Surface 
Mesh data structure that is slowly deprecating Polyhedron_3:
   http://doc.cgal.org/latest/Surface_mesh/


Both Polyhedral_mesh_domain_3 and Polyhedral_mesh_domain_with_features_3 can 
take in their constructors:
  - a range of polyhedra,
  - and a special polyhedron that will be the only one relevant for the 
Is_in_domain_3 functor.

If you want to use that on Polyhedral_mesh_domain_with_features_3, then you 
must iterate on the polyhedra, and call for each that method of 
Polyhedral_mesh_domain_with_features_3:

  void detect_features(FT angle_in_degree, Polyhedron& p);

BUT! that will certainly lead to crashes if the collection of polyhedra do 
intersect, of if their featured edges are locally very close to each other.


You have also discovered that the IDs returned by the Construct_intersection 
sub-functor of the domain can be related to the patch_id() function of the 
facets of the polyhedra. That allows to have different labels for surface-
patches of the output mesh.

What is missing currently in those undocumented featured:

  - Handling of intersections (and that is a difficult subject, I can tell!),

  - And a way to have multiple sub-domain indices from a collection of 
polyhedra. I have somewhere in Git a class that allows that for a collection 
of non-intersecting closed polyhedra, but here again that would crash if the 
polyhedra intersect or are close to each other.

So those features have remained in my TODO-list for years... From time to 
time 
I try to improve the situation. For example, a lot of those undocumented 
features were not even in the distribution of CGAL before version CGAL-4.3.

> Originally, we loaded STLs as Polyhedra, converted to Nef Polyhedra and
> performed a series of Boolean operations, before converting back to a
> domain Polyhedron and meshing. However, this was very slow and the
> polyhedra requirements are quite restrictive, especially for converting
> a Nef Polyhedron to the final domain polyhedron. Instead, we switched to
> a Labeled_mesh_domain_3, using Point_in_polyhedron calls - this was much
> faster, flexible and more robust, providing subdomain labelling (for MSH
> output), effectively free.

Indeed. For the moment, domains using Labeled_mesh_domain_3 are the only easy 
way to have subdomains (with their own labels) in Mesh_3. Mixed with 
Polyhedral_mesh_domain_with_features_3 one can implement hybrid domain 
classes, that use for example the bounding box as Polyhedron_3, to have a 
nice 
meshing of the outer box, and use Labeled_mesh_domain_3 for the inside of the 
domain. I can show you such an hybrid domain.

> However, labelling output boundaries by the original STL was harder -
> Laurent's tip to re-use surface patches, which are actually filled by
> the domain oracle (as I hadn't spotted!), made it far more efficient. We
> combine this with a subclass (Signed_mesh_domain_3) that simply
> overrides the Is_in_domain struct, allowing the labelling function to
> return negative indices for external points. Negative return values are
> preserved in the surface patch for future reference (at MSH output
> time). The simulation component of this project is being open sourced
> (including the CGAL-based meshing tool), although the tools are being
> finished, tidied and documented over the course of this year (and are
> still based on CGAL-4.3/4) - nonetheless, I hope this provides some
> useful feedback for the moment.

Your feedback is interesting. I really enjoyed meeting your group at the 
FEniCS workshop, because it is at the same time exciting and challenging to 
meet users of Mesh_3.


Do you think that some of your implementation is generic enough that it could 
be contributed to CGAL?


Best regards,

Laurent

-- 
Laurent Rineau, PhD
R&D Engineer at GeometryFactory           http://www.geometryfactory.com/
Release Manager of the CGAL Project       http://www.cgal.org/