Discussion :

[Wouzz]

Bonjour à tous.

Je débute en glsl, et j'ai bien entendu lu la doc et parcouru les spécifications, mais je ne trouve pas comment faire ce que je veux.

Je suis en train de réaliser un vertex shader et j'ai besoin d'attacher plusieurs informations à chacun des vertex de ma géométrie, que je puisse récupérer à chaque exécution du shader.
Dans le reste de mon programme ces informations sont stockées dans une structure, et je remplis un tableau avec des instances de cette structure - une pour chaque vertex.

Idéalement je voudrais donc pouvoir attacher un uniform à chaque vertex, ou un tableau d'uniforms à mon tableau de vertex de façon à ce que les données correspondent... ce que je ne sais pas faire... y a-t-il un moyen de faire ça? Ou un meilleur moyen de faire ce dont j'ai besoin?

J'espère avoir été clair...
Merci d'avance!

[adtunum]

si tu programmes cette partie à la manière forward-compatible les datas côté opengl seront générique et tu pourras y mettre n'importe quoi, c'est le shader qui décidera alors quoi en faire. tu utilises alors glEnableVertexAttribArray() et glVertexAttribPointer() :

http://bakura.developpez.com/tutorie...ec-opengl-3-x/

[Wouzz]

Merci , c'est exactement ce qu'il me faut!

Je découvre au passage que ce que je fais est deprecated... je vais devoir repenser mon shader, mais cette petite mise à jour ne fera pas de mal ^^

Merci encore.

[Wouzz]

Rebonjour,

J'ai une question concernant l'utilisation des attributs génériques : est-ce qu'il y a un moyen de les modifier dans le shader ??

Il me semble que non, et je ne trouve pas ça très pratique. Si je prend l'exemple d'une variable attribute vec3 vertexPosition (équivalente à gl_Vertex), tout l'intérêt du shader serait de ne pas avoir à modifier cette variable dans le code. Je voudrais laisser le soin au shader de mettre à jour la position de mon vertex, et de s'en souvenir à chaque frame. Si je dois faire tous les calculs de position dans le code, je perds toute la puissance du shader et du calcul GPU !

Est-ce que je me trompe quelque part? Y a t-il un moyen d'écrire dans les variables "attribute" ?

[Invité]

Non, par contre tu peux en envoyer de nouveaux à chaque frame dans un VBO sans problème.

Autre chose : la position (gl_Vertex) reste un attribut par défaut, il n'est pas nécessaire de le remplacer par un attribut générique. Puisqu'il n'y a pas de vertex sans position.

[Wouzz]

Non, par contre tu peux en envoyer de nouveaux à chaque frame dans un VBO sans problème.

C'est sur, mais du coup le temps de calcul se fait côté CPU et non GPU...

Autre chose : la position (gl_Vertex) reste un attribut par défaut, il n'est pas nécessaire de le remplacer par un attribut générique. Puisqu'il n'y a pas de vertex sans position.

Ben, c'est ce qu'il me semble aussi, mais le lien proposé par adtunum à l'air de dire que l'usage des attributs par défaut est deprecated depuis la dernière version...

[Invité]

En fait j'ai dit n'importe quoi, glVertexPointer est bien deprecated donc j'imagine que gl_Vertex aussi.

[Wouzz]

Ok ^^

[oxyde356]

Travaillant en GL3.2 et essayant d'éliminer tous les mauvais réflexes du pipeline fixe (il y en a beaucoup -_-), je commence à savoir ce qui est deprecated, je vais donc essayer de t'aider. Pour commencer, oui gl_Vertex est déprécié. Il faut maintenant définir un attribut pour la position de ton sommet et le passer à gl_Position dans ton vertex shader (c'est + lui que gl_Vertex qui définit la position vu que c'est un "out" du vertex shader).
Pour passer tous les calculs de positions et mise à jour du coté GPU il faut que tu utilise le Transform Feedback, c'est ce que te conseillé Ponce je pense sans nommée la fonctionnalité. En faite tu dois faire ce que l'on appelle du double buffering. Au lieu d'avoir un VBO (ou plusieurs) il t'en faut deux (respectivement le double). Avec le transform feedback tu vas définir les "out" de ton vertex shader qui vont définir de nouveaux sommets (en écrasant les anciens) et donc le VBO avec lequel tu vas dessiner va tout le temps changer (enfaite alterner avec un autre VBO). Quand tu voudras mettre à jour la position de tes vertex, tu utilisera le VBO 1. Le VBO 2 va recevoir les données à jour et tu vas afficher avec ce VBO 2. A la prochaine mise à jour tu utilisera le VBO 2 et c'est le VBO 1 qui recevra les données mises à jour, etc...

[coda_blank]

Travaillant en GL3.2 et essayant d'éliminer tous les mauvais réflexes du pipeline fixe (il y en a beaucoup -_-), je commence à savoir ce qui est deprecated, je vais donc essayer de t'aider. Pour commencer, oui gl_Vertex est déprécié. Il faut maintenant définir un attribut pour la position de ton sommet et le passer à gl_Position dans ton vertex shader (c'est + lui que gl_Vertex qui définit la position vu que c'est un "out" du vertex shader).
Pour passer tous les calculs de positions et mise à jour du coté GPU il faut que tu utilise le Transform Feedback, c'est ce que te conseillé Ponce je pense sans nommée la fonctionnalité. En faite tu dois faire ce que l'on appelle du double buffering. Au lieu d'avoir un VBO (ou plusieurs) il t'en faut deux (respectivement le double). Avec le transform feedback tu vas définir les "out" de ton vertex shader qui vont définir de nouveaux sommets (en écrasant les anciens) et donc le VBO avec lequel tu vas dessiner va tout le temps changer (enfaite alterner avec un autre VBO). Quand tu voudras mettre à jour la position de tes vertex, tu utilisera le VBO 1. Le VBO 2 va recevoir les données à jour et tu vas afficher avec ce VBO 2. A la prochaine mise à jour tu utilisera le VBO 2 et c'est le VBO 1 qui recevra les données mises à jour, etc...

les perfs sont vraiment boostées avec ça ?

edith : au passage, j'aimerais savoir si le binding de buffer est encore une opération couteuse à l'heure actuelle par rapport au draw call

[Wouzz]

Ah merci oxyde356, tes informations sont très intéressantes!

Sur le principe ça a l'air de bien correspondre à ce que je voulais, mais j'ai encore quelques petites interrogations.
Côté shader, il y a toujours une variable pour chaque VBO? Ou est-ce qu'on peut/doit utiliser une variable unique pour chaque paire de VBO? Dans les deux cas comment gérer l'alternance des VBO? Ensuite, quand tu parles de mettre à jour la position des vertex dans le VBO 1 ou 2, est-ce que ça se fait encore dans le code? C'est ce que je fais actuellement avec le buffering simple, et c'est ce que je voudrais éviter...

les perfs sont vraiment boostées avec ça ?

edith : au passage, j'aimerais savoir si le binding de buffer est encore une opération couteuse à l'heure actuelle par rapport au draw call

Questions tout à fait pertinentes! Ca m'intéresserait aussi de connaitre le gain qu'on peut attendre de cette méthode!
Pour tout vous dire je suis actuellement en train d'optimiser un moteur de particules déjà existant, en faisant passer le traitement de chaque particule dans un vertex shader. Le gain de temps processeur est donc la seule chose qui m'intéresse en fait.

Pour l'instant c'est pas encore ça.

[oxyde356]

les perfs sont vraiment boostées avec ça ?

Si tu parle de l'élimination du pipeline fixe, non je ne pense pas que cela améliore les performances. Si le pipeline fixe est enlevé c'est parce qu'il devient plus génant qu'autre chose. Avant pour faire de la lumière en temps réel on avait pas 36000 solutions, on faisait du vertex lighning, maintenant il existe le per-pixel et une infinité de parametres vu qu'il existe les shaders maintenant qui révolutionnent complètement la façon de concevoir une application graphique. Maintenant on part + de 0 qu'avant mais du coup vu que l'on a les shaders on peut faire vraiment ce que l'on a envie on est pas limité par un pipeline determiné, enfin si mais on peut le contrôler via les shaders alors qu'avant on ne pouvait que lui donnée des trucs en entrées et il nous donné des trucs en sortie et le shader était fixe. Donc enfaite, en prenant en compte que le développeur commence à être habitué au shader et à leur optimisation. On peut dire que supprimer le pipeline fixe est une amélioration de performance car le shader ne contiendra plus que ce que le développeur veut vraiment. Mais dans la majorité des cas il fera aussi des traitement bien plus lourd que ce que permettait le pipeline fixe mais avec les résultats bien plus appréciable qu'avant ^^
Maintenant si tu me demande si la mise à jour d'infos massives par double buffering et transform feedback améliore les performances je te dirais grandement oui, j'arrive à gérer plus de 1 million de particules en temps réel, chose que je ne peux pas faire juste avec un cpu ! Par contre de nouveaux problèmes ce posent si on veut gérer la collision par exemple. Mais plein de solutions sont en train d'être trouvés.

Côté shader, il y a toujours une variable pour chaque VBO? Ou est-ce qu'on peut/doit utiliser une variable unique pour chaque paire de VBO? Dans les deux cas comment gérer l'alternance des VBO?

Je ne comprend pas ta question ! Dans le shader tu ne fais aucune différence entre le VBO 1 et le VBO 2, pour le shader il traite toujours la même chose, des sommets qu'il faut mettre à jour. Par contre dans ton code source tu aura une variable booléenne ou un pointeur par exemple, qui gardera en mémoire le VBO courant, celui qui à les infos le + à jour.

Ensuite, quand tu parles de mettre à jour la position des vertex dans le VBO 1 ou 2, est-ce que ça se fait encore dans le code? C'est ce que je fais actuellement avec le buffering simple, et c'est ce que je voudrais éviter...

Non justement tout passe dans le vertex shader (voir geometry shader, si tu veux rajouter ou enlever des points, par exemple si tu veux faire des opérations de split & merge). Dans ton code tu active le tranform feedback et le vbo qui va recevoir les données, tu desactive la rasterization (qui est inutile vu que tu n'utilise pas de fragment shader), tu fais un draw call de ton VBO courant et là c'est ton shader qui fais le reste et au niveau CPU tu n'as rien à faire.

edith : au passage, j'aimerais savoir si le binding de buffer est encore une opération couteuse à l'heure actuelle par rapport au draw call

Je ne comprend pas bien ta question, le binding par rapport au draw call ? pourquoi comparer les deux ? surtout que dans le cas du drawcall il faut un binding de buffer. Mais pour de meilleur performances, éviter au max les appels à OpenGL dans tout les cas, si vous pouvez regrouper vos changements de renderstate, vos binds de buffer, vos drawcall via l'instancing, faite le.

Pour tout vous dire je suis actuellement en train d'optimiser un moteur de particules déjà existant, en faisant passer le traitement de chaque particule dans un vertex shader. Le gain de temps processeur est donc la seule chose qui m'intéresse en fait.

Moi aussi j'ai pour but de maximiser ce gain ^^ et la technique que j'ai décrite plus haut avec le transform feedback répondra à ton problème

[Wouzz]

Rebonjour!

Je ne comprend pas ta question ! Dans le shader tu ne fais aucune différence entre le VBO 1 et le VBO 2, pour le shader il traite toujours la même chose, des sommets qu'il faut mettre à jour. Par contre dans ton code source tu aura une variable booléenne ou un pointeur par exemple, qui gardera en mémoire le VBO courant, celui qui à les infos le + à jour.

Je m'explique.
Dans mon shader actuel j'utilise des variables attribute liées à des VBO uniques. Mettons que j'utilise à présent deux VBOs pour une variable, ma question était : est-ce que j'ai besoin de définir deux variables attribute au lieu d'une? De ce que tu dis je comprends que non.

Par contre je ne vois toujours pas comment mettre à jour mon attribute autrement que dans le code... Pour l'instant je mets à jour mes sommets en écrivant dans les variables gl_Position, gl_FrontColor etc... Mais pas moyen d'écrire dans les variables attribute, qui du coup ne sont pas mises à jour... Comment est-ce que ta méthode permet de contourner ce problème? Est-ce que je peux désormais écrire dans les attributes, dans le shader?

Si tu as un bout de code à me montrer, peut-être...

Non justement tout passe dans le vertex shader (voir geometry shader, si tu veux rajouter ou enlever des points, par exemple si tu veux faire des opérations de split & merge). Dans ton code tu active le tranform feedback et le vbo qui va recevoir les données, tu desactive la rasterization (qui est inutile vu que tu n'utilise pas de fragment shader), tu fais un draw call de ton VBO courant et là c'est ton shader qui fais le reste et au niveau CPU tu n'as rien à faire.

Merci beaucoup pour ces précisions. Je travaille sous OpenSceneGraph, donc ça doit surement être un peu différent, mais je vais déjà essayer ça et je reviens ici si j'ai des questions.

[oxyde356]

D'accord je crois avoir mieux cerné ton problème d'attributes. Enfaite il existe deux façon de faire pour utiliser les attributes, toi tu utilise la première façon qui consiste, une fois le shader linké, à demander à la carte graphique les index des attributes du shader et après tu les lient aux VBO. La deuxième façon que je te propose est de définir toi même l'index des attributs AVANT le link du shader et de réutiliser ces mêmes index pour tes 2 VBO.
Voila ce que je fais dans mon moteur :

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
CResEffect* effect = CResEffect::Create("mon_vertex_shader.vs");
V(effect->attribute("VertexPosition", 0))
V(effect->attribute("VertexNormal",  1))
V(effect->attribute("VertexColor", 2))
V(effect->link())
 
_meshPing = CResMesh::Create("mon_mesh.msh");
_meshPong = _meshPing.clone();
 
_meshPing->attribute(0, 3,GL_FLOAT,sizeof(CParticle), 0);
_meshPing->attribute(1, 3,GL_FLOAT,sizeof(CParticle), sizeof(glm::vec3));
_meshPing->attribute(2, 3,GL_FLOAT,sizeof(CParticle), 2*sizeof(glm::vec3));
 
_meshPong->attribute(0, 3,GL_FLOAT,sizeof(CParticle), 0);
_meshPong->attribute(1, 3,GL_FLOAT,sizeof(CParticle), sizeof(glm::vec3));
_meshPong->attribute(2, 3,GL_FLOAT,sizeof(CParticle), 2*sizeof(glm::vec3));

Pour moi un "effect" c'est un seul ou plusieurs program qui en une ou plusieurs passe forment un "effet", se référer au D3DXEffect même si on parle d'OpenGL
Donc quand je fais effect->attribute enfaite je fais :

Code :

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

glBindAttribLocation(_program, index, name.c_str());

Et quand je fais mesh->attribute enfaite j'enregistre les données passées en paramètre dans un tableau pour les restituer au moment de l'affichage de mon mesh en faisant :

Code :

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

1
2
glEnableVertexAttribArray(attribute.index);
glVertexAttribPointer(attribute.index, attribute.componentNumber, attribute.type, GL_FALSE, attribute.stride, (void*) attribute.offset);

Ce que l'on peut simplifier en utilisant un Vertex Array Object (VAO)
J'espère avoir été assez clair parce que c'est un peu délicat :p

[coda_blank]

D'accord je crois avoir mieux cerné ton problème d'attributes. Enfaite il existe deux façon de faire pour utiliser les attributes, toi tu utilise la première façon qui consiste, une fois le shader linké, à demander à la carte graphique les index des attributes du shader et après tu les lient aux VBO. La deuxième façon que je te propose est de définir toi même l'index des attributs AVANT le link du shader et de réutiliser ces mêmes index pour tes 2 VBO.
Voila ce que je fais dans mon moteur :

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
CResEffect* effect = CResEffect::Create("mon_vertex_shader.vs");
V(effect->attribute("VertexPosition", 0))
V(effect->attribute("VertexNormal",  1))
V(effect->attribute("VertexColor", 2))
V(effect->link())
 
_meshPing = CResMesh::Create("mon_mesh.msh");
_meshPong = _meshPing.clone();
 
_meshPing->attribute(0, 3,GL_FLOAT,sizeof(CParticle), 0);
_meshPing->attribute(1, 3,GL_FLOAT,sizeof(CParticle), sizeof(glm::vec3));
_meshPing->attribute(2, 3,GL_FLOAT,sizeof(CParticle), 2*sizeof(glm::vec3));
 
_meshPong->attribute(0, 3,GL_FLOAT,sizeof(CParticle), 0);
_meshPong->attribute(1, 3,GL_FLOAT,sizeof(CParticle), sizeof(glm::vec3));
_meshPong->attribute(2, 3,GL_FLOAT,sizeof(CParticle), 2*sizeof(glm::vec3));

Pour moi un "effect" c'est un seul ou plusieurs program qui en une ou plusieurs passe forment un "effet", se référer au D3DXEffect même si on parle d'OpenGL
Donc quand je fais effect->attribute enfaite je fais :

Code :

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

glBindAttribLocation(_program, index, name.c_str());

Et quand je fais mesh->attribute enfaite j'enregistre les données passées en paramètre dans un tableau pour les restituer au moment de l'affichage de mon mesh en faisant :

Code :

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

1
2
glEnableVertexAttribArray(attribute.index);
glVertexAttribPointer(attribute.index, attribute.componentNumber, attribute.type, GL_FALSE, attribute.stride, (void*) attribute.offset);

Ce que l'on peut simplifier en utilisant un Vertex Array Object (VAO)
J'espère avoir été assez clair parce que c'est un peu délicat :p

et comment remplis tu les VBO ? avec des struct ?

[oxyde356]

Tu veux savoir comment on remplis un VBO en général ? si c'est ça il y a plein de tutoriels qui traitent ce sujet.

[coda_blank]

Tu veux savoir comment on remplis un VBO en général ? si c'est ça il y a plein de tutoriels qui traitent ce sujet.

non, je veux dire est-ce que tu utilises un ensemble de struct prédéfinis à l'avance par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
struct PosNorm
{
     float x,y,z; //pos
     float nx,ny,nz; //norm
}
 
struct PosNormTexcoords
{
     float x,y,z; //pos
     float nx,ny,nz; //norm
     float s,t; //texcoords
}

ou bien tu laisses la possibilité d'utiliser une struct inconnue

[la_tupac]

Il semblerait que la meilleur solution soit un seul buffer avec une seule struct:

Code :

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

1
2
3
4
5
6
 
struct VboVertice{
     float x,y,z; //pos
     float nx,ny,nz; //norm
     float s,t; //texcoords
}

ensuite tu utilise le décalage quand tu déclare les vertexpointer normalpointer ...
ex:

Code :

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

1
2
3
4
 
int nb_elem_par_struct = 8; // taille du bond jusqu'a la prochaine normale
int place_dans_la_struct = 4; // position de la première normale dans le buff
glNormalPointer(GL_FLOAT, nb_elem_par_struct, place_dans_la_struct);

mais c'est de tête donc fix me please.

[oxyde356]

Enfaite il faudrait reposer la question de façon clair. Tu veux savoir comment on remplis les VBO dans le cas de l'utilisation du double buffering pour faire les mises à jour grâce à un vertex shader ? ou bien simplement comment on remplis un VBO basique ? Il y a différentes façon de remplir un VBO, tu peux si tu le souhaite faire des structures génériques comme celle que tu montre, ça marche très bien, sinon tu crées une structure spécifique, tu remplis un tableau de struct C et tu l'envoie tout entier au VBO. M'enfin comme je l'ai dis pose ta question clairement parce que là je sais plus de quoi tu parle si c'est du double buffering ou autre

[coda_blank]

Enfaite il faudrait reposer la question de façon clair. Tu veux savoir comment on remplis les VBO dans le cas de l'utilisation du double buffering pour faire les mises à jour grâce à un vertex shader ? ou bien simplement comment on remplis un VBO basique ? Il y a différentes façon de remplir un VBO, tu peux si tu le souhaite faire des structures génériques comme celle que tu montre, ça marche très bien, sinon tu crées une structure spécifique, tu remplis un tableau de struct C et tu l'envoie tout entier au VBO. M'enfin comme je l'ai dis pose ta question clairement parce que là je sais plus de quoi tu parle si c'est du double buffering ou autre

j'aimerais effectivement faire une structure générique qui varie en fonction des attributs qu'on lui affecte; j'aimerais également avoir plusieurs vbo par mesh contenant des structures différentes
par exemple sur un vbo j'ai les pos et les norm entrelacés et sur un deuxième j'ai juste les coordonnées de texture
C'est important d'avoir des structures flexibles aujourd'hui avec des techniques multi pass comme le deferred rendering (tu n'utilises que certains attributs à chaque passe, pas tous)