Discussion :

[Kurisu]

En fait, je me demandais ce qui était plus rapide dans l'execution:
glDrawArrays() avec une liste de vertices à afficher (de facon brute), ou
glDrawElements() avec une liste d'indices de vertices à afficher (facon triangle par triangle).

Au final, cela devrait représenter le même nombre de vertices à afficher, mais de l'autre côté, ca représente une utilisation de la memoire différente selon le modèle.
(Besoin de stocker plus de vertices (certaines étant recurrentes) dans le cas de glDrawArrays() et de devoir stocker moins de vertices mais aussi les indices dans le cas de glDrawElements(). Et encore, cela pourrait varier selon le modèle à afficher...).

Au passage, si je parle des vertex maps, c'est pour stocker les vertices directement sur la carte graphique.

[bafman]

[mode lourd] en OpenGL on ne parle pas de vertex map mais de vertex array ou vertex buffer objects (VBO) [/mode lourd]

techniquement, l'utilisation d'un tableau d'index est plus lente (besoin d'envoyer le tableau d'index, indexation et tout et tout). mais au final, la difference en temps d'execution n'est pas très importante, mais par contre, le tableau d'index sera nettement plus souple d'utilisation.
au final, si tu veux tout afficher d'un coup, inutil d'utiliser un tableau d'index, par contre, si tu souhaite pouvoir faire du clipping, le tableau d'index devient indispensable...

[Yno]

Ce topic tombe à pic, je me posais justement la question ces temps-ci, et...

techniquement, l'utilisation d'un tableau d'index est plus lente (besoin d'envoyer le tableau d'index, indexation et tout et tout)

oO

J'ai justement créé un algorithme dans mon exporteur wavefront pour créer des tableaux d'indices (tu vas pas tout me gâcher ), la création est certes longue (très longue) mais ce n'est pas grave, j'enregistre ensuite les données dans un fichier.
Avant j'utilisais aussi des suites de données, prévues pour des glDrawArrays, et mes fichiers étaient beaucoup plus lourd (un tier plus lourd).
J'ai aussi constaté une petite (mais nette) différence de performance avec l'utilisation de tablaux d'indices.
Dans mon livre sur OpenGL, il me semble qu'il est précisé qu'en utilisant glDrawElements OpenGL envoie moins d'informations à la carte graphique, je regarderais, là je ne l'ai pas avec moi.
Pour finir, Laurent parle d'utiliser des tableaux d'indices dans son tutoriel sur un moteur 3D, je n'ai pas la citation sous les yeux (et n'arrive pas à la chercher avec ce PC en 800*600 ), mais il me semble qu'il dit qu'il vaut mieux stocker moins d'information flottantes, au prix de quelques informations entières, et que celà améliorait les performances. (car les entiers sont plus rapidement traités)

Bon maintenant, ce qu'il en est réèlement, je ne sais pas, je dis ce que j'ai constaté et entendu.

A+

[Laurent Gomila]

Pour finir, Laurent parle d'utiliser des tableaux d'indices dans son tutoriel sur un moteur 3D, je n'ai pas la citation sous les yeux (et n'arrive pas à la chercher avec ce PC en 800*600 ), mais il me semble qu'il dit qu'il vaut mieux stocker moins d'information flottantes, au prix de quelques informations entières, et que celà améliorait les performances. (car les entiers sont plus rapidement traités)

Ce que je disais dans mon tutoriel, c'est qu'il vaut mieux dupliquer en mémoire vidéo quelques entiers (2 ou 4 octets) que quelques sommets (plusieurs flottants, soit potentiellement plusieurs dizaines d'octets).

Le gros avantage des indices aussi, c'est qu'ils permettent d'utiliser le cache vertex de la carte graphique, chose qui n'est pas possible avec une liste de triangles.

[Kurisu]

Le terme de "vertex map" était utilisé dans le tuto de G-truc.net, donc je l'ai repris.

Pour revenir sur le sujet, quelle serait la solution la plus optimale quant à l'utilisation de la memoire ?

Par exemple, si je veux afficher un cube, j'aurais 8 vertices et 12 faces (6 * 2, je triangulise). Je compte donc 3 indices par face, ce qui me fait une liste de 36 indices. Côté memoire, j'aurais donc 8 vertices (simple ou double précision, disons 4 octets), soit 8 * 3 * 4 = 96 octets et 36 * 2 = 72 octets pour les indices. Au total 168 octets.
Dans le cas sans index, ca me fait 3 vertices par face, soit 36 vertices, soit 36 * 3* 4 = 432 octets, plus que le double.
Seulement, j'aurais rarement des structures aussi faciles qu'un cube.

(Déjà, est-ce que mon calcul est bon?)

[Yno]

Je crois que ton calcul est bon, mis à part que tes indices sont des entiers codés sur seulement 16 bits, avec de gros modèles 3D ça risque d'être short (jeu de mot pourri)

Le truc n'est pas d'avoir une structure aussi simple qu'un cube, mais beaucoup de vertices indentiques.
Si tu as un modèle où tous les vertices sont différent, je ne crois pas que l'utilisation d'indices soit utile. (du moins pour un simple affichage)

[Kurisu]

Je me doute bien qu'un tableau d'indices ne servira nullement pour un gros champs de particules. Par contre, pour une mesh de triangles adjacents, j'aurai au moins 2 points en commun pour 2 triangles adjacents, donc, là oui, l'index sera utile.

[Yno]

Je me doute bien qu'un tableau d'indices ne servira nullement pour un gros champs de particules. Par contre, pour une mesh de triangles adjacents, j'aurai au moins 2 points en commun pour 2 triangles adjacents, donc, là oui, l'index sera utile.

A condition que les sommets soient exactement identiques, càd mêmes coordonnées de texture, même normale...
Par exemple, un objet non lissé a des triangles qui comportent chacun une normale différente, et dans ce cas l'utilisation d'indices sera evidemment plus un mal qu'un bien.