From baec1644a432ab0b018fea41b118cc38685d41ef Mon Sep 17 00:00:00 2001 From: Sylvain Pion Date: Thu, 1 Jan 2004 17:27:06 +0000 Subject: [PATCH] updates to compact representation scheme --- Packages/Triangulation_3/TODO | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/Packages/Triangulation_3/TODO b/Packages/Triangulation_3/TODO index bc9b34719ef..d27e33fee21 100644 --- a/Packages/Triangulation_3/TODO +++ b/Packages/Triangulation_3/TODO @@ -28,18 +28,13 @@ TDS - More compact representation [inspired by a CUJ article for lists] : instead of having a cell which stores 4 vertex pointers, it only stores the XOR of them. And a Cell_handle now additionaly stores the 4 vertex pointers - of the cell. - The tricky part seems to be how to update the correspondance between - neighbor(i)/vertex(i) when doing c2 = c->neighbor(i). - Maybe it requires storing a permutation table, or storing the vertices - in adress order, and squatting bits in the Cell* in order to specify the - permutation ? - It's definitely worth thinking about it. - - Maybe we could remove the requirement of fat handles by storing a little - bit more ? But that seems complicated at first sight. Let's try - to implement the first idea first. - - Sharing the neighbor pointers seems less fruitful. - + of the cell, the "context". + One problem is the Cell_iterator : it looses the context, so I think that + one way to work around this is to write the Cell_iterator as based on the + Vertex_iterator (a bit like the reverse used to be made) : we iterate over + the vertices, and for each vertex, we compute the incident cells, but we + pick only those whose smallest vertex (adress-wise) is the one in question. + T3 - degree() devrait-il, au niveau geometrique, ne pas compter le sommet infini ? - is_valid devrait verifier l'enveloppe convexe