Vertex buffer et géométrie complexe

J'ai beau tourner le probleme dans tout les sens je ne m'en sort pas et je ne vois aucune solution satisfaisante.
le fonctionnement des vertex buffers (ou VBO opengl) sont optimisés pour les géométries simples, voir simplistes, c'est à dire des géométrie de base avec UNE normale et UN uv par vertex... hors, c'est du jamais vue ! N'importe quel "vrai" objet 3d à un mappage uv complexe par face qui implique une multiplication de coordonnées de texture pour LE MEME vertex... De fait, dans un objet normalement mappé, on trouve beaucoup plus de coordonnées de texture que de vertex, donc pour rendre fidelement un tel objet, il est nécéssaire d'appliquer une logique "par face"... Or, la logique d'indexation des VB et VBO sont... par vertex... avec une normale et un uv par vertex... Dans un monde original et optimale, on aurait la possibilité de tracers nos géométrie à l'aide de 3 index différents, un pour les vertices, un pour les normales, et un pour les uv... En l'état, je n'ai trouvé qu'une solution : faire des VB brutalement avec des redondances de vertex pourvu que chaque face soit dessiné avec les normales et les uv correspondants, et du coup l'utilisation d'un index buffer est purement fortuit puisque ils s'agit de tout dessinner à la suite (1,2,3,4,5,6...) ... c'est un énorme gachi de mémoire bien entendu, alors j'aimerais savoir si il existe une autre solution...

En même temps, moi je veux bien que tu me donnes un exemple d'un modèle qui possède de nombreux niveaux de texture avec des UV différents pour chaque. Ca ne me paraît pas si fréquent.

Tu développes quel genre d'appli ?

Citation:

---

Envoyé par Loulou24

En même temps, moi je veux bien que tu me donnes un exemple d'un modèle qui possède de nombreux niveaux de texture avec des UV différents pour chaque. Ca ne me paraît pas si fréquent.

Tu développes quel genre d'appli ?

---

Non il ne s'agit pas de models avec différents niveau de texture... il s'agit de models avec UN SEUL niveau de texture, mais un mappage de texture complexe. N'importe quel personnage d'un jeu video est fait comme ça, certains vertex partagent deux corrdonnées de textures, voir trois, selon qu'il est utilisé par une face ou l'autre...

Ah ok, j'avais compris de travers.

Ceci-dit le problème ne se pose pas si tu textures correctement ton modèle. A savoir que s'il y a continuité dans la géometrie, il peut très bien y avoir continuité dans le mapping et donc tu n'as bien qu'une paire d'UV par vertex.

En tout cas, il n'y a pas de solution miracle. Mais personnellement, c'est un problème qui ne s'est jamais posé à moi.

Citation:

---

Envoyé par Loulou24

Ah ok, j'avais compris de travers.

Ceci-dit le problème ne se pose pas si tu textures correctement ton modèle. A savoir que s'il y a continuité dans la géometrie, il peut très bien y avoir continuité dans le mapping et donc tu n'as bien qu'une paire d'UV par vertex.

---

Et bien non, malheureusement ça ne marche pas comme ça... Tu peux avoir un mesh d'un bloc mais des uvs "fragmentés"... c'est meme pratiquemement indispensable si on veut mapper un objet correctement...
Prenon l'exemple d'un personnage dont le mapping se trouve sur une image de 512 * 512. tu ne peux pas mapper entièrement ton personnage d'un bloc, tu est obliger d'appliquer différentes projections suivant les parties du model. Tu aura par exemple le visage dans un coin, le bras dans l'autre, le dos d'un coté, le torse de l'autre etc... Le model est d'un seul bloc, mais les uvs sont "détachés" et son répartis par "subsets" selon leur projection... MAIS comme le mesh est d'un bloc, tu aura fatalement des blocs de mappings qui partagerons des vertices, et aurons pourtant des uvs totalements différent, c'est que une face sera disposé un endroit de l'image, et l'autre face, tout à fait de l'autre coté... tout les uvs sont différents, mais deux vertexs sont partagés...

Exemples :
http://www.righthemisphere.com/products/duv/images/duvui.jpg
http://www.caligari.com/Products/trueSpace/ts65/Brochure/images/UVE_small.jpg
http://www.jawa9000.com/technical/3d-color-theory/3d-theory-images/uv-mapping-stages04.jpg
http://www.psionic.pwp.blueyonder.co.uk/tutorials/lowpoly/guv30.jpg
http://bim.km.ru/nfs_hs/car_tutor_2/4_uvmapping.html

Oui oui, je n'ai pas dit que le problème ne se posait jamais ; je te dis juste que ça ne m'avait jamais choqué, et qu'il n'y a de toute façon pas d'alternative niveau API pour optimiser cela.

Ensuite je ne suis pas non plus un pro en mapping, mais j'imagine que dans la plupart des cas on peut tout de même s'en sortir relativement bien.

Citation:

---

Envoyé par Loulou24

Oui oui, je n'ai pas dit que le problème ne se posait jamais ; je te dis juste que ça ne m'avait jamais choqué, et qu'il n'y a de toute façon pas d'alternative niveau API pour optimiser cela.

Ensuite je ne suis pas non plus un pro en mapping, mais j'imagine que dans la plupart des cas on peut tout de même s'en sortir relativement bien.

---

Ben, la seule solution que j'ai vu, c'est celle de refaire un buffer "redondant" qui gache horriblement la mémoire... la technique de faire un buffer, non par vertex, mais par face... donc on multiplie le nombre de vertex réel par 3... ca fait dur dur quand même...

déjà tu travailles par indices pour bénéficier des caches post transforms, ensuite tes données ne sont pas "fortement redondantes" mais redondantes uniquement sur les bords de chacun de tes "patches", tu peux former tes artistes pour réduire le nombre de patches et donc limiter la redondance mais c'est probablement de la suroptimisation surtout à ce niveau de détails et sur du hardware moderne.

En fait tu fais ça simplement : si UV partagée, alors partage de données et si UV pas partagé alors duplication de données.

Tu disposes de combien de sommets par modèle ? combien de patches par modèle ? De combien de mémoire est-ce que tu disposes pour stocker ta géométrie ?

Citation:

---

Envoyé par LeGreg

déjà tu travailles par indices pour bénéficier des caches post transforms, ensuite tes données ne sont pas "fortement redondantes" mais redondantes uniquement sur les bords de chacun de tes "patches", tu peux former tes artistes pour réduire le nombre de patches et donc limiter la redondance mais c'est probablement de la suroptimisation surtout à ce niveau de détails et sur du hardware moderne.

---

Ca c'est e, théorie, parcequ'en pratique, pour optimiser ce genre de chose, il faudrait sortir à l'export des fichier des "subset" liés aux uvs et redondances... c'est que c'est loin d'etre évident comme manipulation, d'autant qu'apres avoir fait ça, il faudrait en plus creer des submesh interne au moteur... donc, en théorie c'est optimisable, en pratique, c'est un énorme casse tête...

Citation:

---

Envoyé par LeGreg

En fait tu fais ça simplement : si UV partagée, alors partage de données et si UV pas partagé alors duplication de données.

Tu disposes de combien de sommets par modèle ? combien de patches par modèle ? De combien de mémoire est-ce que tu disposes pour stocker ta géométrie ?

---

toutes ces questions sont ouvertes, il n'y a pas de restrictions précises... De combiens de mémoire je dispose pour stoquer les géométrie, je dirais autant que je veux, mais le but est de le réduire au maximum... or j'ai fais le calcul, pour un vertex standar il faut compter 32 octets (8 floats), ce qui nous amenne la face à 96 octets... Pour avoir une scene complexe, je pense qu'on peut largement friser les 200 000 faces... au final ça fait dans les 20Mo uniquement de géométrie...

Je ne comprend pas le problème qui pour moi n'existe pas, tu as plusieurs listes :
- Les vertex
- Les normales
- Les couleurs éventuellement
- Les coordonnées de textures UV

et ces tables sont utilisées via un index buffer qui peut trés bien utiliser plusieurs fois une même vertex evec des coordonnées UV différentes

je vois pas où est le problème, pas de redondance, pas de multiplication des vertex, pas de meilleures solution au niveau rapport performances / utilisation mémoire

Citation:

---

Envoyé par shenron666

Je ne comprend pas le problème qui pour moi n'existe pas, tu as plusieurs listes :
- Les vertex
- Les normales
- Les couleurs éventuellement
- Les coordonnées de textures UV

et ces tables sont utilisées via un index buffer qui peut trés bien utiliser plusieurs fois une même vertex evec des coordonnées UV différentes

---

JE ne vois pas comment tu fais, tu as un vertex buffer par élément ? comment coordonne tu le dessin des éléments ?... tu as un index buffer par élément (uv, vtx, nrml) ?

Citation:

---

Envoyé par shenron666

je vois pas où est le problème, pas de redondance, pas de multiplication des vertex, pas de meilleures solution au niveau rapport performances / utilisation mémoire

---

Le probleme de redondence apparait quand on doit stoquer et dessiner tout ce petit monde à partir de vertex et index buffer...

Citation:

---

Envoyé par Omeyocan

Ca c'est e, théorie, parcequ'en pratique, pour optimiser ce genre de chose, il faudrait sortir à l'export des fichier des "subset" liés aux uvs et redondances... c'est que c'est loin d'etre évident comme manipulation, d'autant qu'apres avoir fait ça, il faudrait en plus creer des submesh interne au moteur... donc, en théorie c'est optimisable, en pratique, c'est un énorme casse tête...

---

Donc ta question est :
- comment est-ce que je retravaille ma géométrie à l'export, pour ne dupliquer que les sommets qui en ont besoin ? Eh bien soit ton logiciel d'exportation te sort déjà les valeurs indicées dans un tableau indépendamment selon les UVs, les coordonnées des sommets etc.. Et donc ton travail consiste à dériver ces données pour obtenir un seul index par vertex et non plus N. Suggestion : si tu as (i1,i2.. in) qui définit ton sommet, alors tu effectues un tri radix sur les valeurs d'indices pour obtenir l'index final utilisable par ton hardware, et pour chaque jeu d'indice unique tu dois créer un jeu de données par vertex. Soit il ne te sort pas les valeurs indicées mais te sort une liste de triangle avec toutes les données dupliquées : pareil, tu effectues un tri radix mais sur les données de vertex. Quel que soit le cas tu peux (ou dois) reclasser tes résultats par classe d'équivalence (appartenance au même patch étant ta fonction d'équivalence) pour limiter les effets de la lecture aléatoire dans ton vertex buffer. Tu peux également réarranger tes triangles dans une même classe pour maximiser la réutilisation du cache de vertex post transforms à ce moment là (les classes helpers de D3DX font déjà ce boulot, voir l'exemple optimized meshes).

- Pourquoi est-ce que mon hardware graphique ne peut pas supporter l'utilisation de plusieurs index indépendants comme le fait mon logiciel X de modélisation/animation ? Tout simplement parce que l'un est du hardware fixe et à la programmabilité limitée et l'autre est un logiciel qui est constitué de code versatile et qui peut ainsi coller à une spécification arbitraire. Espoir : les hardware graphiques sont de plus en plus programmables et il est probable de voir arriver d'ici peu, des unités de vertex processing qui seront capables de fonctionner avec des indices indépendants selon le type de données, voire des indices issus de calculs (un peu comme les lectures de textures dépendantes dans les pixel shaders).
Ceci dit il ne faut pas toujours se réjouir parce que plus programmable veut parfois aussi dire plus complexe ;)

LeGreg

Citation:

---

Envoyé par Omeyocan

JE ne vois pas comment tu fais, tu as un vertex buffer par élément ? comment coordonne tu le dessin des éléments ?... tu as un index buffer par élément (uv, vtx, nrml) ?

---

oui et non, tu as 2 possibilités : des buffers séparés et un buffer entrelacé (interleaved)
je connais OpenGL mais pas direct3d donc je ne peux te donner un exemple qu'avec OpenGL

Code:

---

1 2 3 4 5 6

// active le VBO contenant des couleurs et des vertices glBindBufferARB (GL_ARRAY_BUFFER_ARB, g_uiBuffer); // Indique à opengl ce qu'il va trouver dans l'index buffer (3 couleurs suivies de 3 vertex) glInterleavedArrays (GL_C3F_V3F, 0, 0); // indique à opengl comment dessiner (primitive GL_QUADS) et quoi (le tableau d'indices g_ucCubeIndices) glDrawElements (GL_QUADS, 24, GL_UNSIGNED_BYTE, g_ucCubeIndices);

---

Citation:

---

Le probleme de redondence apparait quand on doit stoquer et dessiner tout ce petit monde à partir de vertex et index buffer...

---

C'est justement ce que je ne comprend aps, tu n'as pas de problème de redondance à moins que le fait de faire appel à une même vertice plusieurs fois signifie pour toi une redondance hors ce n'est pas le cas, de mon poitn de vue c'est similaire à appeler plusieurs fois une même variable dans un tableau