• Introduction
• Interface utilisateur
• Paramétrisation
• Améliorations
• Bilan
• Documentation

Interface utilisateur

• Encore beaucoup de messages se font par le biais de la console. Ce serait préférable d'avoir ces messages sur l'interface directement, en les affichant non plus sur la sortie standard mais dans un QWidget du genre Pop-up ou autre.
• Dans notre interface, on ne peut modifier un point de snake déjà tracé. Pour permettre la modification/suppression de points déjà tracés, il suffirait de mettre en place de nouvelles commandes, qui activent les modes suivants : ajouter sommet, supprimer sommet, déplacer sommet. Ces modes se traduiraient par de nouvelles procédures qui agissent sur les attributs _snake_total, _snake_vertex de Mesh.
• La visibilité des objets que nous avons rajouté au mesh (points du snake, lignes, faces de la région locale) laisse à désirer. Il suffirait de rajouter un offset à chacun de ces objets.
• Le must du must : pouvoir travailler sur plusieurs snakes. Il suffirait pour cela de modifier la structure de Mesh : actuellement un unique snake est associé à un mesh. Cette modification n'est pas la plus intéressante.

Structure du snake

• Le calcul du plus court chemin est encore une approximation. La plupart du temps, la solution trouvée semble assez proche de l'optimum. Il existe encore des cas où notre algorithme ne termine pas. Cependant l'utilisateur peut contourner ce problème en sélectionnant des points intermédiaires, pour "aider" notre algorithme. La meilleure solution serait d'appliquer un algorithme de type Dijkstra. Mais dans ce cas, le temps de calcul et la place mémoire utilisée augmenteraient.

  

• Actuellement il n'est pas possible de partitionner le snake en plusieurs snakes. Ceci est gênant pour les raisons suivantes :
  • Si l'utilisateur trace un snake qui "se mord la queue" (c'est-à-dire si le snake est une courbe fermée), la région locale associée est généralement un beignet : il y a un trou à l'intérieur. Actuellement, notre calcul de la région locale est correct (voir image ci-dessous). Par contre, la paramétrisation 2d est fausse. Pour résoudre le problème, il faudrait boucher le trou de la région locale (c'est-à-dire ajouter les facettes situées dans le trou). On pourrait comparer cette solution avec celle consistant à partitionner le snake : la région locale serait donc divisée en 2 moitiés.

    

  • Actuellement le nombre de points du snake est limité à 200 (valeur arbitraire). En effet 200 est la taille de la matrice que nous utilisons dans le calcul de la paramétrisation 2d. Cependant on a pu tester sur les maillages donnés, que 200 points étaient en général suffisants pour longer n'importe quel feature.

Structure de la région locale

• La structure de données actuelle est lourde. En effet une Region a deux attributs Polyhedron : un correspond à la fraction qui nous intéresse du mesh 3D d'origine, l'autre est une version 2D, sur laquelle on effectue les calculs de minimisation d'énergie. Les 2 meshes ont la même topologie. La seule différence est les coordonnées des points associés aux sommets. Nous étudions actuellement une solution : rajouter à la classe Enriched_vertex un attribut de type Point_3, qui correspond en fait à un point du plan d'équation z=0. Ainsi, on peut manipuler un unique mesh. Dans ce cas, la phase de paramétrisation consiste à parcourir les points 3D associés aux sommets, et à remplir les attributs Point2d correspondants.
• Au vu des difformités des triangles utilisés dans les meshs de nos exemples, il semble intéressant d' "homogénéiser" les régions locales, d'une part en enlevant les concavités, et d'autre part en augmentant localement la taille de la région locale autour des rétrécissements.