#25 

24-07-2007 18:36:13

Copland
Modérateur
Lieu: ZarbiLand
Date d'inscription: 22-09-2006
Messages: 657
Site web

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


Config : I5 2400, ATI HD6870 1Go DDR5, 4Go DDR3.
Single Boot : Windows Seven.

Hors ligne


#26 

24-07-2007 20:28:09

ZeroZero
Membre
Date d'inscription: 18-07-2007
Messages: 15

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


#27 

25-07-2007 20:24:20

ZeroZero
Membre
Date d'inscription: 18-07-2007
Messages: 15

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


#28 

25-07-2007 22:16:50

Ikam
Membre
Date d'inscription: 16-05-2007
Messages: 56
Site web

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 smile

Hors ligne


#29 

25-07-2007 22:27:46

ZeroZero
Membre
Date d'inscription: 18-07-2007
Messages: 15

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 :

Code:

 // 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 :

Code:

// 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


#30 

25-07-2007 22:50:47

Ikam
Membre
Date d'inscription: 16-05-2007
Messages: 56
Site web

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


#31 

25-07-2007 22:52:49

Copland
Modérateur
Lieu: ZarbiLand
Date d'inscription: 22-09-2006
Messages: 657
Site web

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 smile.
@+


Config : I5 2400, ATI HD6870 1Go DDR5, 4Go DDR3.
Single Boot : Windows Seven.

Hors ligne


#32 

25-07-2007 23:23:20

Ikam
Membre
Date d'inscription: 16-05-2007
Messages: 56
Site web

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


#33 

26-07-2007 09:33:53

ZeroZero
Membre
Date d'inscription: 18-07-2007
Messages: 15

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


#34 

26-07-2007 10:24:48

Ikam
Membre
Date d'inscription: 16-05-2007
Messages: 56
Site web

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


#35 

26-07-2007 20:12:14

ZeroZero
Membre
Date d'inscription: 18-07-2007
Messages: 15

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 :

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
irrlicht
irrklang
irredit
irrxml
xhtml 1.0
css 2.1
Propulsé par FluxBB
Traduit par FluxBB.fr
883 membres
1429 sujets
11121 messages
Dernier membre inscrit: Saidov17
123 invités en ligne
Aucun membre connecté
RSS Feed