mirror of https://github.com/CGAL/cgal
84 lines
3.5 KiB
Plaintext
84 lines
3.5 KiB
Plaintext
FINIR CORRECTIONS SUR output_stream de T_3 (ordre)
|
|
pour tester, example/Triangulation_3/example_hierarchy
|
|
|
|
a negocier
|
|
- mise a jour de la doc de Filtered_exact...
|
|
|
|
penser a enlever -I../../include\ dans demo/Triangulation_3/makefile
|
|
changer le nom du fichier include pour Filtered_exact dans exemples et demos
|
|
|
|
General
|
|
- new Vertex/Cell
|
|
- trouver une interface avec T_2 qui permette d'eviter de reprogrammer
|
|
tout le 2d dans le 3d
|
|
- purify
|
|
- Incompatibilite entre le remove, et les I/O de fichiers, a cause du numero
|
|
de vertex pour les perturbations, qui est recree pas dans le bon ordre.
|
|
Solution possible : mettre les sommets dans le fichier dans l'ordre du
|
|
numero de creation utilise par le remove ?
|
|
|
|
TEST SUITE
|
|
|
|
Doc
|
|
- quand on sauve hierarchie dans fichier, et qu'on relit le fichier,
|
|
on perd la hierarchie... et la copie, etc ???
|
|
- ameliorer user manual
|
|
- revoir les anciennes corrections de JF Dufourd
|
|
|
|
Exemples - demo
|
|
- en rajouter si bonnes idees...
|
|
|
|
TDS
|
|
- Unification de Triangulation::Vertex et TDS::Vertex.
|
|
- 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 ?
|
|
- set_number_of_vertices(number_of_vertices()+1); devrait etre dans la TDS ?
|
|
|
|
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) ?
|
|
- nearest neighbor
|
|
|
|
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 --> apres explications... il y a un pb, les infos
|
|
eventuellement rajoutees par l'utilisateur dans sa cell_base ont une
|
|
valeur "aleatoire" pour les cellules creees par insert().
|
|
|
|
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).
|