Besoin de lumières sur les VBO et le texturing s.v.p.

Salut, je me prends la tête depuis quelques jours a fouiller le web pour trouver un exemple de textures appliquées sur VBO et malgré les deux-trois codes qui correspondent à ma recherche, je n'ai pas réussi à les appliquer à mon projet.
En plus, je trouve des contradictions, sur l'utilisation des PBO par example. Un gazier me sort que mapper ses textures en PBO augmente les performances, un autre que le seul moyen est un shader pour texturer les VBO, et un autre raconte que l'API se charge toute seule de mapper les textures en Vram lors de la génération.
C'est pour cette raison que je fais appel à des gens compétents (vous :ccool:)
Pour résumer voila ou j'en suis:
Mes mesh sont affichés avec des VBO entrelacés (vertex,normale,texcoord) et sans textures ca marche à merveille.
C'est clair que je suis assez paumé mais si quelqu'un pouvait m'éclairer sur la bonne façon de procéder je lui en serais très reconnaissant.

merci.

Bonjour,

POur appliquer des textures ( dans un VBO ) ou un VBO en texture, c'est la même chose ( tuto N°6 de NeHe ).
Je veux dire que par là, il faut:

- Selectionner la texture
- L'appiquer ( tex coords )
- La deselectionner

Et voilà

Je ne vois pas ou est le problème ... ( à part si la texture est invalide ) ( on peut le savoir avec glGetError() )

merci White, tu confirme ce que je pensais. Mais la lesson 6 de nehe ne traite pas de VBO, seulement de rendu opengl standard. Et je n'ai pas de soucis pour texturer avec des glTexCoords().
Je ne sais pas si je suis assez clair donc mon soucis est que si je Bind ma texture (qui march niquelle), ca fonctionne avec un rendu glTexCoord();glVertex(). Mais avec un vbo, mon mesh est noir. Et mon mesh en vbo sans texture s'affiche bien.

De mémoire, je n'ai jamais fait de texture dans un VBO, mais je ne vois pas pourquoi il y aurai un problème, vu que VBO veut juste dire que l'on choisie une texture pour faire le rendu ( et non l'écran ).

Après peut être que cela crée conflit avec les différent selection des textures / textures utilisé par le VBO

Bonjour,

Citation:

---

vu que VBO veut juste dire que l'on choisie une texture pour faire le rendu ( et non l'écran )

---

eug je crois que tu confonds VBO et FBO Littlewhite:

- VBO = Vertex buffer object, pour stocker la geometrie
- FBO = Frame buffer object, pour faire du rendu offscreen ou dans une texture

Sinon la_tupac, pour afficher un object texturé avec les VBOs, il faut activer le "client state" correspondant, ansi que les pointeurs qui vont avec, et enfin le texturing:

Code:

---

1 2 3 4 5 6

glEnableClientState(GL_TEXTURE_COORDINATES_ARRAY); glTexCoordpointer(....); glEnable(GL_TEXTURE_2D); glBindTexture(....);   <dessin>

---

Tout a fait, les VBO servent uniquement à la géométrie.
En tout cas j'ai bien activé le client state mais le nom diffère un peut. (je pense que c'est une erreur de ta part).

Code:

---

glEnableClientState(GL_TEXTURE_COORD_ARRAY);

---

Mais en voyant ton example, une question me taraude: faut-il lancer glEnable(GL_TEXTURE_2D) après le EnableClientState ?
le BindTexture() aussi ?

:red: Oups ... j'ai confondu ( je me disais bien qu'il y avait un leger problème )...

Si je me rappelle bien ( bon ok, je n'ai pas prouvé mes talents ) le glEnable(GL_TEXTURE2D) devrait être activer surtout dans la phase dessin ...
( A verifié avec des glGetError() )

Citation:

---

En tout cas j'ai bien activé le client state mais le nom diffère un peut. (je pense que c'est une erreur de ta part).

---

Oui j'ai donné mon exemple de tête, ta version est la bonne.

Pour répondre à ton autre question: les "client state" sont à activer / desactiver une fois lors de l'initialisation, indépendamment de l'état de GL_TEXTURE_2D.

Ensuite, pour le dessin, tant qu'à faire bind ta texture au début, avant de passer les pointeurs vers ton tableau de coordoneees de texture.

Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

initOpenGL() { .... glEnableClientState(GL_VERTEX_ARRAY); glEnableClientState(GL_NORMAL_ARRAY); glEnableClientState(GL_TEXTURE_COORD_ARRAY); .... }   draw() { .... glEnable(GL_TEXTURE_2D); glBindBuffer(GL_ARRAY_BUFFER, m_vboIDs[0]); glVertexPointer(3, GL_FLOAT, sizeof(GLVertex), 0); glNormalPointer(GL_FLOAT, sizeof(GLVertex), (char*) NULL + sizeof(GLfloat) * 3); glTexCoordPointer(2, GL_FLOAT, sizeof(GLVertex), (char*) NULL + sizeof(GLfloat) * 6);   glBindTexture(....);   <dessin>   .... }

---

J'aurais dit que les client states doivent être aussi activer pour le dessin, sinon comment le programme ( enfin OpenGL ) sait qu'il faut dessiner tel ou tel truc.

merci pour l'example je pourrait tester ça en rentrant du boulot (bouh pas bien les forums au travail !! :oops: )
Mais moi je pensait comme White, que le clientstate devait être activé à chaque frame et pour chaque vbo

edit : tu as raison je viens de les virer rapidement et ca tourne toujours. Mais toujours pas en activant la texture. On vera ce soir ;) (bouh ! il code au travail! bouh !!)

Re,

Citation:

---

J'aurais dit que les client states doivent être aussi activer pour le dessin, sinon comment le programme ( enfin OpenGL ) sait qu'il faut dessiner tel ou tel truc.

---

Oui ils doivent être activés au moment du dessin, mais si, par exemple, à chaque frame on ne dessine que des objets texturés, inutile de le désactiver puis de le réactiver à chaque frame, on active le tout une fois et c'est bon.

Après, si le dessin mélange des objets texturés et d'autres non texturés, il faudra activer / desactiver les client state en fonction

Citation:

---

Envoyé par ShevchenKik

Re,



Oui ils doivent être activés au moment du dessin, mais si, par exemple, à chaque frame on ne dessine que des objets texturés, inutile de le désactiver puis de le réactiver à chaque frame, on active le tout une fois et c'est bon.

Après, si le dessin mélange des objets texturés et d'autres non texturés, il faudra activer / desactiver les client state en fonction

---

ça peut poser des problèmes de perf ?

Citation:

---

ça peut poser des problèmes de perf ?

---

Oui c'est ca: changer les états OpenGL est toujours relativement couteux, tous les articles sur l'optimisation de code OpenGL le disent: il faut toujours essayer de minimiser les changements d'état.

Par exemple si dans une scene on a 3 objets texturés et 3 non texturés, ils vaut mieux les regrouper pour n'"allumer" qu'une fois les etats necessaires à l'application de texture.

Après tout dépend de la scène, ce n'est pas toujours possible de regrouper efficacement.

Un truc à retenir: un état activé le reste tant qu'il n'est pas désactivé. Mais si on demande à un état actif de se RÉ-activer, il le fera (avec le temps que ca coute) alors que ce n'est pas necessaire...

Re ! Alors vous n'allez pas me croire mais il se trouve qu'en tant que linuxien convaincu, je n'avais pas touché WC++ :mouarf: depuis des années et pof! c'est le drame !!8O
Je m'explique: en rentrant chez moi je ne n'arrivais pas a croire qu'avec tout mes efforts le viewport restait noir. Alors (toujours n'y croyant pas) je doubleclic sur mon exe et un joli cube texturé apparait devant mes yeux grand ouverts 8O. Aurais-je révé ? ai-je consomé toute mon Ayahuasca en une nuit ? Et ben non ! sous WC ça reste noir. Je ne vois pas pourquoi car toutes mes données sont dans les sources (même texture) et en plus les deux exe sont au même endroit. Enfin voilà une nouvelle bonne raison d'adorer le merveilleu travail que nous offre gracieusement nos grands amis de Micro$oft :aie:
En tout cas merci à vous j'aurais appris que les clientstates n'ont pas besoint d'être activés à chaque rendu, ce qui me fera gagner du temps plus tard.
Allez pour la peine j'vais essayer d'aider d'autres posteurs.

bb

bonjour,

quand vous parlez de WC, c'est Visual Studio?

Un probleme récurrent entre les tests depuis Visual Studio, en lancant l'app en Debug, et un test "direct" en lancant l'exe depuis l'explorateur, ce sont les chemins relatifs, en particulier ceux des fichiers contenant vos texures.

Mais bon, si c'etait le cas vous veriez un cube blanc, pas un viewport complètement noir....

Sinon en Debug je sais que Visual Studio force l'initialisation de toutes les variables, ce qui peut donner des surprises quand on passe en release...

A part ca: ???....mais je ne suis pas sûr non plus d'avoir bien compris votre dernier post...;)

Tu peux me dire "Tu" je ne t'en voudrais pas, Mais je pense que tu es étranger et tu traduit les textes. C'est pour cette raison que tu n'as pas compris. Je parle en francais compliqué.
En fait comme je l'ai dis, rien à voir avec les textures (que j'ai inclues dans le code en static). Le soucis est la variable $(TargetPath) dans les options du debuger. Je l'ai modifiée pour être la même que la sortie de l'exe. Et tout va bien. Les linkings sont foireux je pense mais c'est comme tout les produits Grosoft, il faut connaitre les bugs.

Héhéhé non je suis francais, j'écris si mal que ca?? ;)))

OK pour le "tu", je préfère aussi!

Pour tes textures, tu veux dire quoi par "inclues en static"? Dans les ressources? ou bien tu as codé des tableaux de Glubyte comme dans les exemples de textures avec des carreaux noir et blanc?

Enfin bref, tant que ca marche hein...;)

héhé ! un fraçais à Munich !
Non tu t'exprime rien maistu me dis que tu as du mal à comprendre et tu habite Munich, la déduction était évidente ;)
Sinon tu écrit très bien pour un allemand :mouarf:
Pour donner plus d'infos, la variable qui me posait soucis était le dossier d'éxecution du débugage. La variable se nomme $(Target Path) et il a fallut indiquer le même répertoire que le dossier de sortie.
Je ne comprend toujours pas car aucunes données ne sont externes au programme (la preuve c'est qu'il marche sur nimporte quel windows).
Quand je dis que les données sont en static c'est le mot clé c++ dont je parle:

Code:

---

static const GLubyte texture[]={1,2,3,1,2,3,1,2,3}

---

En tout cas ça marche impecable et je peux avancer merci encore.