tu utilises bien la version svn ?

essaye avec ce bout de code, ya pas grand chose a faire faut juste activer les vbo avec setHardwareMappingHint(scene::EHM_STATIC) pour le meshbuffer souhaité.

scene::IAnimatedMesh* node = smgr->addTerrainMesh("t1",
        driver->createImageFromFile("Media/color.jpg"),
        driver->createImageFromFile("Media/map.jpg"),
        core::dimension2df(10.0f,10.0f), 300.0f);


    scene::IMesh * mesh = node->getMesh(0);
    for(u16 a=0; a<mesh->getMeshBufferCount(); a++)
    {
        mesh->getMeshBuffer(a)->setHardwareMappingHint(scene::EHM_STATIC);
    }

    scene::ISceneNode * n1 = smgr->addAnimatedMeshSceneNode(node);
   
    video::ITexture * detailMap = driver->getTexture("Media/detail.jpg");
    n1->setMaterialFlag(video::EMF_LIGHTING, false);
    n1->setMaterialTexture(1, detailMap);
    n1->setMaterialType(video::EMT_DETAIL_MAP);

concernant le bug qui fait crasher la demo, j'ai posté un message sur ce sujet sur le forum officiel. Il en est retourné que le probleme viens de la fonction qui consiste à mettre a jour les buffers et les supprimer si ceux-ci n'ont pas été utilisés depuis plusieurs frames.

Le bug viens du fait que l'iterateur qui parcours l'arbre où sont stocké les buffers est cassé quand on supprime un element, alors qu'on parcours l'arbre.

Un membre a proposé une solution qui reset l'iterateur a chaque delete de buffer, ainsi l'iteration se stoppe quand y'a plus de buffer à supprimer, mais c'est pas tres optimisé puisque ca re-parcours l'arbre a chaque fois. J'ai proposé la solution suivante qui me semble plus efficace pour corrigé le probleme :

//! Update all hardware buffers, remove unused ones
void CNullDriver::updateAllHardwareBuffers()
{
    core::map<const scene::IMeshBuffer*,SHWBufferLink*>::ParentFirstIterator Iterator=HWBufferMap.getParentFirstIterator();

    irr::core::list<SHWBufferLink*> LinkList;

    for (;!Iterator.atEnd();Iterator++)
    {
        SHWBufferLink *Link=Iterator.getNode()->getValue();

        Link->LastUsed++;
        if (Link->LastUsed>200000)
        {
            LinkList.push_back(Link);
            //deleteHardwareBuffer(Link);
        }
    }

    // if there is some buffers to delete
   if(!LinkList.empty())
   {
      // delete all buffer in list
      irr::core::list<SHWBufferLink*>::Iterator it = LinkList.begin();
      for (; it != LinkList.end(); ++it)
      {           
          deleteHardwareBuffer((*it));
      }
   }
}

ps : quoiqu'il en soit les vbo sont toujours en phase de dev et de mise au point avant leur sortie officiel, donc tout ca risque peut etre de changer un peu et n'est valable que pour le moment pour patienter :p

Ca n'empêche que j'aimerai également voir et tester avec le code de ta démo car chez moi ça ne fonctionne toujours pas, comme marco à parament, et j'arrive vraiment pas à comprendre pourquoi :s.
J'ai même testé sur des démos d'irrlicht et ça change vraiment que dale.
Il n'y a pour l'instant que sur ta démo que j'ai vu une différence...A par le crash qui arrivait au bout de 2/3 minutes, lui je l'ai bien vu lol.

EDIT :
Voici mes résultats sur ta démo sur mon portable Core2Duo 1.67Ghz 3Go de ram et GeForce 8600M GS :
OpenGL Sans VBO = 226 Fps
OpenGL Avec VBO = 477 Fps
DirectX9 Sans VBO = 430 Fps

voici les sources:

sources demo

C'est bizarre que tu n'arrive pas a les faire fonctionner Copland puisque j'utilise ta classe de terrain pour la demo.

ps : la dll founi avec les sources est recompilé sans le bug de crash :p

Okay bein ça marche pas, je vois plus qu'une seule différence, c'est le compileur, à première vue tu utilises celui de VC++ et moi j'utilise GCC, mais si c'est ça, c'est carrément bizarre ou alors il y a quelque chose qui m'échape.
En tout cas merci pour la source ça m'a au moins permis de voir que ça déconnait pas dans mon code (ouf) .

Ok alors après une petite demi heure de test, voici mes constatations :
Irrlicht GCC avec ou sans VBO aucune différence mais 90 Fps de moyenne sur ma scene.
Irrlicht VC++ Sans VBO 57 Fps
Irrlicht VC++ Avec VBO 90 Fps
Les vbo seraient-ils activés par défaut sur irrlicht en compilation GCC ? Ce qui expliquerai le fait que je ne vois aucune différence sur mon jeu.
Honêtement je suis déçu des performances, je m'attendais à bien mieux, irrlicht reste quand même très lent en rendu c'est dommage.

mmm c'est bizarre

T'as essayé de desactiver les vbo en mettant setHardwareMappingHint(scene::EHM_NEVER); et de compiler sous gcc ? pour voir si ca donne la meme chose qu'avec EHM_STATIC. Si c'est le ca c'est que les vbo ne sont pas actifs.

Je ne vois pas trop le rapport entre le compilateur et les vbo.

Dernière modification par Ikam (04-05-2008 20:04:05)

ben moi avec mon matos pouris j'ai :

avec l'ati 9200 se :

gl sans 20 ( no texture )
gl avec 30 ( no texture aussi :s )
dx      112

et ma geforce 4 mx 4000 :

gl sans 44
gl avec 90
dx 67 (  si je regarde pas le terrain il ne se raffiche pas XD )

edit : je sais pas comment sa se fait cher moi d'habitude sous opengl sa plante sur le pc avec l'ati donc sa peut venir de la les textures menfin ...

Dernière modification par Magun (07-05-2008 11:30:16)

Salut tout le monde?

Alors on en est ou avec ses fameux vbo?

pour ma part j'ai changé de carte graphique (8800 GT DDR3 512Mo) et le vbo me font passé de 500fps environ à... 3000FPS (non y a pas de zéro en trop)

Ooooh yeah !
Ca passe on ne peut mieu sur ma ATI HD3850. Je passe en moyenne de 300 a 2100 FPS (OGL)

Y a vraiment un truc bizarre vu les différence entre les cartes...
Peut être des spécificité à ce niveau (mémoire embarqué/partagé, chipset,...)

Je pense surtout que les VBOs ne sont pas actif sur DirectX et donc ne font forcément aucun changement...

je viens de recompiler les sources avec code blocks et vc 2005 sa a l'ai de fonctionner, et il ny a pa d'écart de fps entre les 2 compilateurs je vais faire dotres tests