Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Geometry in a 2D periodic triangulation

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Geometry in a 2D periodic triangulation


Chronological Thread 
  • From: Daniel Duque <>
  • To:
  • Subject: Re: [cgal-discuss] Geometry in a 2D periodic triangulation
  • Date: Thu, 14 Nov 2013 20:44:17 +0100

Hello everyone,

For the record, I have been able to do what I intended, with a little
more reading and M. Teillaud's help.

My original problem was in fact more complicated, since I wanted to
store geometrical information in the faces and vertices of a
triangulation. This more or less precludes the use of
Periodic_triangle_iterator, since I would like to loop over faces, not
over triangles.

Nevertheless, this code does the trick <http://pastebin.com/iMbQg0Mm>,

by iterating over faces, then getting each corresponding
periodic_triangle, and finally the geometric triangle.

Thank you. Best,

Daniel



On Wed, Nov 13, 2013 at 8:37 PM, Monique Teillaud <> wrote:
no, they are not overloaded. But the periodic_point gives you all information you need to construct a "normal" point, on which you can call kernel computations.
        Monique

Le 13/11/13 19:56, Daniel Duque a écrit :
Thanks for your replay, Monique.

I have tried things like this example:
http://doc.cgal.org/latest/Periodic_2_triangulation_2/Periodic_2_triangulation_2_2p2t2_geometric_access_8cpp-example.html

But your point, if I understand correctly, is that functions such as
squared_distance() are now
overloaded so that they return the answer that is correct for a periodic
triangulation when
the arguments are of type periodic_point. That makes sense.

Thanks again. Best,

Daniel





On Wed, Nov 13, 2013 at 5:28 PM, Monique Teillaud
< <mailto:Monique.Teillaud@inria.fr>> wrote:

    Dear Daniel,

    I guess that function periodic_point(face,index) should help you.
    http://doc.cgal.org/latest/__Periodic_2_triangulation_2/__classCGAL_1_1Periodic__2____triangulation__2.html#__a16806236a206a836a37e0ce58c961__aed
    <http://doc.cgal.org/latest/Periodic_2_triangulation_2/classCGAL_1_1Periodic__2__triangulation__2.html#a16806236a206a836a37e0ce58c961aed>

    Or periodic_segment(face,index)
    http://doc.cgal.org/latest/__Periodic_2_triangulation_2/__classCGAL_1_1Periodic__2____triangulation__2.html#__a50b4f8adcb511d4102b0e3c6f803b__b9d

    <http://doc.cgal.org/latest/Periodic_2_triangulation_2/classCGAL_1_1Periodic__2__triangulation__2.html#a50b4f8adcb511d4102b0e3c6f803bb9d>

    Once you get a periodic point, you know how to translate the point

    see also
    http://doc.cgal.org/latest/__Periodic_2_triangulation_2/__index.html#__P2Triangulation2secspace

    <http://doc.cgal.org/latest/Periodic_2_triangulation_2/index.html#P2Triangulation2secspace>

    Then you can just use standard geometric computations from the CGAL
    kernel.

    Hope this helps.
    Best,
             Monique

    Le 13/11/13 14:15, Daniel Duque a écrit :

        Hello,

        I have finally been able to have a look at this exciting new
        feature of
        CGAL. I would love to say that I understand everything on the
        manual,
        but sadly this is not the case. At any rate, after building the
        periodic
        triangulation I get a list of vertices whose Cartesian
        coordinates are
        all within the original domain. Usually, there is only one
        covering, so
        there are just as many vertices as the points I used as input.

        My question is: imagine I now want to compute geometrical stuff, say
        distances between all neighboring nodes. The triangulation build
        has the
        proper connectivity, so two vertices that are close to the edge
        of the
        domain and quite far apart may in fact be periodic neighbors. In
        order
        to do such a thing, I would do this kind of loop:

           for( Finite_edges_iterator ed=T.finite_edges_begin();
                ed!=T.finite_edges_end();
                ed++) {

              FT l2=per_dist2(v0->point(), v1->point());

        // ... print out, collect stats, whatever

        }

        The "finite" I think can be dropped in this case. I have been
        careful
        not to compute the distance between the points, but a periodic
        distance,
        following what is called the minimum image convention:

        // LL is the size of the periodic domain

        FT per_dist(const FT& x1, const FT& x2) {
            FT dx=x1-x2;

            if(fabs(dx)>LL/2.0)
              if(dx>0)
                dx -= LL;
              else
                dx += LL;
            return dx;
        }

        FT per_dist2(const Point& P1, const Point& P2) {
            FT dx=per_dist(P1.x(),P2.x());
            FT dy=per_dist(P1.y(),P2.y());

            return dx*dx+dy*dy;
        }

        I would like to get some reassurance that what I am doing is
        correct.
        Not very elegant, perhaps, and even redundant (there may be some
        CGAL
        function that does just this), but in the end correct (all edges are
        taken into account just once, for example).

        Thanks very much,

        Daniel




    --
    Monique Teillaud
    http://www.inria.fr/sophia/__members/Monique.Teillaud/

    <http://www.inria.fr/sophia/members/Monique.Teillaud/>
    INRIA Sophia Antipolis - Méditerranée
    Institut National de Recherche en Informatique et Automatique

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





--
Monique Teillaud
http://www.inria.fr/sophia/members/Monique.Teillaud/
INRIA Sophia Antipolis - Méditerranée
Institut National de Recherche en Informatique et Automatique

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






Archive powered by MHonArc 2.6.18.

Top of Page