Mesh_3 -> Triangulation_3

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Mesh_3 -> Triangulation_3

Marc Alexa
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Sebastien Loriot (GeometryFactory)
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Marc Alexa
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 cgal-discuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgal-discuss
>
>


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


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Sebastien Loriot (GeometryFactory)
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 cgal-discuss.
>> To unsubscribe or access the archives, go to
>> https://sympa.inria.fr/sympa/info/cgal-discuss
>>
>>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Marc Alexa
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss



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



Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Marc Alexa
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



On 10. Jan 2019, at 09:25, Marc Alexa <[hidden email]> 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. 

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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss



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




Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

MaelRL

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 one-by-one 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



On 10. Jan 2019, at 09:25, Marc Alexa <[hidden email]> 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. 

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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss



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




Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Laurent Rineau (CGAL/GeometryFactory)
In reply to this post by Marc Alexa
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 non-zero 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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Laurent Rineau (CGAL/GeometryFactory)
In reply to this post by Marc Alexa
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Marc Alexa
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 non-zero 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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Marc Alexa
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 cgal-discuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgal-discuss
>
>


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


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Laurent Rineau (CGAL/GeometryFactory)
In reply to this post by Marc Alexa
On Friday, January 11, 2019 5:14:00 PM CET Marc Alexa wrote:
> 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.

Yes, you are right. For each simplex of the Delaunay triangulation (with weights or not), then the simplex is in the triangulation restricted to a sub-space if and only if its dual intersects the sub-space.

For a tetrahedron, it is in the triangulation restricted to the domain if and only if its circumcenter is in the domain.

For a triangle, it is in the triangulation restricted to the boundary of the domain if and only if its dual segment (or dual ray, for triangles in convex position) intersects the boundary of the domain.

There are illustrations in 2D and 3D on Google Image. For example:

https://www.semanticscholar.org/paper/Conforming-restricted-Delaunay-mesh-generation-for-Engwirda/3607169f6d38b2085a582b3b2597515e86d6719d/figure/0
https://www-sop.inria.fr/geometrica/software/cgalmesh/restrictedDT.html

--
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Mesh_3 -> Triangulation_3

Laurent Rineau (CGAL/GeometryFactory)
In reply to this post by Marc Alexa
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 cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss