Discussion :

[epsilon68]

Hello,

en regardant plusieurs moteurs 3d, j'ai remarqué que les triangles indexaient les points et les aretes.... moi dans ma structure j'ai des pointeurs. Mes triangles pointent leurs vertices et leurs aretes.

J'ai l'impression que personne ne fait ca, pourtant c'est pratique, mes triangles sont independant, je peux leur appeler une fonction sans passer les tableaux de points et plus...

Quelqu'un pourrait me dire pourquoi il faut indexer et non pointer ?

C'est pas encore trop tard pour que je change alors ...

Merci a+

[Happy]

Bonjour,

Pour éviter donc les duplications d'un arrêt quand il y a plusieurs triangles partageant ce dernier?

[epsilon68]

un pointer fait exactment la meme chose dans ce cas non?

[orand]

un pointer fait exactment la meme chose dans ce cas non?

oui mais imagine que tu fasse des calculs sur les vertex, il se peut que tu calcul plusieurs fois plusieurs vertex se trouvant à la même position pour rien.
sans parler de la consommation mémoire en +.

au final ce que tu pense gagner d'un coté tu en perd encore plus de l'autre.

[Emmanuel Deloget]

Hello,

en regardant plusieurs moteurs 3d, j'ai remarqué que les triangles indexaient les points et les aretes.... moi dans ma structure j'ai des pointeurs. Mes triangles pointent leurs vertices et leurs aretes.

J'ai l'impression que personne ne fait ca, pourtant c'est pratique, mes triangles sont independant, je peux leur appeler une fonction sans passer les tableaux de points et plus...

Quelqu'un pourrait me dire pourquoi il faut indexer et non pointer ?

C'est pas encore trop tard pour que je change alors ...

Merci a+

Personne ne fait ça parce que tout le monde prend exemple sur les API 3D majeures - OpenGL et DirectX - qui ne peuvent pas gérer des pointeurs lors de la définiton des listes de triangles.

Ceci-dit, ne pas le faire pour éviter de faire comme tout le monde n'est pas forcément une bonne chose. D'une part, si tu passes en 64 bits, tes triangles vont doubler de taille (mais ce n'est pas bien grave). D'autre part, combien d'algorithmes nécessitent-t-ils de prendre en compte et les triangles, et les vertex ? Très peu (calcul de normal, extrusion de silouhette... un autre auquel je n'ai pas pensé ?). Dans ces conditions, est-til vraiment utile de "faire différent", étant donné que
1) il n'y a strictement aucune pénalité liée à l'utilisation d'index en lieu et place de pointeurs
2) si plus tard tu souhaites utiliser une API 3D de type OpenGl ou DirectX, tu devra faire cette modification.

(Question: à quoi cela sert-il de garder une référence sur les arêtes d'un triangles ? Elles sont implicites à partir du moment ou on connait les 3 sommets... Ce qui peut être interessant, ce ne sont pas les arêtes, mais les triangles adjacents. Mais bon, la fatigue aidant, j'oublie peut-être quelque chose... )

[epsilon68]

Hello,

merci pour vos reponses :-)

je garde les aretes pour avoir effectivement les faces adjacentes.
elles me servent aussi a calculer les 3 plans du triangle qui me servent à tester si un point est dans une face. Donc en cas de mis à jour des points du modele, mes faces peuvent se mettre a jour.

Je ne gardais pas les indices parce que c'etait plus pratique a manipuler, par exemple je peux retourner un triangle sans que l'utilisateur de cet objet se soucie du tableau de points etc.

Les indices obligent aussi a avoir une structure a acces direct. en plus un tableau est obligé vous allez me dire pour OpenGL ou autre (grrr Directx).

donc vous utilisez un vector ?

etes vous d'accord avec la definition des classes suivantes:

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
 
class Mesh {
  vector<Vertex> vertices;
  vector<Edge> edges;
  vector<Triangle> faces;
}
 
class Vertex {
  Vector3 position;
  Vector3 normale;
}
 
class Edge {
  int[2] vertices;
  Vector3 dir;
}
 
class Triangle {
  int[3] vertices;
  int[3] edges;
  Plan plane;
  Plane[3] planes; // pour tester un point si elle est dans le triangle
}

Comment faites-vous par apres pour l'afficher avec OpenGL ?
je n'utilises de toute facon pas la structure de données adequates je pense si?

Je connais bien le mode immediat avec OpenGL et quasiment pas les vertex buffer objects ou les frame buffer objects... J'ai besoin de votre aide...

Merci a+

[epsilon68]

up?

[epsilon68]

j'ai changé ma structure, je n'utilise plus de pointers, en effet ca sera mieux pour OpenGL... Mais j'aimerais toujours votre avis?

[epsilon68]

Personne ne peut me guider? me dire si je vais vers des orties ou si je suis sur une autoroute?

[LeGreg]

Les moteurs 3D n'ont pas besoin d'autant d'infos que cela. les modèles leurs viennent de packages 3D comme 3dsmax, maya, softimages, et n'ont que rarement besoin d'être modifiés à la volée.

Donc quoiqu'il arrive il est probable que tu doives faire cohabiter deux types de représentation, une qui est adaptée à tes calculs (s'ils font appel à la connectivité et autre), et une autre adaptée à l'affichage (une liste de vertices et une liste d'indices que tu peux dériver de ta représentation plus complexe). Pour les perfs les cartes graphiques préfèrent que les données soient mis dans un vertex buffer dont la mémoire est gérée par le driver de toute façon (donc ta structure servira juste de cache intermédiaire par rapport à ce qui est nécessaire à l'affichage).

De toute façon s'il y a une solution idéale elle est très spécifique à ton problème (puisque s'il n'etait question que d'affichage tu n'aurais pas besoin de stocker les edges et les plans).

LeGreg

[epsilon68]

pourtant c'est bien pratique une structure du modele 3d, on peut faire des tests d'intersection, calculer les normales aux sommets, calculer la silhouette suivant un angle donné etc...

je suis et reste ouvert a toutes propositions quand même.

merci a+

[Kurisu]

Si c'est juste pour faire des tests de collision, je te conseille d'abstraire un peu plus. En fait, tu peux faire l'abstraction entre le modèle "graphique",qui sera stocké dans un vertex buffer pour optimiser le rendu, et le modèle "physique" (peut-être simplifié par rapport au modèle graphique) qui te servira á faire les tests de collision. Pour debugger, tu peux aussi faire le rendu du modèle physique, mais ceci sera en mode immédiat.
Juste mes 2 sous, mais qu'est-ce tu en penses?

[epsilon68]

en fait je suis parti sur les indices parce que ca me permet d'envoyer ma structure a opengl (avec les strides, offset sur les indices dans une structure plus grosse comme la mienne)
je fais aussi moins de petites allocations, pas de new Vertex pour chaque vertex.

pour l'instant ca marche bien, l'inconvenient aussi des indices etant qu'il faille passer la structure des points ou des edges ou des triangles quand on veut acceder reellement aux objets, mais ca va je trouve, c'est encore pas mal.
Les edges, vertices, triangles sont de toute facon assez couplé avec le model donc pas de problem vraiment. Maintenant je m'attaque a la normalisation des vertices (partagés entre les triangles) et ensuite au rendu direct.

En fait pour l'instant je suis en train de decoupler mon moteur de Qt suite a l'annonce du rachat par nokia... Je ne voulais pas le faire avant pour aller plus vite dans le development, mais je suis quasiment sur que Qt va progressivement disparaitre, noyé dans une grosse structure.

Pour etre honnete, maintenant je suis un peu perdu, Qt étant pour moi le meilleur toolkit qui m'assurait le mutli-plateforme en C++.
J'ai vu que Java ne pouvait pas repondre a mes besoins mais C# si.
alors je me demande si je ne vais pas tout simplement passer a c#....

d'apres mes benchs, il n'etait que 2 fois moins rapide que C++ dans mon cas, et donc apres plus de problemes sur les innovations et l'interface graphique, sauf que pour la portabilité c'est rapé, peut-etre alors mono du coup. Je reutiliserais mon c++ en c++ managé... J'espere que Boost le permet

a+

[Emmanuel Deloget]

En fait pour l'instant je suis en train de decoupler mon moteur de Qt suite a l'annonce du rachat par nokia... Je ne voulais pas le faire avant pour aller plus vite dans le development, mais je suis quasiment sur que Qt va progressivement disparaitre, noyé dans une grosse structure.

Aucune chance. De toute façon, même si Qt "disparait", il n'en reste pas moins disponible en GPL et (vu l'importance du projet pour l'équipe KDE) sera nécessairement repris dans le futur.

Mais je doute que Nokia fasse disparâitre Qt - il l'ont racheté, quand même.

d'apres mes benchs, il n'etait que 2 fois moins rapide que C++ dans mon cas, et donc apres plus de problemes sur les innovations et l'interface graphique, sauf que pour la portabilité c'est rapé, peut-etre alors mono du coup. Je reutiliserais mon c++ en c++ managé... J'espere que Boost le permet

a+

Boost ne sait pas ce qu'est du C++ managé. Il n'utilise pas les extensions au langage C++ propre à C++/CLI.

Fait attention avec mono - il va falloir attendre encore un peu avant que la librairie offre un support suffisant des namespace non standard (Microsoft.xxx).

Sinon, as-tu essayé wxWidgets ? Je suis d'accord avec toi, la programmation sous Qt est très agréable - mais la programmation wxWidget est elle aussi très agréable. Cela te permettra de garder ton code C++ (mais, encore une fois, ce n'est vraisemblablement pas nécessaire d'abandonner Qt; ce qui ne veut pas dire que tu ne dois pas découpler ta librairie de cette bibliothèque).

[epsilon68]

hello,

merci Emmanuel pour tes conseils - je ne regrette pas du tout d'etre passé en indices ;-D

pour ce qui est de Qt, j'ai vraiment regardé les alternatives et ... il n'y en a pas...

ultimate c++ trop jeune (et trop "C++" a mon gout), WxWidgets semble trop vieux, gtkmm n'est pas sous macosx, mono n'a pas de solution pour l'IHM (les Forms sont bien sur windows mais nulles sous les autres)

donc je n'ai le choix que de Qt ou faire la partie IHM specifique sur chaque plateforme (comme j'ai beaucoup trop de temps à moi)

mais maintenant je ne suis pas rassuré sur l'avenir de Qt donc je separe mon code metier de l'IHM (je le fait normalement mais bon j'ai voulu exploiter pleinement Qt et de ne pas me ralentir a établir des ponts et des facades)...

je continue donc mon code metier avec boost ;-)

d'ailleurs je compte bien faire une dll... pour l'utiliser dans les autres languages.

finalement c'est comme ca que j'aurais du faire depuis le debut ;-)
heureusement c'est pas trop tard pour moi...

j'utiliserais donc Qt pour prototyper mon truc, puis je verrais bien a ce moment la, comme souvent les vraies decisions sont prises au bout d'1 an dans les rachats de ce type.
Je compte beaucoup sur KDE

[Mat.M]

Hello,

en regardant plusieurs moteurs 3d, j'ai remarqué que les triangles indexaient les points et les aretes.... moi dans ma structure j'ai des pointeurs.
Merci a+

Des pointeurs au sens C/C++ ? C'est à dire des adresses mémoires ?

Si tu as des pointeurs/adresses mémoires comment veux-tu passer d'un pointeur à un autre s'ils ne sont pas contigus en mémoire ?
Avec des pointeurs c'est risque de plantage s'ils sont mal gérés.
Avec des indices tu parcours des listes séquentiellements avec une banale boucle pour faire des listes de triangles qui vont constituer une mesh
Regarde le SDK de Direct X pour les listes de triangles on passe par la gestion d'indices effectivement..

[epsilon68]

Des pointeurs au sens C/C++ ? C'est à dire des adresses mémoires ?

oui c'était ca

Si tu as des pointeurs/adresses mémoires comment veux-tu passer d'un pointeur à un autre s'ils ne sont pas contigus en mémoire ?

Je ne comprends pas la question. J'allouais chaque vertex, edge et triangle avec "new", ensuite un triangle avait 3 pointers sur des vertices, etc.

Avec des pointeurs c'est risque de plantage s'ils sont mal gérés.

oui c'est vrai, mais ils étaient bien gérés, ce n'est pas le probleme.

Avec des indices tu parcours des listes séquentiellements avec une banale boucle pour faire des listes de triangles qui vont constituer une mesh

avec les pointers aussi



en fait le point le plus important était de pouvoir l'envoyer à la carte graphique. Ce n'était pas bon avec les pointers dans ce cas la, et c'est normalement tout bon avec les indices (je n'ai pas encore testé).

Emmanuel avait tout bon dans son post.

Voila a+

[bafman]

J'allouais chaque vertex, edge et triangle avec "new"

arg... Je suis mort rien qu'en lisant ca... une alloc par vertex, c'est quand même horrible pour le pauvre allocateur memoire en plus de fragmenter...

[epsilon68]

arg... Je suis mort rien qu'en lisant ca

Mince, j'espere que tu vas mieux

[Mat.M]

arg... Je suis mort rien qu'en lisant ca... une alloc par vertex, c'est quand même horrible pour le pauvre allocateur memoire en plus de fragmenter...

Tout le monde pourrait faire la même erreur
Epsilon68 n'a peut-être pas totalement tort mais c'est certain que pour des objets complexes cela risque de fragmenter la mémoire.
Faire x new() à chaque fois...