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 ?

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

TUpac Ecris:

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.

"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

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

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

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"

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

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.

TUpac Ecris:

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