1

I'm planning on using CGAL Triangulation and Delaunay Triangulation classes as a backbone geometric structure for robot motion planning algorithms. The main difficulty that I have encountered so far is in assigning extra geometric data to full cells in an abstract complex. For example, in order to find the shortest path through a full cell I need to compute a set of normal vectors to all facets. For this purpose, I use expensive pseudo inverse procedure. Since, these computations have to be done several times in each full cell, I prefer to store this data once it is computed, and retrieve it during successive computations. In addition, I would like to store collision data for each full cell instead of recomputing it all over again after refining given triangulation.

Browsing some answers here and trying to understand the structure of CGAL, I reached some understanding on this subject:

  1. It is a really bad idea to rewrite geometric kernel just for this...
  2. I've seen examples of using a vertex base class with info in which points are augmented with indices here. Although using Triangulation_cell_base_with_info seems as an easy workaround, I consider it as an inelegant hack because it requires me to implement a wrapper class for keeping additional data and pass this class to the planning algorithm.
  3. I can derive a cell class from Triangulation_ds_cell_base. This looks like the most acceptable way to do things, but I cannot find a good example of code that will help me to get started. I need not only class derivation, but also example code on how to access cell data in various scenarios: through iterator, vertex adjacency, and so on.

So, here are my two questions:

  1. What is CGAL way to store and retrieve additional geometric data per cell?
  2. Is there a good example of code doing exactly that?

EDIT: I forgot to mention that I need to use dD triangulation introduced in CGAL 4.6

Community
  • 1
  • 1
Dmitry Yershov
  • 11
  • 2
  • In 2D/3D, `*_with_info` is the way to go, and I don't understand why it seems hacky to you. In dD, it seems that you can pass as second argument of Triangulation: `Triangulation_data_structure, Triangulation_full_cell >`. – Marc Glisse Jun 18 '15 at 21:54
  • If you don't want to dig too deep into the implementation of CGAL, you could easily create, on the side, a (hash)map that associates whatever information to a Full_cell_handle. – Marc Glisse Jun 18 '15 at 22:01
  • Looking at the source code of CGAL, I have a feeling that adding MyInfo class/struct as a storage policy for the triangulation data structure will brake the code. Storage policy accepts either default policy or mirror policy, each of which actually contain combinatorial data for full cell connectivity. If you simply substitute it with a 3rd party class, this necessary data structure is going to be missing... Also, I consider using hash maps to be even more serious hack than storing indices in the cell info. The main reason, is that I don't want to implement a wrapper class to keep this data. – Dmitry Yershov Jun 18 '15 at 22:24
  • Well, read better. What I suggested amounts to replacing No_full_cell_data (an empty class) with whatever class you like containing your data, it does not change the policy. If you are going to call all clean solutions "hacks", that's too bad for you. And you still haven't explained that wrapper class business you are complaining about. – Marc Glisse Jun 18 '15 at 23:19
  • My bad... I've checked Triangulation_ds_full_cell instead of Triangulation_full_cell. I'll try following your suggestion. Thanks. – Dmitry Yershov Jun 19 '15 at 01:01

0 Answers0