Discussion :

[TanEk]

Bonjour,

Je suis actuellement en train de développer un éditeur pour une structure appelée maillage en demi-arête. Je ne vais pas m'attarder sur la structure elle-même. Je pense avoir à peu prêt saisie la notion de modèle-vue-contrôleur mais je n'arrive pas à la mettre en oeuvre dans une structure déjà existante sans être intrusif.

J'ai défini ma structure en demi-arête en arbre telle que suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
triangle 1
   half-edge 1
      sommet
   half-edge 2
      sommet
   half-edge 3
      sommet
triangle 2
   half-edge 1
       sommet
   half-edge 2
       sommet
etc.

Voici maintenant le problème que je me pose : ma structure existe déjà et est plutôt un graphe. Ensuite les éléments de l'arbre n'ont rien en commun (des types complètement différents, ils n'ont pas une classe mère commune). Hors dans les exemples fournis sur le net on parle toujours d'un TreeItem et on peut avoir certains noeuds spécialisés mais ils sont quand même des TreeItem par héritage. J'en viens maintenant à mon problème, je dois hériter de cette méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
virtual QModelIndex index ( int row, int column, const QModelIndex & parent = QModelIndex() ) const = 0

pour définir mon modèle. Voici maintenant ma question : comment je fais pour lier ma structure déjà existante à mon modèle ? Si je mets de simples pointeurs (qui seront envoyés au QModelIndex et récupérables avec la méthode internalPointer) vers mes objets je n'ai pas assez d'informations pour trouver le fils connaissant l'index. En effet, comme les types sont complètement différents, si je récupère le pointeur, je ne saurais pas quel type d'objet c'est et donc connaître ses fils.

Je me demande si je ne devrais pas utiliser les rtti seulement les rtti ne doivent pas être utilisés avec des classes ayant au moins une méthode virtuelle ? Et si possible j'aimerai éviter cela.

Si vous avez des suggestions.

Merci d'avance.

[yan]

Salut

Ensuite les éléments de l'arbre n'ont rien en commun (des types complètement différents, ils n'ont pas une classe mère commune)

j'ai pas bien compris cela.
Tu as quand même une structure? S'ils n'ont rien en commun, comment fait tu la différence entre les noeuds et les feuilles?

[TanEk]

Et bien en gros j'ai ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
struct MeshHalfEdge
{
     vector<Face> faces;
};
 
struct Face
{
    HalfEdge halfEdge;
};
 
struct HalfEdge
{
   Face face;
   Sommet sommet;
   HalfEdge next; // prochain
   HalfEdge sym; // Half-Edge Symétrique
};
 
struct Sommet
{
   float x, y, z;
   HalfEdge halfEdge;
};

Pour plus de détails voir : http://www.flipcode.com/archives/The...tructure.shtml. Donc ils n'ont pas de classe mère commune. Tu penses que je devrais rajouter une surcouche genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class Node
{
public
    Node* getParent(void);
    Node* getChild(int index);
    int getChildCount(void);
};

Comme ceci dans ma structure Half-Edge et ensuite utiliser ceci pour les introduire dans mon modèle d'arbre ? Le truc c'est qu'en faisant ça je rend mes structures polymorphiques et elles deviennent beaucoup plus grosses en mémoire (on peut avoir des meshs à plusieurs millions de vertices).

[yan]

Tu penses que je devrais rajouter une surcouche genre :

Vue que tout est typé, je dirait que non. Au cas ou, Tu devrais quand même demander conseil sur le forum C++ (si tu ne la pas encore fait).
par contre que face contient HalfEdge et HalfEdge contient face ça me parait étrange mais cela correspond a ton article.

Le mieux que tu puisse faire, c'est de te baser sur cette exemple
http://qt.developpez.com/doc/4.4/ite...mpletreemodel/

En suite tu as un treeitem en class mère et:
spécialisation pour
MeshHalfEdge
Face
Sommet

Le seul intérêt de treeitem est de fournir les information pour un noeud de l'arbre. Après y as surement une gestion mémoire à prévoir pour ne pas tout allouer d'un coup.

Dans le principe du model-vue-controleur, l'ihm n'est qu'une vue et ton coeur métier ne doit en aucun cas connaitre ses contraintes. En gros :
model : le coeur de ton application
vue : ihm
controleur : passerelle entre les deux.

En gros, il faut au maximum séparer les chose pour pouvoir facilement passé de Qt à un autre lib comme gtk.

Par contre rien ne t'empêche que ton cœur soit basé sur Qt puisse que Qt fait plus que de l'ihm

je ne sait si je suis claire

[edit]
Le problème de cette structure est qu'il est assez difficile de maintenir tout les liens entre eux. Tu devrait regarder ce tuto qui te simplifiera cette tache
http://loic-joly.developpez.com/tuto...mart-pointers/
A voir si cela ne te rajoutera pas trop de mémoire
Au faite, tu devrais regarder CGAL. Ils ont peut être une classe basée sur cette structure :
http://www.cgal.org/Manual/3.3/doc_h...pter_main.html
http://www.cgal.org/Manual/3.3/doc_h...nk_anchor_1113

[epsilon68]

tu peux faire des dynamics cast et voir si ca te retourne different de 0 ...
dans ton cas je ne vois guere plus malheureusement.

mais tu peux encapsuler avec un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
class BetterAccess
{
  BetterAccess( void * rawptr ) {  init }
 
  // plein de dynamic cast
  bool isTriangle();
  bool isHalfSpace();
 
  Triangle* triangle() // null si c'est pas un triangle.
 
  void* getChild(int it) {
    if( isTriangle() ) {
       Triangle * mytriangle = triangle();
       return mytriangle->getHalfSpace(i) etc etc etc
    }
    else if( etc etc
  }
}

c'est finalement pas si sale que ca non?

a+

[TanEk]

Je vous remercie pour vos propositions, je vais demander l'avis sur le forum C++ mais pour le moment je pars sur ce que j'ai dis plus haut (pour Mongaulois : ça revient à ta proposition de faire un TReeItem et de dériver : Node <=> TreeItem).

[HanLee]

Pour plus de détails voir : http://www.flipcode.com/archives/The...tructure.shtml. Donc ils n'ont pas de classe mère commune. Tu penses que je devrais rajouter une surcouche genre :

L'article indique juste comment est implémentée la structure de données, mais pas comment modifier, construire un maillage à l'aide de cette structure de données.

Le lien vers Stanford est mort. Ca m'intéresse, parce que c'est plus compliqué qu'on le croit.

Lire des informations sur un half edge est simple, mais construire l'information c'est pas évident.

Les seules publications exhaustives que je connais sont payantes...

[yan]

Lire des informations sur un half edge est simple, mais construire l'information c'est pas évident.

Les seules publications exhaustives que je connais sont payantes...

GTS est sur le même principe mais c'est du C. Tu trouvera peut être des chose intéressante :
http://gts.sourceforge.net/biblio.html

Il n'y as pas de publication lié à CGAL?