Hello, merci pour les corrections je vais tester ça dès que possible.
Pour le clignotement je pense que c'est plus un bug d'irrlicht, ça provient pas du shader (enfin chez moi ça ne le fait pas).
Hors ligne
Salut a tous,
bon ba j'ai testé le fait de retourner NbsTile pour la méthode GetMaterialCount() et de retourner CTTileBuffer[i]->Material pour la méthode GetMaterial(u32 i) et ca marche bien donc je pense qu'il faudrait le changer dans la classe de Copland a moins qu'il y ait des contre indication que je n'ai pas vue.
A+
Hors ligne
Salut,
quelqu'un a t'il deja essayer d'afficher les normals du terrain, j'ai l'impression qu'elle ne sont pas correct? (cad celle du bord de chaque tiles sont bonnes mais celle a l'interrieur des tiles on l'air fausse)
Hors ligne
quelle est ta methode pour afficher les normals ?
moi j'ai essayé avec la version d'origine de copland et effectivement j'obtient des grands trait horizontal le long du terrain et sur les bords j'obtient des truc bizard
avec la version que je suis en train de modifier les normals du terrain ont l'air correct mais sur les bord j'obtient des grands trait aussi
c'est aussi peut etre mon code pour dessiner les normals qui est pourri
Hors ligne
Salut,
je viens de trouver le bug dans la fonction de calcul des normal de Copland, voici un extrait de son code avec en commentaire la partie qui était incorrect et en dessous la correction :
// bottom right if (x<Size-1 && z<Size-1) { a = pMeshBuffer->Vertices[x*Size+z+1].Pos; //b = pMeshBuffer->Vertices[x*Size+z+1].Pos; b = pMeshBuffer->Vertices[x*Size+z].Pos; c = pMeshBuffer->Vertices[(x+1)*Size+z+1].Pos; b -= a; c -= a; t = b.crossProduct ( c ); t.normalize ( ); normal += t;
c'est la valeur de b qui était incorrect.
Je pense qu'il y a encore un autre bug car j'ai toujour des normal qui sont de trait grand très sous la map, je vais essayer de trouver d'ou ca vient si je peux.
Voila, pour l'affichage des normal, je vais te filer mon code mais bon je debute alors je suis pas sur que ce que je vais mettre soit un exemple a prendre :
// normals if (DebugDataVisible == scene::EDS_NORMALS || DebugDataVisible == scene::EDS_FULL) { video::SMaterial m; m.Lighting = false; Driver->setMaterial(m); for (u32 i=0;i<NbsTiles;i++) { if (CTTileBuffer[i] != NULL) { if( frustum->getBoundingBox().intersectsWithBox(CTTileBuffer[i]->getBoundingBox())==true) { f64 ActualDistance = CTTileBuffer[i]->BoundingBox.getCenter().getDistanceFrom(Pos); if(ActualDistance < RenderDistance) { video::SColor c ( 255, 0 ,0, 255 ); for(u16 j = 0 ; j < CTTileBuffer[i]->getVertexCount(); j++) { video::S3DVertex2TCoords v = CTTileBuffer[i]->Vertices[j]; core::vector3df h = v.Normal*100; Driver->draw3DLine ( v.Pos, v.Pos + h, c ); } } } } } }
j'espere que ca va t'aider.
A+
Hors ligne
bon merci pour le code d'affichage des normals c'etait bien le miens qui etait pourri.
par contre je vois pas trop la difference avec et sans ta modif.
ce que je trouve pas normal c'est que les normales :p s'affichent toutes verticalement, alors qu'elle devrait etre vertical par rapport aux triangles du terrain non ?
Dernière modification par Ikam (25-07-2007 23:35:59)
Hors ligne
Hehe pour les normals le code n'est pas de moi mais provient du code source du moteur de terrain d'irrlicht, je ne sais même pas si il est necaissaire de modifier les normals après la génération de mon terrain (à voir). Pour les afficher, le modelview du dernier irrlicht le fait donc doit y avoir une méthode déjà codé et qui à parament fonctionne bien.
Merci pour vos feedbacks .
@+
Hors ligne
j'ai testé avec et sans et je vois aucune difference si tu recalcul comme tu le fais les normals au moment de la generation ou si tu ne le fait pas.
Par contre je crois qu'il est quand meme nécéssaire de le faire pour orienter les normals car si tu le fait pas elles sont toutes verticales et ca je crois que c'est pas bon.
Sur la version que je suis en train de modifier je ne sais pour quelles raisons on dirait que ca marche correctement sans rien toucher aux normales et en laissant ta fonction pour les calculer elle sont bien orientées, exemples :
pas bon
bon
Dernière modification par Ikam (25-07-2007 23:38:29)
Hors ligne
Salut,
Je ne sais pas trop a qui tu parlais, la modif que j'ai faites dans la fonctions de recalcul des normals n'est pas correct?
Avec cette modif j'obtient un resultat qui ressemble a ce que tu as mis en bon.
Le seul problème qui me reste c'est que pour certains Tile (pas tous) il y a quelques points (les points indice 0,le premier, et indice 288=17*17-7, le dernier, pour un terrain de 256) qui ont une normal incorrect (de grand traits sous la map)
Sinon il restera encore un problème, c'est que pour les points qui sont double, (bord des tiles) les deux normal ne sont pas identiques donc je pense qu'il faudrait faire un passage juste pour mettre ces deux normals identiques (en faire la sommes et les normaliser).
D'ailleur on voit un exemple du problème sur ton image "bonne".
Nota : La modif que j'ai faites consistait a changer l'index d'un vertice qui était incorrect (il y avait 2 fois le même point).
A+
Dernière modification par ZeroZero (26-07-2007 09:52:05)
Hors ligne
salut ZeroZero
Je disais juste que j'ai vu aucune difference avec et sans ta modif. Faut il modifier juste la partie pour "bottom right" comme dans ton exemple ? sinon il faudra que je reteste avec le code original de Copland.
Tu dis que ta modif permet de resoudre le probleme comme quoi il y avait 2 fois le meme points ? ou qu'elle permet d'orienter correctement les normales ? car d'apres mes tests, le code d'origine, les orientes mal (image "pas bon" ) :p
Sur la version de CTerrain que j'ai modifier moi je n'ai pas besoin de retoucher comme tu le dit à la fonction calculateNormals pour que les normales s'affiche correctement. peut etre est ce lié à la generation du terrain ? concernant celle ci j'ai touché à 3 points :
- Accepter des heightmaps de taille 2^n+1
- Modifier la facon dont etait calculée la position des tiles car il y avait un probleme de decalage sur leur emplacements
- prendre en compte l'inversement de l'image pour generer le terrain dans le bon ordre
Sinon pour le reste je n'ai pas vu de grand traits sous la map, tout à l'air correct.
Et re-Sinon tu à tout a fait à raison pour les normales en double sur les bords des tiles et je suis d'accord avec toi sur le fait de faire la somme des 2 et les normaliser
Je referais des test dans journée si j'ai le temps ou sinon demain.
Dernière modification par Ikam (26-07-2007 10:39:21)
Hors ligne
Salut a tous,
Bon voila je pense avoir corrigé les autres problème de la fonctions CalculateNormal.
En faite le problème restant était toujours dans la partie "//Bottom Rigth". Le triangle dont on calcvul la normal n'était pas pris en compte dans le bon sens.
Voila la partie a remplacer dans le code :
// bottom right if (x<Size-1 && z<Size-1) { a = pMeshBuffer->Vertices[x*Size+z].Pos; b = pMeshBuffer->Vertices[x*Size+z+1].Pos; c = pMeshBuffer->Vertices[(x+1)*Size+z+1].Pos; b -= a; c -= a; t = b.crossProduct ( c ); t.normalize ( ); normal += t; a = pMeshBuffer->Vertices[x*Size+z].Pos; b = pMeshBuffer->Vertices[(x+1)*Size+z+1].Pos; c = pMeshBuffer->Vertices[(x+1)*Size+z].Pos; b -= a; c -= a; t = b.crossProduct ( c ); t.normalize ( ); normal += t; count += 2; }
Je pense d'après les tesyts que j'ai fait que le problème est maintenant résolu.
Reste donc a s'occuper des normals du bord des tiles pour les uniformisé avec les tiles voisins.
A+
Hors ligne
Options | Liens officiels | Caractéristiques | Statistiques | Communauté |
---|---|---|---|---|
Corrections |
|
xhtml 1.0 css 2.1 Propulsé par FluxBB Traduit par FluxBB.fr |
882 membres 1429 sujets 11119 messages |
Dernier membre inscrit: LiseBuisson96 36 invités en ligne Aucun membre connecté RSS Feed |