Stockage de la géométrie

[Kromagg]

Bonjour

Petite question concernant le stockage de la géométrie dans une classe Mesh.
J'ai vu différentes façon de faire. Certains moteur de rendu stockent les informations liées aux sommets (position, couleur, normale...) ainsi que les indices dans une classe Mesh via des conteneurs (std::vector) du genre

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class Mesh
{
public:
    Mesh();
    ~Mesh();
    ...
private:
    std::vector<Vertex> m_vVertices;
    std::vector<int> m_vIndices;
};

Et d'autres vont plutôt stocker directement des buffers du style

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class Mesh
{
public:
    Mesh();
    ~Mesh();
    ...
private:
    VertxBuffer* m_pVertexBuffer;
    IndexBuffer* m_pIndexBuffer;
};

Quelles différences cela fait-il exactement ?

Kromagg

Ben ca depend de la classe VertexBuffer. En theorie c'est peut etre seulement une classe similaire a vector.

mais je pense que c'est une classe qui encapsule des donnees GPU et la difference est donc que les donnees du mesh seraient stockees sur la memoire du GPU au lieu de la memoire du CPU.

[Kromagg]

Envoyé par screetch

Ben ca depend de la classe VertexBuffer. En theorie c'est peut etre seulement une classe similaire a vector.

mais je pense que c'est une classe qui encapsule des donnees GPU et la difference est donc que les donnees du mesh seraient stockees sur la memoire du GPU au lieu de la memoire du CPU.

Dans cet exemple il s'agit bien de données stockés côté GPU (VBO OpenGL par exemple). Quelle différence cela fait-il de stocker les données du mesh directement en mémoire GPU au lieu de la mémoire CPU ? Est-ce que c'est plus optimisé pour les transferts CPU/GPU ?

[LittleWhite]

Bonjour,

Comme le dit screetch, on ne connait pas vraiment ce que fait la classe VertexBuffer.

Sinon, si seulement les ID des buffers coté GPU sont gardés, cela posera une contrainte supplémentaire. En effet, il sera un peu plus dur de faire changer la mesh (que ce soit couleur, tex coord ou positions des points) facilement, si on ne garde pas toutes les données coté CPU. En effet, il n'est pas possible de lire les données du mesh stockés sur le GPU.

Ce que je veux dire par là, c'est que l'on est presque tout le temps obligé de garder les données de la mesh coté CPU (sauf si la mesh est statique et que l'on sait que l'on ne la mettra pas à jour et donc, qu'elle restera inchangée coté GPU).

Envoyé par Kromagg

Est-ce que c'est plus optimisé pour les transferts CPU/GPU ?

c'est plutot le contraire; ce qui est optimise c'est la rapidite de l'acces du GPU a ces donnees de vertex, donc c'est mieux pour le rendu
en revanche, ces donnees etant sur le CPU, chaque fois que tu veux les changer (en gros) elles sont rapatriees sur la memoire du CPU avant d'etre modifiees puis renvoyees au GPU, autant dire que c'est long.

en general il y a des mecanismes de double ou triple buffer qui sont ajoutes alors ce qui se passe precisement derriere l'interface VertexBuffer est tres difficile a comprendre.

[Kromagg]

Envoyé par LittleWhite

En effet, il sera un peu plus dur de faire changer la mesh (que ce soit couleur, tex coord ou positions des points) facilement, si on ne garde pas toutes les données coté CPU. En effet, il n'est pas possible de lire les données du mesh stockés sur le GPU.

Il me semblait pourtant que les fonctions comme glMapBuffer/glUnmapBuffer (avec flag GL_READ_ONLY) permettaient de récupérer le contenu de nos buffers et donc les données du mesh stockées sur le GPU.

[LittleWhite]

Oui en effet, j'avais oublié car je n'ai pas l'habitude de le faire (et dire que je me demandais comment faisait gDEBugger ).

Je pense que cela apporte quelques difficultés en plus, dans le sens, il faut savoir combien de données doivent être lues (donc la taille a du être conservée quelque part) et puis comme a pu le dire screetch, l'échange GPU <-> CPU a tendance à être lent, donc à éviter (éviter, dans le sens, en faire le moins possible).

[Kromagg]

Ok maintenant en rapport avec tout ça je vais prendre l'exemple de l'animation skeletal. Cette technique peut être implémentée de deux façon :
- sur CPU où tout les calculs sont effectués (transformations de bones et déplacement des sommets)
- sur GPU où la mise à jour des sommets est effectué via un vertex shader auquel on envoi les matrices de transformation du/des bones ainsi que les poids associés pour un sommet données.

Dans mon premier exemple comme les calculs sont effectués côté CPU je dois mettre à jour les données stockés sur le GPU (sommets). Dans cet exemple on voit bien l'utilité de stocker les sommets côtés CPU car en effet nous n'avons pas besoin de récupérer sur le CPU les données du GPU, de les mettre à jour puis de les renvoyer au GPU.

Dans mon second exemple les calculs sont effectués côté GPU, donc la je dois récupérer mes données stockées sur le GPU pour mettre à jour celle qui sont sur le CPU.

Dans ces deux exemples est-ce que les transferts CPU/GPU sont équivalents en terme de performances ?

[LittleWhite]

Dans le second exemple, nous ne sommes pas obligés de remonter les données au CPU. Je veux dire, que si le CPU veut continuer la transformation, il continue à modifier la matrice, le GPU continuera la transformation en application. (en fait la transformation coté GPU n'est pas du tout sauvegardé (les positions transformés sont calculés dans le vertex shader puis passés à travers le pipeline, mais ne sont pas mis en mémoire). Ainsi, il n'est même pas possible de récupérer les points transformés pour les redonner au CPU)

Il y a plusieurs types de vertex buffer qui sont organises differement selon ce que tu veux faire avec.
Tu peux specifier comment tu vas utiliser les buffer lors de leur construction et il y a en gros 3 modes (je soupconnes que la plupart des drivers n'implementent que deux, voire un seul...)
- read only, envoyes au GPU une fois et ne changent jamais
la plupart des meshs sont comme ca
- read-write, envoyes une fois de temps en temps au GPU pour rafraichissement
par exemple, la vegetation est comme ca; on stocke les mesh d'herbe dans un buffer et lorsque la camera bouge et change de region, on ajoute des donnees dans le buffer; mais on en ajoute pas toute les frame en general
- read-write, envoyes au GPU une fois par frame; il y a quelques donnees comme ca, qui sont generees sur le CPU a chaque frame, pour etre franc la j'ai pas d'exemple mais je crois que c'est legitime


en revanche, on ne lit (quasiment) jamais les donnees du GPU sur le CPU, ca se passe presque toujours dans la direction CPU->GPU.


dans ton exemple d'animation skeletal, tu envoies les donnees au GPU une fois (le squelette en question, dans une pose determinee) et le vertex shader se charge de transformer les bones a chaque frame selon les poses que tu envoies au GPU chaque frame. Donc dans ce cas, les VertexBuffer sont constants, mais il y a un Buffer (soit un groupe de variables Uniform, soit, encore mieux, un UniformBufferObject) qui est envoye au GPU toute les frame. C'est le cas optimal en general car le VertexBuffer est bien plus gros que le UniformBuffer, et que le GPU calcule les transformations de bone plus vite que le CPU.

[Kromagg]

Envoyé par screetch

- read-write, envoyes au GPU une fois par frame; il y a quelques donnees comme ca, qui sont generees sur le CPU a chaque frame, pour etre franc la j'ai pas d'exemple mais je crois que c'est legitime

La je pense que tu veux dire write-only ?

Envoyé par screetch

en revanche, on ne lit (quasiment) jamais les donnees du GPU sur le CPU, ca se passe presque toujours dans la direction CPU->GPU.

Je ne suis pas sur d'avoir compris cette phrase. Tu veux dire que l'on transfert les données du CPU vers le GPU (write) mais que l'on ne lit quasiment jamais les données stockées sur le GPU depuis le CPU (read), c'est ça ?

Concernant mon exemple d'animation squeletale, les sommets du mesh sont déplacés à chaque frame. Donc comment je fait si par exemple je veux mettre à jour la boîte englobante de mon mesh avec ces nouvelles données de sommet ? (calcul qui est effectué côté CPU quand je traverse mon graphe de scène)

Envoyé par Kromagg

La je pense que tu veux dire write-only ?

non, je crois que c'est plus facile si je dis:
cas 1: read often, write once
cas 2: read often, write sometimes
cas 3: read often, write often
les vertex buffer sont toujours lus tres souvent par la carte graphique

Envoyé par Kromagg

Je ne suis pas sur d'avoir compris cette phrase. Tu veux dire que l'on transfert les données du CPU vers le GPU (write) mais que l'on ne lit quasiment jamais les données stockées sur le GPU depuis le CPU (read), c'est ça ?

tout a fait

Envoyé par Kromagg

Concernant mon exemple d'animation squeletale, les sommets du mesh sont déplacés à chaque frame. Donc comment je fait si par exemple je veux mettre à jour la boîte englobante de mon mesh avec ces nouvelles données de sommet ? (calcul qui est effectué côté CPU quand je traverse mon graphe de scène)

je pense que c'est tres peu performant de transformer tous tes vertex sur le GPU puis de les transferer sur le CPU pour avoir une boite englobante. Le poin d'etranglement des applications c'est souvent le transfert de donnees, pas le calcul lui meme.

Je verrais deux ou trois solutions:
* une approximation ou on a une boite englobante trop grande qui est en gros la boite englobante maximale (on peut du coup la precalculer). Ce qui est souvent fait d'ailleurs, c'est de prendre la boite englobante du personnage non anime (souvent en position T) est la boite englobante maximale
* on calcule la boite englobante en animant quelques vertex, pas tous; on a un calcul beaucoup plus rapide evidemment. par exemple, un vertex de la main, un vertex du coude, les pieds, les hanches et la tete, et hop on a une boite englobante. animer 5 vertex c'est pas comme animer le perso entier
* on a une carte graphique evoluee et lorsqu'on transforme le vertex, on met a jour la bounding box sur le GPU et on transfere cette bounding box sur le CPU (c'est toujours couteux mais on est deja dans du plus acceptable)

peut etre il y a des gens plus creatifs que moi pour resoudre ce probleme cependant
moi je partirais sur la premiere solution, c'est souvent suffisant.

[Kromagg]

Envoyé par screetch

non, je crois que c'est plus facile si je dis:
cas 1: read often, write once
cas 2: read often, write sometimes
cas 3: read often, write often
les vertex buffer sont toujours lus tres souvent par la carte graphique

D'accord donc il s'agit des politiques OpenGL quand on créé un VBO.

Envoyé par screetch

* on a une carte graphique evoluee et lorsqu'on transforme le vertex, on met a jour la bounding box sur le GPU et on transfere cette bounding box sur le CPU (c'est toujours couteux mais on est deja dans du plus acceptable)

Et oui c'est une bonne idée, il s'agit ici de ne transférer que 2 sommets (24 octets) pour chaque mesh, je pense que c'est relativement acceptable.

Envoyé par screetch

peut etre il y a des gens plus creatifs que moi pour resoudre ce probleme cependant
moi je partirais sur la premiere solution, c'est souvent suffisant.

Ou alors on stocke directement la taille de la boîte englobante du mesh (pour chaque frame) dans le fichier mesh, comme c'est le cas pour les fichiers md5mesh de Doom 3 si je ne me trompe pas et puis on interpole côté CPU si nécessaire.

[LittleWhite]

Pour les boites englobantes, je me disais que la mise à jour n'avait pas à être effectuée nécessairement à chaque frame. Je veux dire, il se peut que le moteur de collision ou la mise à jour du monde soit plus lent que le nombre d'images par FPS. Mais bon, cette hypothèse est un peu faiblarde pour dire que comme ça on a "plus de temps pour calculer les collisions".

Sinon, on part d'une boite englobante qui est vraiment une boite englobante dans laquelle toutes les animations entrent (genre une grosse AABB/OBB classique).
Ensuite, on peut avoir des boites englobantes par ensemble de membre (genre, jambe gauche, droite, torse, tête), auquel on appliquerai les transformations pour les membres correspondants (ainsi, là, on a que 5 transformations à faire).
Ensuite, on peut faire un truc plus parfait ou l'on appliquera les matrices de chaque membre compris dans la sous section déterminée par le test précédent. Ainsi, on reste à un haut niveau de réalisme, tout en évitant de transformer toutes la mesh coté CPU.

Et si vraiment on a besoin de l'optimisation, on utilise un système de cache qui permet une fois la boite de collision du test 3 calculée, de ne pas la recalculée.

Enfin, c'était une proposition

(Si on utilise le GPU pour calculer la boite passante, ça veut dire obligatoirement que l'on dépend d'une frame, pour faire nos tests de collisions ?)

[Kromagg]

Envoyé par LittleWhite

Pour les boites englobantes, je me disais que la mise à jour n'avait pas à être effectuée nécessairement à chaque frame. Je veux dire, il se peut que le moteur de collision ou la mise à jour du monde soit plus lent que le nombre d'images par FPS. Mais bon, cette hypothèse est un peu faiblarde pour dire que comme ça on a "plus de temps pour calculer les collisions".

C'est vrai que la mise à jour du moteur physique ne se fait pas à chaque frame. Je crois qu'en général cette mise à jour se fait à un temps fixe, par exemple toute les x milliseconds. D'ailleurs si je prend l'exemple de Unity3D, il y a une fonction FixedUpdate spécialement faite pour ça.
Function FixedUpdate in Unity3D

Envoyé par LittleWhite

Ensuite, on peut faire un truc plus parfait ou l'on appliquera les matrices de chaque membre compris dans la sous section déterminée par le test précédent. Ainsi, on reste à un haut niveau de réalisme, tout en évitant de transformer toutes la mesh coté CPU.

Et si vraiment on a besoin de l'optimisation, on utilise un système de cache qui permet une fois la boite de collision du test 3 calculée, de ne pas la recalculée.

Je n'ai pas très bien compris ton raisonnement. Est-ce que tu pourrais détailler un petit peu plus ?

Envoyé par LittleWhite

(Si on utilise le GPU pour calculer la boite passante, ça veut dire obligatoirement que l'on dépend d'une frame, pour faire nos tests de collisions ?)

Oui je pense que l'on dépend d'une frame. Comme le moteur physique n'est pas mise à jour toutes les x frames mais toutes les x milliseconds on peut se retrouver à faire des calculs de collisions sur une boite englobante calculée 2-3... N frames avant, mais est-ce que cela pose vraiment un problème, je ne suis pas sûr.

[LittleWhite]

Je n'ai pas très bien compris ton raisonnement. Est-ce que tu pourrais détailler un petit peu plus ?

Le concept du cache ? ou le truc jute avant.
Enfin, bref, je vais essayer d'expliquer à nouveau.

Pour faire une détection encore plus précise, il faudra appliquer la transformation sur chaque membre animable / animée. Les premiers tests permet de faire une première approximation généraliste, ce qui permettra d'éviter de tester tous les membres un par un, mais de tester que les membres qui sont concernées (un peut comme dans les hiérarchie de partitionnement d'espace).
Ensuite, je parlais d'un système de cache. Car une fois que l'on arrive au membre à tester, il faut transformer tous les points (appliquer la matrice du mouvement, sur les points). Comme ceci peut être lourd, on va faire le calcul une fois et on gardera le résultat dans un cache afin de ne pas le recalculé une seconde fois, si en a besoin.

[Kromagg]

Je me demande également dans les jeux vidéo type FPS, est-ce qu'ils utilisent une boîte englobante générale ou est-ce qu'ils en ont une pour chaque partie du corps, ceci afin de faciliter les tests d'intersections lors des shoots ?

[LittleWhite]

Je pense qu'ils continuent d'utiliser les deux. La boite englobante, ça permet de faire des recherches de collision plus rapidement et les boites plus petites pour que cela soit plus précis. Et puis, ensuite une fois que l'on a eu la précision voulue, on peut faire un lancer de rayon (détection rayon / triangle) pour avoir une précision maximale.

pour la physique, il y a une boite englobante histoire de voir tres vite ou pas si il y a une collision possible ou pas.
si une collision est possible, en general le personnage est modelise (en physique, pas en rendu) avec des cylindres; un gros cylindre pour le corps, un cylindre par membre et une sphere pour la tete. seuls ces cylindres sont animes.
la detection de collision ne se fait pas souvent au triangle pres, car c'est trop couteux car il faut animer chaque triangle.

la boite englobante est souvent calculee au large, car c'est seulement une optimisation. c'est dunc un compromis entre le calcul de l'update de la boite englobante, et le gain pour les tests de collisions evites.

[Mat.M]

Envoyé par Kromagg

Quelles différences cela fait-il exactement ?

Kromagg

Salut je conseillerais d'utiliser la solution avec des std::vector
Si tu définis ceci

VertxBuffer* m_pVertexBuffer;
IndexBuffer* m_pIndexBuffer;

1 tu est dépendant de l'API graphique...
par exemple si tu utilises Direct3d comme l'API graphique change fréquemment tu seras obligé de réecrire du code.

L'important c'est de faire des classes génériques de géométrie 3d.

A ce moment-là il suffit d'appeler la méthode Dessine() ou Draw()d'une classe Video et là tu parcours les Indices et Vertices Buffer
2-de toute façon à l'affichage dans le rendu des objets tu seras obligé constamment de verrouiller les VertexBuffer et IndexBuffer pour accéder à leur contenu et dessiner
Parce que rien ne garantit que ces objets VB et IB aient une adresse mémoire constante,l'OS et la carte graphique peuvent très bien les déplacer en mémoire