mirror of https://github.com/CGAL/cgal
71 lines
2.9 KiB
Plaintext
71 lines
2.9 KiB
Plaintext
General
|
|
- new Vertex/Cell
|
|
- trouver une interface avec T_2 qui permette d'eviter de reprogrammer
|
|
tout le 2d dans le 3d
|
|
- virer geom_traits
|
|
- purify
|
|
|
|
TEST SUITE
|
|
|
|
Doc
|
|
- revoir tous les insert...(...)
|
|
- traits class
|
|
- ameliorer user manual
|
|
- verifier requirements sur la cell_base pour output/input stream
|
|
- revoir les anciennes corrections de JF Dufourd
|
|
|
|
TDS
|
|
- Facet_circulator : Est-ce qu'il y a besoin de stocker un TDS * ? Stocker
|
|
deux Vertex * plutot que deux ints, ca permet de gagner une Cell *, et
|
|
d'etre plus rapide, non ?
|
|
- comprendre bug dans ancienne version de is_edge de tds, dim 2
|
|
(pb edge_iterator...? etonnant)
|
|
- Why are the iterators friend in the ds_cell ?
|
|
|
|
T3
|
|
- nettoyer flips/is_flippable (code duplique)
|
|
- incident_facets, incident_cells (vieille demande de Frank a
|
|
rediscuter)
|
|
- is_valid devrait verifier l'enveloppe convexe
|
|
- prevoir differentes sorties : geomview (ameliorer le rendu pour
|
|
donner un effet de perspective), vrml, viewer_3...
|
|
- point iterator
|
|
|
|
Delaunay
|
|
- optimiser remove
|
|
- For Delaunay, we can use the visibility (non stochastic) walk. How to
|
|
choose ? Is it worth the complexity (benchmark first) ?
|
|
- insertion dans Delaunay : quand on est a l'interieur de l'enveloppe convexe,
|
|
mais une cellule en conflit est en contact avec le bord, on va tester sa
|
|
voisine infinie si elle est en conflit avec un test d'orientation, mais il
|
|
n'est pas necessaire. Essayer de le zapper (voir avec un bench/profile si
|
|
la complexite en vaut le coup).
|
|
- dual -> voronoi
|
|
|
|
Gestion memoire
|
|
- Alignement des cellules en memoire : effets de cache + pointeurs a
|
|
l'interieur des cellules pour le voisinage (Fred a deja fait => ask).
|
|
- La gestion memoire (interne a l'allocateur new/delete) prend pas mal de
|
|
place (30%...). Ca serait bien de ranger les cellules dans des tableaux,
|
|
et ca permettrait de surcroi[tsx] aussi de se passer des listes doublements
|
|
chainees.
|
|
Le flag temporaire pourrait aller dans un des bits -> sizeof(cell) == 32 :)
|
|
NB: Ca serait bien de factoriser ce probleme avec T2D !!!
|
|
- De plus, un vrai allocateur (a la STL) serait mieux, pour preserver les
|
|
constructions/destructions (encore que je doute de l'utilite, je ne vois pas
|
|
comment ca peut etre vraiment fiable).
|
|
- M doit se faire expliquer par S dans le detail une fois pour toutes ce
|
|
que ce qui precede veut dire, et qu'il n'y a aucun pb si l'utilisateur
|
|
change la cell_base.
|
|
|
|
Regular :
|
|
- faire marcher la hierarchie avec. Le probleme est qu'on delete des
|
|
vertex, et donc la hierarchie est perdue avec ses pointeurs up/down qui
|
|
pointent dans l'espace, du coup...
|
|
La solution que je vois est de commencer l'implantation des sommets caches
|
|
par une liste (in place) de vertex dans chaque cellule, qui sera
|
|
necessaire pour le remove de toute facon.
|
|
- quelques cas de dimension < 3 ne sont pas programmes. --> ca me
|
|
parait etre une affirmation un tantinet rapide, je dirais plutot, a
|
|
la limite : verifier que tous les cas sont programmes (M).
|