CGAL users discussion list

[Benjamin Kehlet <>]

Thanks! I have a working solution now (but it needs some more polishing).

I basically made my own domain class which reimplemts the
construct_initial_points(). The main part can be outlined as this:

// 
----------------------------------------------------------------------------
template< typename IGT_ >
class Polyhedral_multicomponent_mesh_domain_with_features_3
  : public CGAL::Polyhedral_mesh_domain_with_features_3< IGT_ >
{

  struct Construct_initial_points
  {
    template<class OutputIterator>
    OutputIterator operator()(OutputIterator pts, const int n = 8) const
    {
      // Generate surface points from all disconnected components
sufficiently spread over the surface
      [...]
    }
  };

  Construct_initial_points construct_initial_points_object() const;
};
// 
------------------------------------------------------------------------------

I also had make my own
C3t3 make_multicomponent_mesh_impl( [usual arguments to make_mesh_impl()] );

since make_mesh() does not always call construct_initial_points().

Overall, do you think this design looks reasonable or are there
smarter ways to do this?

One last question:
Construct_initial_points(OutpitIterator) should output
std::pair<Point_3, Index>. This index seems to be documented as "the
index of the lowest dimensional face of the input 3D complex." Is this
index just to be able to connect vertices in the input polyhedron to
vertices in the resulting mesh? Are they used during the mesh
generation? Do they have to be unique?

Benjamin

2014-07-22 11:41 GMT+02:00 Andreas Fabri 
<>:
>
> Hi Benjamin,
>
> it should be spread out.
> Note also that this problem might even occur with one connected
> component.
>
>   -------------  ----------------
>   |            ||               |
>   |            ||               |
>   |           /  \              |
>   |          |____|             |
>   |                             |
>   |                             |
>   |                             |
>   |_____________________________|
>
> If the channel that connects the cavity with the rest
> is extremely narrow it might happen that the algorithm
> never detects the channel and the cavity.
>
> andreas
>
>
> On 18/07/2014 13:07, Benjamin Kehlet wrote:
>>
>>
>> Ah, I see. Thanks!
>>
>> I will try to come with an implementation of
>> Construct_initial_points() that makes sure all components are
>> represented.
>> Is the reason for shooting random rays that the points should be
>> spread out over the surface or could I just pick some points (eg. via
>> the vertex iterator)? (I generally find (bug) reproducability a nice
>> feature :) )
>>
>> Benjamin
>>
>> 2014-07-18 12:00 GMT+02:00 Andreas Fabri
>> <>:
>>>
>>> Hi Benjamin,
>>>
>>> the polyhedral domain class has a function
>>> Polyhedral_mesh_domain::Construct_initial_points
>>>
>>> that provides an intial set of points on the surface.
>>> It currently does this by shooting rays in random
>>> directions from the center of the bounding box.
>>>
>>> When the surface has several connected components
>>> and for a component no intial point is given
>>> it may happen that the mesh generator later
>>> never finds it (by also shooting rays, not random
>>> though).
>>>
>>> What you have to do is to initialize
>>> the Complex_3_in_triangulation_3 with better
>>> points by doing what
>>> Polyhedral_mesh_domain::Construct_initial_points
>>> Mesh_3::init_c3_t3  do.
>>>
>>> If I find the time next week, I will try to provide
>>> an example.
>>>
>>> best,
>>>
>>> andreas
>>>
>>>
>>> On 17/07/2014 01:40, Benjamin Kehlet wrote:
>>>>
>>>>
>>>> Hello CGAL people!
>>>>
>>>> I got a report of some unexpected results in mshr (a mesh generation
>>>> component in the FEniCS project which uses CGAL heavily). I have
>>>> simplified it a bit and reproduced the issue as a standalone CGAL
>>>> program.
>>>>
>>>> When meshing a box with a crude triangulation of a sphere subtracted,
>>>> the sphere is sometimes "missing" in the resulting mesh.
>>>>
>>>> When meshing the polyhedron in smaller.off (which is basically an axis
>>>> aligned box with corners at (-1, -1, -.4) and (1,1,1) with a sphere
>>>> with center at origin and radius .3 subtracted) it works fine. See the
>>>> surface plot of the resulting mesh in smaller.png.
>>>>
>>>> However, with bigger.off (where the first corner is at (-1,-1,-.7) and
>>>> the rest is equal) the inner sphere can not be seen in the plot. See
>>>> bigger.png.
>>>>
>>>> I confirmed that it is not a plotting issue by calculating the volume
>>>> of the mesh. For bigger.off the result is 6.8 which is equal to the
>>>> volume of the box (2*2*1.7). For smaller.off it calculates the volume
>>>> to 5.5223. I assume is the correct solution since it is smaller than
>>>> 5.6 which is the volume of the box (2*2*1.4=5.6). The program source
>>>> code is attached. The issue seems to be insensitive to the meshing
>>>> parameters.
>>>>
>>>> Best regards
>>>>
>>>> Benjamin Kehlet
>>>>
>>>
>>> --
>>> Andreas Fabri, PhD
>>> Chief Officer, GeometryFactory
>>> Editor, The CGAL Project
>>>
>>> phone: +33.492.954.912    skype: andreas.fabri
>>>
>>> --
>>> You are currently subscribed to cgal-discuss.
>>> To unsubscribe or access the archives, go to
>>> https://sympa.inria.fr/sympa/info/cgal-discuss
>>>
>>>
>>
>
> --
> Andreas Fabri, PhD
> Chief Officer, GeometryFactory
> Editor, The CGAL Project
>
> phone: +33.492.954.912    skype: andreas.fabri
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgal-discuss
>
>