Discussion :

[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 :

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

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 :

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

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

[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.

[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.

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).

[Kromagg]

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).

[screetch]

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.

[Mat.M]

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

[screetch]

Pourquoi l'important c'est des classes generiques?
a base de std::vector tu vas renvoyer des donnees a la carte graphique a chaque frame, ce qui est couteux mais aussi platform-specific qu'un VertexBuffer au final. Ca combine le plus lent et le moins portable...

[Kromagg]

Pourquoi l'important c'est des classes generiques?
a base de std::vector tu vas renvoyer des donnees a la carte graphique a chaque frame, ce qui est couteux mais aussi platform-specific qu'un VertexBuffer au final. Ca combine le plus lent et le moins portable...

Quel est ton avis alors ?