

Dear all,
I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3?
On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere?
Best,
Marc

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


Hi Marc,
Did you try to dump c3t3.triangulation()? AFAIK, this should directly
call the operator<<() from Regular_triangulation_3 and gives you what
you need. I guess you could even down cast it to a given Triangulation_3
class.
If you need to import it into a different triangulation type, you have
to do it at the TDS level by using the function copy_tds() for example.
See here:
https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89HTH,
Sebastien.
On 01/05/2019 01:53 PM, Marc Alexa wrote:
> Dear all,
>
> I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3?
>
> On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere?
>
> Best,
> Marc
>
>
>
>

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


Hi Sebastian,
Thanks for your answer. I use the stream operator on both, c3t3 and c3t3.triangulation and the result is identical.
I was never able to downcast. I somehow don’t manage to use types that CGAL understand to cast. The copy_tds function looks interesting. For now I solved my problem in a more ugly way by directly filtering the stream generated by c3t3.
My other problem remains. c3t3 uses some peeling, but the peeled tets are part of the triangulation so they still get exported.
I guess, fundamentally I need to solve the following problem: given a collection of tets that form a valid tet mesh with boundary. How can I generate the ‘outside’ tets that CGAL expects for Triangulation 3, i.e. the tets connected to the infinite vertex. Is there a simple way in CGAL to do this?
Thanks!
Marc
> On 7. Jan 2019, at 08:47, Sebastien Loriot (GeometryFactory) < [hidden email]> wrote:
>
> Hi Marc,
>
> Did you try to dump c3t3.triangulation()? AFAIK, this should directly
> call the operator<<() from Regular_triangulation_3 and gives you what
> you need. I guess you could even down cast it to a given Triangulation_3
> class.
>
> If you need to import it into a different triangulation type, you have
> to do it at the TDS level by using the function copy_tds() for example.
>
> See here:
> https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89>
> HTH,
>
> Sebastien.
>
> On 01/05/2019 01:53 PM, Marc Alexa wrote:
>> Dear all,
>> I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3?
>> On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere?
>> Best,
>> Marc
>
> 
> You are currently subscribed to cgaldiscuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgaldiscuss>
>

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


Here is an example of usage of copy_tds():
https://gist.github.com/sloriot/f9f929ce2e30b59f1b63a3cf3780159eAre talking of filtering infinite cells?
Sebastien.
On 01/09/2019 10:25 PM, Marc Alexa wrote:
> Hi Sebastian,
>
> Thanks for your answer. I use the stream operator on both, c3t3 and c3t3.triangulation and the result is identical.
>
> I was never able to downcast. I somehow don’t manage to use types that CGAL understand to cast. The copy_tds function looks interesting. For now I solved my problem in a more ugly way by directly filtering the stream generated by c3t3.
>
> My other problem remains. c3t3 uses some peeling, but the peeled tets are part of the triangulation so they still get exported.
>
> I guess, fundamentally I need to solve the following problem: given a collection of tets that form a valid tet mesh with boundary. How can I generate the ‘outside’ tets that CGAL expects for Triangulation 3, i.e. the tets connected to the infinite vertex. Is there a simple way in CGAL to do this?
>
> Thanks!
> Marc
>
>
>
>> On 7. Jan 2019, at 08:47, Sebastien Loriot (GeometryFactory) < [hidden email]> wrote:
>>
>> Hi Marc,
>>
>> Did you try to dump c3t3.triangulation()? AFAIK, this should directly
>> call the operator<<() from Regular_triangulation_3 and gives you what
>> you need. I guess you could even down cast it to a given Triangulation_3
>> class.
>>
>> If you need to import it into a different triangulation type, you have
>> to do it at the TDS level by using the function copy_tds() for example.
>>
>> See here:
>> https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89>>
>> HTH,
>>
>> Sebastien.
>>
>> On 01/05/2019 01:53 PM, Marc Alexa wrote:
>>> Dear all,
>>> I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3?
>>> On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere?
>>> Best,
>>> Marc
>>
>> 
>> You are currently subscribed to cgaldiscuss.
>> To unsubscribe or access the archives, go to
>> https://sympa.inria.fr/sympa/info/cgaldiscuss>>
>>
>
>

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


Thank you so much! The code runs fine. But my main problem remains: the triangulation in c3t3.triangulation contains more cells than the interior triangulation of the object.
If you add the lines
std::cerr << "Number of cells in c3t3: " << c3t3.number_of_cells() << std::endl; std::cerr << "Number of finite cells in t: " << t.number_of_finite_cells() << std::endl;
to your code you see. this. I had hoped if I take a convex surface there would be no difference, because there is no necessity for tetrahedra on the outside, but this is still not true. If you create a mesh for a sphere, the numbers will still be different.
What I would really like to do is to export the tetrahedral mesh that is in the interior of the object — the number of tetrahedra c3t3 reports. I could of course iterate over these tetrahedra, but this does not give me a valid Triangulation_3 object, because it expects a triangulation without boundary faces; rather the boundary faces are incident on tetrahedra with one vertex at infinity. So my question is how to easily create a Triangulation_3 object that captures what c3t3 intends to represent?
Best, Marc
On 10. Jan 2019, at 07:16, Sebastien Loriot (GeometryFactory) < [hidden email]> wrote:
Here is an example of usage of copy_tds(): https://gist.github.com/sloriot/f9f929ce2e30b59f1b63a3cf3780159eAre talking of filtering infinite cells? Sebastien. On 01/09/2019 10:25 PM, Marc Alexa wrote: Hi Sebastian, Thanks for your answer. I use the stream operator on both, c3t3 and c3t3.triangulation and the result is identical. I was never able to downcast. I somehow don’t manage to use types that CGAL understand to cast. The copy_tds function looks interesting. For now I solved my problem in a more ugly way by directly filtering the stream generated by c3t3. My other problem remains. c3t3 uses some peeling, but the peeled tets are part of the triangulation so they still get exported. I guess, fundamentally I need to solve the following problem: given a collection of tets that form a valid tet mesh with boundary. How can I generate the ‘outside’ tets that CGAL expects for Triangulation 3, i.e. the tets connected to the infinite vertex. Is there a simple way in CGAL to do this? Thanks! Marc
On 7. Jan 2019, at 08:47, Sebastien Loriot (GeometryFactory) <[hidden email]> wrote:
Hi Marc,
Did you try to dump c3t3.triangulation()? AFAIK, this should directly call the operator<<() from Regular_triangulation_3 and gives you what you need. I guess you could even down cast it to a given Triangulation_3 class.
If you need to import it into a different triangulation type, you have to do it at the TDS level by using the function copy_tds() for example.
See here: https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89
HTH,
Sebastien.
On 01/05/2019 01:53 PM, Marc Alexa wrote:
Dear all, I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3? On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere? Best, Marc
 You are currently subscribed to cgaldiscuss. To unsubscribe or access the archives, go to https://sympa.inria.fr/sympa/info/cgaldiscuss
 You are currently subscribed to cgaldiscuss. To unsubscribe or access the archives, go to https://sympa.inria.fr/sympa/info/cgaldiscuss


Looking at the medit output from your example, something that reads an medit file and creates a Triangulation_3 from it would do the trick.
Marc
Thank you so much! The code runs fine. But my main problem remains: the triangulation in c3t3.triangulation contains more cells than the interior triangulation of the object.
If you add the lines
std::cerr << "Number of cells in c3t3: " << c3t3.number_of_cells() << std::endl; std::cerr << "Number of finite cells in t: " << t.number_of_finite_cells() << std::endl;
to your code you see. this. I had hoped if I take a convex surface there would be no difference, because there is no necessity for tetrahedra on the outside, but this is still not true. If you create a mesh for a sphere, the numbers will still be different.
What I would really like to do is to export the tetrahedral mesh that is in the interior of the object — the number of tetrahedra c3t3 reports. I could of course iterate over these tetrahedra, but this does not give me a valid Triangulation_3 object, because it expects a triangulation without boundary faces; rather the boundary faces are incident on tetrahedra with one vertex at infinity. So my question is how to easily create a Triangulation_3 object that captures what c3t3 intends to represent?
Best, Marc
On 10. Jan 2019, at 07:16, Sebastien Loriot (GeometryFactory) < [hidden email]> wrote:
Here is an example of usage of copy_tds(): https://gist.github.com/sloriot/f9f929ce2e30b59f1b63a3cf3780159eAre talking of filtering infinite cells? Sebastien. On 01/09/2019 10:25 PM, Marc Alexa wrote: Hi Sebastian, Thanks for your answer. I use the stream operator on both, c3t3 and c3t3.triangulation and the result is identical. I was never able to downcast. I somehow don’t manage to use types that CGAL understand to cast. The copy_tds function looks interesting. For now I solved my problem in a more ugly way by directly filtering the stream generated by c3t3. My other problem remains. c3t3 uses some peeling, but the peeled tets are part of the triangulation so they still get exported. I guess, fundamentally I need to solve the following problem: given a collection of tets that form a valid tet mesh with boundary. How can I generate the ‘outside’ tets that CGAL expects for Triangulation 3, i.e. the tets connected to the infinite vertex. Is there a simple way in CGAL to do this? Thanks! Marc
On 7. Jan 2019, at 08:47, Sebastien Loriot (GeometryFactory) <[hidden email]> wrote:
Hi Marc,
Did you try to dump c3t3.triangulation()? AFAIK, this should directly call the operator<<() from Regular_triangulation_3 and gives you what you need. I guess you could even down cast it to a given Triangulation_3 class.
If you need to import it into a different triangulation type, you have to do it at the TDS level by using the function copy_tds() for example.
See here: https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89
HTH,
Sebastien.
On 01/05/2019 01:53 PM, Marc Alexa wrote:
Dear all, I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3? On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface. I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere? Best, Marc
 You are currently subscribed to cgaldiscuss. To unsubscribe or access the archives, go to https://sympa.inria.fr/sympa/info/cgaldiscuss
 You are currently subscribed to cgaldiscuss. To unsubscribe or access the archives, go to https://sympa.inria.fr/sympa/info/cgaldiscuss


Hello,
Depending on your usage of the triangulation afterwards (more
details below), you can look into this file https://github.com/CGAL/cgal/blob/master/Mesh_3/include/CGAL/Mesh_3/tet_soup_to_c3t3.h,
and use functions such as "build_triangulation_from_file", which
take a .mesh and build a triangulation.
BUT: this triangulation is built manually; the cells are created
onebyone and infinite cells are added when there is a facet with
only a single incident finite cell. Thus, even if your input tet
soup is not convex, you will get a combinatorially valid
triangulation. However, a lot of functions in the triangulation
classes assume that the triangulation is a partition of the convex
hull, e.g the location function and everything that uses that
(insertion, removal, etc.), and they are likely to break if used
on a triangulation built that way.
Best,
Mael
On 10/01/2019 09:33, Marc Alexa wrote:
Looking at the medit output from your example, something that
reads an medit file and creates a Triangulation_3 from it would do
the trick.
Marc
Thank
you so much! The code runs fine. But my main problem
remains: the triangulation in c3t3.triangulation
contains more cells than the interior triangulation of
the object.
If you add the lines
std::cerr << "Number of cells in c3t3: "
<< c3t3.number_of_cells() << std::endl;
std::cerr << "Number of finite cells in t: "
<< t.number_of_finite_cells() <<
std::endl;
to your code you see. this. I had hoped
if I take a convex surface there would be no
difference, because there is no necessity for
tetrahedra on the outside, but this is still not
true. If you create a mesh for a sphere, the numbers
will still be different.
What I would really like to do is to
export the tetrahedral mesh that is in the interior
of the object — the number of tetrahedra c3t3
reports. I could of course iterate over these
tetrahedra, but this does not give me a valid
Triangulation_3 object, because it expects a
triangulation without boundary faces; rather the
boundary faces are incident on tetrahedra with one
vertex at infinity. So my question is how to easily
create a Triangulation_3 object that captures what
c3t3 intends to represent?
Best,
Marc
On 10. Jan 2019, at 07:16, Sebastien
Loriot (GeometryFactory) < [hidden email]>
wrote:
Here is an example of usage of
copy_tds():
https://gist.github.com/sloriot/f9f929ce2e30b59f1b63a3cf3780159e
Are talking of filtering infinite cells?
Sebastien.
On 01/09/2019 10:25 PM, Marc Alexa wrote:
Hi Sebastian,
Thanks for your answer. I use the stream
operator on both, c3t3 and
c3t3.triangulation and the result is
identical.
I was never able to downcast. I somehow
don’t manage to use types that CGAL
understand to cast. The copy_tds function
looks interesting. For now I solved my
problem in a more ugly way by directly
filtering the stream generated by c3t3.
My other problem remains. c3t3 uses some
peeling, but the peeled tets are part of the
triangulation so they still get exported.
I guess, fundamentally I need to solve the
following problem: given a collection of
tets that form a valid tet mesh with
boundary. How can I generate the ‘outside’
tets that CGAL expects for Triangulation 3,
i.e. the tets connected to the infinite
vertex. Is there a simple way in CGAL to do
this?
Thanks!
Marc
On 7. Jan
2019, at 08:47, Sebastien Loriot
(GeometryFactory) <[hidden email]>
wrote:
Hi Marc,
Did you try to dump c3t3.triangulation()?
AFAIK, this should directly
call the operator<<() from
Regular_triangulation_3 and gives you what
you need. I guess you could even down cast
it to a given Triangulation_3
class.
If you need to import it into a different
triangulation type, you have
to do it at the TDS level by using the
function copy_tds() for example.
See here:
https://doc.cgal.org/latest/TDS_3/classTriangulationDataStructure__3.html#aac784b676421bd590612bb08c0a84f89
HTH,
Sebastien.
On 01/05/2019 01:53 PM, Marc Alexa wrote:
Dear all,
I am generating a tetrahedral mesh using
the suite of algorithms in Mesh_3. I
want to use the resulting mesh in my
code, which is based on Triangulation_3.
The vertex and cell base classes are
incompatible. My preferred way for doing
this would be writing the mesh to a
file. Unfortunately, the formats of the
stream operators are different. Is there
an easy way to “reduce” what is being
written by Mesh_3 to what is being
expected by Triangulation_3?
On a side note: I understand that if I
am not using sliver exudation, the
triangulation generated by Mesh_3 will
be Delaunay. This means I could export
the points only (and then reconstruct
the tetrahedra). Then I only need
information on which tetrahedra are in
the interior of the meshed surface. I
tried to circumvent this by using a
simple convex surface, namely a sphere.
Yet even for the sphere some tetrahedra
are excluded, despite clearly lying in
the interior. I do understand that the
excluded tetrahedra are slivers, but
wouldn’t it make sense that a
tetrahedral mesh with the boundary
vertices on the sphere contained
everything inside the sphere?
Best,
Marc

You are currently subscribed to
cgaldiscuss.
To unsubscribe or access the archives, go
to
https://sympa.inria.fr/sympa/info/cgaldiscuss

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


On Saturday, January 5, 2019 1:53:50 PM CET Marc Alexa wrote:
> Dear all,
>
> I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3.
> I want to use the resulting mesh in my code, which is based on
> Triangulation_3. The vertex and cell base classes are incompatible. My
> preferred way for doing this would be writing the mesh to a file.
> Unfortunately, the formats of the stream operators are different. Is there
> an easy way to “reduce” what is being written by Mesh_3 to what is being
> expected by Triangulation_3?
>
> On a side note: I understand that if I am not using sliver exudation, the
> triangulation generated by Mesh_3 will be Delaunay. This means I could
> export the points only (and then reconstruct the tetrahedra). Then I only
> need information on which tetrahedra are in the interior of the meshed
> surface.
Hi Marc,
Note that the trianguation is not a Delaunay triangulation, but a *weighted*
Delaunay triangulation (call a regular triangulation). If your mesh domain
does not have 1D featured curves, then all the weights will be 0, and then
only the triangulation is equivalent to a Delaunay triangulation. (And as soon
as you use the sliver exuder, then the nonzero weights reappear.)
> I tried to circumvent this by using a simple convex surface,
> namely a sphere. Yet even for the sphere some tetrahedra are excluded,
> despite clearly lying in the interior. I do understand that the excluded
> tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh
> with the boundary vertices on the sphere contained everything inside the
> sphere?
I agree that could be surprising, but that is not the definition of the
Delaunay triangulation restricted to the mesh domain.

Laurent Rineau, PhD
R&D Engineer at GeometryFactory http://www.geometryfactory.com/Release Manager of the CGAL Project http://www.cgal.org/
You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


On Thursday, January 10, 2019 9:25:39 AM CET Marc Alexa wrote:
> Thank you so much! The code runs fine. But my main problem remains: the
> triangulation in c3t3.triangulation contains more cells than the interior
> triangulation of the object.
>
> If you add the lines
>
> std::cerr << "Number of cells in c3t3: " << c3t3.number_of_cells() <<
> std::endl; std::cerr << "Number of finite cells in t: " <<
> t.number_of_finite_cells() << std::endl;
>
> to your code you see. this. I had hoped if I take a convex surface there
> would be no difference, because there is no necessity for tetrahedra on the
> outside, but this is still not true. If you create a mesh for a sphere, the
> numbers will still be different.
There is no valid solution to that problem, unless your own `Triangulation_3`
type keeps a Boolean field for each cell, indicating whether or not the cell
is part of the mesh.
When the cell converter must be wrote that way:
Cell_converter
{
Triangulation::Cell operator()(const C3t3::Triangulation::Cell& input_cell)
const {
Triangulation::Cell output_cell;
output_cell.is_in_domain = ( input_cell.subdomain_index() != 0 );
return output_cell;
}
void operator()(const C3t3::Triangulation::Cell&,Triangulation::Cell&) const
{}
};

Laurent Rineau, PhD
R&D Engineer at GeometryFactory http://www.geometryfactory.com/Release Manager of the CGAL Project http://www.cgal.org/
You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


In reply to this post by Laurent Rineau (CGAL/GeometryFactory)
Hi Laurent,
thanks for the clarification about the weights. I’m not using sharp features so I should be fine.
So what is the definition of restricted Delaunay? That the circumcenter needs to be part of the domain? That would explain why sliver on the boundary are not part of the triangulation.
Thanks! Marc
On 11. Jan 2019, at 11:06, Laurent Rineau (CGAL/GeometryFactory) < [hidden email]> wrote:
On Saturday, January 5, 2019 1:53:50 PM CET Marc Alexa wrote:Dear all,
I am generating a tetrahedral mesh using the suite of algorithms in Mesh_3. I want to use the resulting mesh in my code, which is based on Triangulation_3. The vertex and cell base classes are incompatible. My preferred way for doing this would be writing the mesh to a file. Unfortunately, the formats of the stream operators are different. Is there an easy way to “reduce” what is being written by Mesh_3 to what is being expected by Triangulation_3?
On a side note: I understand that if I am not using sliver exudation, the triangulation generated by Mesh_3 will be Delaunay. This means I could export the points only (and then reconstruct the tetrahedra). Then I only need information on which tetrahedra are in the interior of the meshed surface.
Hi Marc,Note that the trianguation is not a Delaunay triangulation, but a *weighted* Delaunay triangulation (call a regular triangulation). If your mesh domain does not have 1D featured curves, then all the weights will be 0, and then only the triangulation is equivalent to a Delaunay triangulation. (And as soon as you use the sliver exuder, then the nonzero weights reappear.)I tried to circumvent this by using a simple convex surface, namely a sphere. Yet even for the sphere some tetrahedra are excluded, despite clearly lying in the interior. I do understand that the excluded tetrahedra are slivers, but wouldn’t it make sense that a tetrahedral mesh with the boundary vertices on the sphere contained everything inside the sphere?
I agree that could be surprising, but that is not the definition of the Delaunay triangulation restricted to the mesh domain. Laurent Rineau, PhDR&D Engineer at GeometryFactory http://www.geometryfactory.com/Release Manager of the CGAL Project http://www.cgal.org/ You are currently subscribed to cgaldiscuss.To unsubscribe or access the archives, go tohttps://sympa.inria.fr/sympa/info/cgaldiscuss


In reply to this post by Laurent Rineau (CGAL/GeometryFactory)
> On 11. Jan 2019, at 11:20, Laurent Rineau (CGAL/GeometryFactory) < [hidden email]> wrote:
>
>>
>
> There is no valid solution to that problem, unless your own `Triangulation_3`
> type keeps a Boolean field for each cell, indicating whether or not the cell
> is part of the mesh.
I wrote my own solution and I realized this. It seems the domain boundary need not be manifold.
If I used the converter as you indicated below, would it add tetrahedra with an infinite vertex during the conversion?
Thanks!
Marc
>
> When the cell converter must be wrote that way:
>
> Cell_converter
> {
> Triangulation::Cell operator()(const C3t3::Triangulation::Cell& input_cell)
> const {
> Triangulation::Cell output_cell;
> output_cell.is_in_domain = ( input_cell.subdomain_index() != 0 );
> return output_cell;
> }
>
> void operator()(const C3t3::Triangulation::Cell&,Triangulation::Cell&) const
> {}
> };
>
>
>
> 
> Laurent Rineau, PhD
> R&D Engineer at GeometryFactory http://www.geometryfactory.com/> Release Manager of the CGAL Project http://www.cgal.org/>
>
>
>
> 
> You are currently subscribed to cgaldiscuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgaldiscuss>
>

You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss


On Friday, January 11, 2019 5:14:17 PM CET Marc Alexa wrote:
> > On 11. Jan 2019, at 11:20, Laurent Rineau (CGAL/GeometryFactory)
> > < [hidden email]> wrote:
> >
> >
> >
> > There is no valid solution to that problem, unless your own
> > `Triangulation_3` type keeps a Boolean field for each cell, indicating
> > whether or not the cell is part of the mesh.
>
> I wrote my own solution and I realized this. It seems the domain boundary
> need not be manifold.
>
> If I used the converter as you indicated below, would it add tetrahedra with
> an infinite vertex during the conversion?
copy_tds will copy all the tetrahedra, including:
 finite tetrahedra in the domain,
 finite tetrahedra outside the domain,
 and infinite tetrahedra.
Of course, the infinite tetrahedra will always have 'subdomain_index()==0'
(meaning "outside the domain").

Laurent Rineau, PhD
R&D Engineer at GeometryFactory http://www.geometryfactory.com/Release Manager of the CGAL Project http://www.cgal.org/
You are currently subscribed to cgaldiscuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgaldiscuss

