Salut, je suis en train de faire un petit moteur 3d utilisant des VBO avec des Index partagés. Pour ceux qui ne connaissent pas, c'est une méthode pour limiter la quantité de données envoyées à la carte graphique.
Mon soucis est que les coordonnées de texture s'appliquent à un vertex et non un index. Du coup j'ai deux faces sur mon cube qui ne sont pas correctes car elle ont deux (1.0, 1.0) ou deux (0.0, 0.0). De plus, les autres faces (qui sont texturées) sont inversée une face sur deux.
Une solution m'est venue immédiatement, c'est d'ajouter des vertex pour que les triangles ne partagent plus leurs vertex, mais ça augmente la quantité de données.
Je file mes buffers pour mon cube dessiné avec des triangles :

GLfloat CubePosData[] = { // Les vertex de 0 à 7 avec le logo des index
   -1.0f,-1.0f, 1.0f,
   -1.0f,-1.0f,-1.0f,
   -1.0f, 1.0f,-1.0f,    
   -1.0f, 1.0f, 1.0f, //   7----3
                      //  /|   /|
    1.0f,-1.0f, 1.0f, // 6-4--2-0
    1.0f,-1.0f,-1.0f, // |/    |/
    1.0f, 1.0f,-1.0f, // 5-----1
    1.0f, 1.0f, 1.0f,};

GLubyte CubeIndexData[] = { // les index
    1,0,2,
    3,2,0,
    5,6,4,
    7,4,6,
    7,3,4,
    0,4,3,
    6,1,2,
    5,1,6,
    3,7,2,
    6,2,7,
    1,5,0,
    4,0,5,};

GLfloat CubeCoordsData[] = { // Coordonnées dans le même ordre que les vertex
    0.0f,0.0f, 1.0f,0.0f, 1.0f,1.0f, 0.0f,1.0f,
    1.0f,0.0f, 0.0f,0.0f, 0.0f,1.0f, 1.0f,1.0f,
    1.0f,0.0f, 0.0f,1.0f, 1.0f,0.0f, 1.0f,0.0f,
    0.0f,0.0f, 0.0f,1.0f, 1.0f,1.0f, 1.0f,0.0f,};

Merci d'avance pour vos conseils.

Dernière modification par TUpac (09-09-2010 13:37:08)

Salut TUpac, tu utilises quoi comme fonction ? et avec quels paramètres ? j'ai bien envie de tester je te promets rien mais sait-on jamais.

glDrawelement () en mode triangle
avec les buffers vertex, Index, TexCoords bindés.
Ca ne se met pas en place en 5 minutes

Hum... Intéressant!! Dommage que j'ai aucune connaissance pour la prog C++, j'aurais aimé t'aider. Bonne continuation quand même^^!

merci quand même

TUpac :

Ca ne se met pas en place en 5 minutes

bein tu pourrais me passer ton code qui pose soucis histoire que je puisse tester vite,
sinon j'ai cru comprendre qu'avec les vbo, le coordsData ne s'utilise pas de la même façon...
genre plutôt comme ça:

0.00f,0.00f,    0.25f,0.00f,    0.25f,0.25f,    0.00f,0.25f,
...........

Code c++ :

enum // pour ne pas se mélanger les buffers
{
    vertex = 0,
    INDEX = 1,
    TEXCOORD = 2
};


//Cube Données

GLsizeiptr VertSz = 8 * 3 * sizeof(GLfloat);
GLfloat VertData[] = {
    -1.0f,-1.0f, 1.0f,
    -1.0f,-1.0f,-1.0f,
    -1.0f, 1.0f,-1.0f,
    -1.0f, 1.0f, 1.0f,

    1.0f,-1.0f, 1.0f,
    1.0f,-1.0f,-1.0f,
    1.0f, 1.0f,-1.0f,
    1.0f, 1.0f, 1.0f,};

GLsizeiptr IndexSz = 6 * 6 * sizeof(GLubyte);
GLubyte IndexData[] = {
    1,0,2,
    3,2,0,
    // gauche droite
    5,6,4,
    7,4,6,

    7,3,4,
    0,4,3,
    // face fond
    6,1,2,
    5,1,6,

    3,7,2,
    6,2,7,
    // haut bas
    1,5,0,
    4,0,5,};

GLsizeiptr CoordsSz = 8 * 2 * sizeof(GLfloat);
GLfloat CoordsData[] = {
    0.0f,0.0f, 1.0f,0.0f, 1.0f,1.0f, 0.0f,1.0f,
    1.0f,0.0f, 0.0f,0.0f, 0.0f,1.0f, 1.0f,1.0f,

    1.0f,0.0f, 0.0f,1.0f, 1.0f,0.0f, 1.0f,0.0f,
    0.0f,0.0f, 0.0f,1.0f, 1.0f,1.0f, 1.0f,0.0f,};


int BufferSz = 3;
GLuint BuffersId[BufferSz];

GLsizei VertexCount = 8;
GLsizei IndexCount = 36;


void End() // nettoyage de vram. Si tu oublies window$ devrait s'en charger..
{
    glDeleteBuffers(BufferSz, BufferName);
}

void Render(Vec3f *pos, Vec3f *rot) // fonction de rendu
{
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    glPushMatrix();

    glRotatef(rot->x, 1,0,0);
    glRotatef(rot->y, 0,1,0);
    glRotatef(rot->z, 0,0,1);
    glTranslatef(pos->x, pos->y, pos->z);

    glBindBufferARB(GL_ARRAY_BUFFER, BuffersId[vertex]);
    glBufferDataARB(GL_ARRAY_BUFFER, VertexSz, VertexData, GL_STREAM_DRAW);
    glVertexPointer(3, GL_FLOAT, 0, 0);

    glBindBufferARB(GL_ARRAY_BUFFER, BuffersId[INDEX]);
    glBufferDataARB(GL_ARRAY_BUFFER, IndexSz, IndexData, GL_STREAM_DRAW);
    glIndexPointer(GL_UNSIGNED_BYTE, 0, 0);

    glBindBufferARB(GL_ARRAY_BUFFER, BuffersId[TEXCOORD]);
    glBufferDataARB(GL_ARRAY_BUFFER, CoordsSz, CoordsData, GL_STREAM_DRAW);
    glTexCoordPointer(2, GL_FLOAT, 0, 0);

    glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_TEXTURE_COORD_ARRAY);
    glEnableClientState(GL_INDEX_ARRAY);

    glDrawElements(GL_TRIANGLES, IndexCount, GL_UNSIGNED_BYTE, IndexData); //RENDU !!

    glDisableClientState(GL_INDEX_ARRAY);
    glDisableClientState(GL_TEXTURE_COORD_ARRAY);
    glDisableClientState(GL_VERTEX_ARRAY);

    glPopMatrix();
}

// 2010 copyright all rights reserved. PTDR !!

Voilou ! je t'avoue que j'ai misèré pour allèger le code au milieu de la jungle qu'est mon projet ( tout comme mon appart )
Mais si tu connais opengl tu crées un ptit projet opengl de base et tu y ajoutes ça. N'oublie pas glew.h.
Sinon je n'ai pas compris dans quel ordre tu les plaçais car tu me donnes comme exemple la même chose que ma première ligne de coords sauf que c'est 1/4 de texture que tu affiches. (ou 4x je sais plus)
En tout cas si comme tu dis, les coords n'étaient pas dans cet ordre, ça expliquerait mes ennuis.
Merci.

Dernière modification par TUpac (09-09-2010 21:39:27)

ok je vais voir ça... après un gros café

edit, heu t'aurais pas le code du chargement des textures en affaire ? + la texture

t'as qu'à utiliser ça :
http://www-evasion.imag.fr/Membres/Anto … engl7.html
y'a une texture de drapeau à damier. Tu mets des texcoords à 8 pour répéter suffisamment.
merci de ton soutien

première chose il vaut mieux utiliser glDrawArrays que glDrawElement plus rapide, et plus orienté VBO ...
deusio tu ne spécifies pas de normale donc il est normal que les faces de ton cube ne soient pas correctement orientées

quand on définit des faces il y a un ordre ( "clock-wise" ou "counter clock-wise" ), et suivant le cas les faces sont tournées d'origine vers l'intérieur("counter...") ou l'extérieur ("clock-wise")

exemple: 'tiré de mon code pour un cube'

clock-wise:

counter clock-wise:

bon par contre tu notes que les vertices ne sont pas dans l'ordre donc les indices ... et puis bien sûr tu peux les "décaler"

Ok !! pour moi l'ordre des indices indiquait le coté visible du poly. Mais en quoi les normales jouent dans l'orientation de la texture ? Je pige pas trop ...
Sinon quand tu parles de "décaler", je pense que tu parles de buffers entrelacés "vvvnnttvvvnntt...." Je le mettrai en place quand tout marchera car c'est plus simple de bosser sur des buffers séparés (c'est mon avis).

Dernière modification par TUpac (10-09-2010 15:51:42)

heu tout ce que je vois c'est un triangle tout blanc, ne manque t-il pas du code là ?

Un seul triangle ?!!?
non je ne vois pas ce qui peut clocher....
vérifie le buffer "Index" ... et "IndexSz" surtout c'est lui que détermine le nombre de triangles affichés.

par rapport à ton code, j'ai juste rajouté glewInit() et le swap() qui était par défaut dans la démo codeblocks et enlevé le translatf et rotate sinon je voyais rien !?!
je pense donc qu'il manque des paramètres dans l'initialisation d'ogl ?
le plus simple c'est que tu me passes ton code copyright au moins j'ai pas à jouer au lego avec ogl

J'ai toute confiance en toi mais pas en toute personne parcourant internet.
donc MP !!
par contre y'a pô la fonction dans le forum. Et ton mail est caché dans ton profile

ps1:  c'est en vc++2010 désolé mais va falloire encore installer du crO$oft ... (intégration cg meilleur)
ps2: c'est plutot gros et en bordel donc pas de commentaires désobligeants stp
ps3: garde le pour toi stp.
psp : ça c'est une bonne console portable qui déchire

"Un petit dessin mal fait vaut mieut qu'un long post écrit par un débile."
Je regarde bien entendu ce que tu m'as dit Magun, mais en attendant si ça peut aider voilà un aperçu du problème.
Les flèches représentent le sens de la texture sur les faces des cotés. Le haut et bas ne sont pas texturées étant donné leur coords complètement absurdes.
Sinon je ne comprends pas bien en quoi les normales sont utiles en l’occurrence.
Je croyais qu'elles ne servaient qu'à la lumière et aux effets divers... pour le texturing je vois pas ..
Merci en tout cas.



Uploaded with ImageShack.us

TUpac :

ps1:  c'est en vc++2010 désolé mais va falloire encore installer du crO$oft ... (intégration cg meilleur)

bhou la honte hey !!! t'es passé du coté obscure de la force haha.
j'ai pas l'intention d'installer ce truc, mais je veux bien voir ton code pour voir ce qui me manque merci
je t'envois un mail pour que t'aies mon adresse.

Je précise juste que mon code est parfaitement portable mais si tu avais l'ide dont je ne dirais plus le nom à partir de maintenant, y'avais plus qu'a ouvrir projet avec le logiciel ù$^*^$ù$^:!$$:$:!. C'est tout

ps : wha! ziva la teuhon! comme il a trop abuzé tavu.

oui effectivement les normales jouent sur la lumière, mais de "base" comme je l'ai expliqué les "faces" ne sont pas forcément dans le bon sens, le fait de spécifier les normales évite deux choses, le problème d'une mauvaise orientation, et des calculs supplémentaires pour ogl, qui lui va les calculer à "l'arrache" suivant le sens de construction pour l'affichage, pour ce qui est des textures, et du double buffer, je ne sais pas vraiment, mais en tout cas au final, je doute que tu gagnes en espace ?

tu te retrouves donc, avec 2x vertices + 2x indices + 2x TCoord ? ou c'est séparé "impeccable" ? mais dans ce cas il est probable d'avoir de futurs bugs graphiques ...
je me demande d'ailleurs si tu veux bosser en "double buffer" ne serait-ce pas pour faire du multi-threading ? si c'est le cas je t'arrête tout de suite, tu seras obligé de faire un swap des contextes ogl, c'est pas bon pour les perfs, enfin ça pompe pas trop, tu me diras windows partage des données entre context ! oui mais non, tu veux du portable rapide non ?

bon je m'arrête la parce que ça fait pas longtemps que je bosse sous ogl ... donc ...
oh et sinon c'est pas la bonne façon d'afficher des VBO, là tu bind les data à chaque frame, fais des recherche tu verras tu peux faire un appel des données, ou plutôt tu dis à ogl où se trouvent les données, c'est les mêmes fonctions

Et ben dit donc, tu dis que ça fait pas longtemps pourtant tu as l'air de connaitre par coeur
En fait je copie à chaque frame car je prévois de faire un éditeur et en plus c'est plus light pour débuter. Je ferai un vrai vbo par la suite avec destruction des données en Ram juste après la copie en vram. Je finirai par utiliser 2 buffers, un pour les données Vertice*3:Normal*3:Texcoord*2, et un pour les indices.
Pour le moment j'ai mon Vbo non optimisé qui fonctionne et mes faces sont tracées dans le bon sens car j'ai activé le culling et tout est bien visible.
Pour le multithreading, sur une utilisation Gpu je préfère ne pas tenter
Sinon j'ai tenté glDrawArrays mais il me semble qu'il ne tient plus compte de mes indices, le traçage des triangles est anarchique. Ou peut-être faut-il lui binder un seul buffer avec toutes les données entrelacées ?

Dernière modification par TUpac (10-09-2010 23:44:19)

Coucou, j'ai enfin réussi à afficher le cube, je vois enfin le problème que t'as, en effet j'ai fait deux face opposées, et j'ai du mal à les relier, ça part en diagonale,
j'ai fait par exemple
0,1,2,   2,3,0,
4,5,6  ,6,7,4,
....et après c'est chaud
et là je cherche à faire la liaison, dans les exemples que j'ai vus sur le net ça utilise des indice et toi des index, c'est quoi la nuance ?
en tout cas j'ai appris plein de trucs

kikou ça fait plaisir que tu vois le soucis
Les indices et les index c'est la même chose (encore un mot francisé qui cause des confusions).
En fait je me suis bien rensigné et contrairement à ce que disait Magun, glDrawElements est plus performant car il utilise des index ce qui permet le partage de vertex.
Autrement dit, pour un cube, on déclare les 8 vertex de base.
Puis on déclare une liste d'indexs avec le numero de vertice (trois par triangle).
Et c'est ce partage de vertex qui fait que si un vertex est 1.0f 1.0f sur une face ne pourra pas être 0.0f 0.0f sur la face d'a coté.
Mais plus je recherche, plus je pense que Magun a raison sur les normales. il me semble que les texcoords les utilisent pour s'orienter.
Cependant, je galère toujours à les intégrer (certes je n'ai pas encore creusé beaucoup).
Sinon j'ai un doute sur ton post précédent, quand tu dis: "ça part en diagonales", tu parles des textures ou bien des triangles?
Car j'avais changé glDrawElements par DrawArrays (ce qui foutait le boxon).
Utilise le dérnier mail que je t'ai filé. Il est Codeblocks ready et sans erreures

Dernière modification par TUpac (11-09-2010 16:14:04)

Merci pour les précisions
il y a un encore un truc que je comprends pas, c'est pourquoi ogl texture automatiquement ma troisième face sans que je lui demande, regarde:

voilà, je ne comprends pas pourquoi il texture alors que je lui demande pas

Et ben c'est exactement la même chose que mon soucis. Les vertex qui sont partagées entre les faces sont utilisées par ogl pour texturer la troisième:

Et pour les faces de dessus et dessous c'est pire !

ok, je vais faire des recherches....