Bonjour amis geeks,

Je fais un petit jeu avec irrlicht, et je me heurte à un problème de performance. En cherchant sur le net j'ai trouvé une fonction "magique" qui n'a de magie que pour les autres (pourquoi tout le monde m'en veut? XD), permettant de stocker les données d'un IMesh dans la mémoire du GPU et non celle du CPU (si j'ai bien compris). L'idée m'a séduit mais je suis passé de 10 fPS a 10.5 ... :s Voici la fonction : setHardwareMappingHint(EHM_STATIC);

Je n'ai pas mon code sous les yeux mais l'algorithme est le suivant :

pour tous les modèles de la map je fais
{
   IAnimatedMesh lMesh = sceneManaget->getMesh("modele.obj");
   lMesh->setHardwareMappingHint(EHM_STATIC);
   IAnimatedMeshSceneNode lModele = sceneManager->addAnimatedMeshSceneNode(lMesh);
   lModele->setPosition(vector3df pos);
}

Et pis c'est tout !

Voilà donc chaque élément du décor est dans un fichier séparé. Le truc c'est que c'est bien pratique pour les collisions avec les boundingbox.

J'ai pas une CG tip top mais elle me fait quand même tourner Oblivion avec les graphismes à fond et un fps correct.

Voici un aperçu du rendu avec un fps de 10 :

Qu'en pensez vous?

Merci d'avance

les vbo (ce que tu apelle le truc magic) améliorer les performence surtout sur les mesh qui sont composé de beaucoups d'élément, ça permait sur "suprimer" le rafraichissement des donner liez a ce mesh dans la ram de la cg
donc on gagne a latence car il n'y a plus le transfère entre la ram et celle de la carte graphique

seulement il y a plusieur chose qui rentre en compte au nievaux des performance, le nombre d'obj, le nombre de changement de matrice, le nombre de changement de matériaux ... etc
je me doute que les boundingbox sont utils, rien ne tempeche des les utiliser, mais rien ne tempeche d'utilise un "mesh" globale pour une seule entiter static
regarde sur le forum officiel, j'ai il n'y a pas si longtemp que sa un genre de "ICombenedSceneNode" qui prend en paramètre ton IMesh
il fait un genre de copy interne de ton mesh sur plusieur position, et tu te retrouve avec une seul entiter mais qui affiche une foret par exemple

après je ne veut pas être méchant mais t'est mesh ont laire super polygoner, sache que un personnage lowpoly est entre 1000 et 3500 polygonne
tandis que les obj de l'environement sont au alentour de 80-1200 polygone, ce n'est certainement pas le cas avec t'est sphere ...

bonne journé/soiré/nuit

edit: syntax

Dernière modification par Magun (18-06-2011 14:24:49)

Merci bien pour ta réponse. Si j'ai bien compris tu penses que le plus gros pb de performance est le fait d'avoir un modele par fichier?
Par contre j'ai pas trouvé de sujet qui pale de ICombenedSceneNode :s

Pour le décors le maillage est pas tres serré, mais bon c'est fait expres aussi je voulais du simple c'est pour ca que ca m'embette d'avoir peu de FPS.

absolument pas, un model par fichier est la marche a suivre, ce pendant rien ne t'empeche de faire de l'optimisation interne
comme bouger les entiter static directement sur les vertices et non via un changmeent de matrice, de même pour le matériaux

il te faut faire une class "manager" qui modifie la methode de rendue de ISceneManager de façons a regrouper les entiter par type l'or du rendue
tout les entiter static/light/skybox/skydome ensemble pour commencer, et les entiter dynamic a par également

un thread séparé pour OnAnimate peut-être intéressent également
ou une entiter composer d'entiter pour faire un "merge" de plusieur IMesh par exemple
ton sol semble composé de plusieur "plane" tu pourrais en utiliser qu'une plus grande, tu pourrais aussi te pencher sur le frustum culling ... etc

je ne sais pas si je suis très claire pour ton niveaux, demande si tu ne comprend pas certaine chose

Tu veux dire ecrire une classe heritant de ISceneManager pour redéfinir la fonction "drawAll" ? Je viens de vérifier dans la doc elle est bien virtuelle en tout cas cette méthode.
La fonction OnAnimate je vois pas, je l'utilise pas, c'est dans quelle classe?
Pour le sol je vais essayer un grand carré on va ptet gagner un peu en performance.
avec l'emploi de l'expression "frustum culling" tu viens d'ajouter des octets a mon dictionnaire interne cérébral ! En tout cas c'est cette idée la qui m'a fait utiliser plusieurs petits carrés pour le sol mais c'est vrai que pour l'herbe par exemple je pourrais utiliser un seul grand carré. En fait pour le décors je n'affiche que ce que qui est pres du perso (le reste je le vire de la scene) quand je bloque la caméra en vue de dessus, mais tu parles peut etre de gérer ca en redéfinissant les fonctions de rendu d'irrlicht j'ai l'impression.
En tout cas tu as l'air calé sur irrlicht, tu programmes des jeux aussi?

je t'indique plus ou moins l'optimisation que j'ai apporter a irrlicht pour mon engine
mon engine comporte 3thread ( OnAnimate, Sound, Network ), cela ma permis de gagner environs ~120fps suivant la scene

OnAnimate est une fonction interne de ISceneManager, elle permait de mettre a jours les position des objects d'irrlicht ( pour ma par j'y est incorporé la physique )
c'est une simple fonction qui appelle OnAnimate(irr::u32 time) des ISceneNode de la scene, en gros c'est pour les animation "ISceneNodeAnimator"

j'ai plusieur array d'entiter, une global (la scene), et plusieur autres, par type
quand j'ajoute ou suprimer une entiter je l'ajoute/vire de l'array global et celui référent a sont type
certain node comme le heightfield(terrain) on d'autre optimisation interne (quad-tree, lod) et des testes de frustum-culling interne que j'effectue dans OnAnimate
ce qui peut-être compliquer c'est de savoir quelle node est plus gourmand a rendre avec ou sans frustum-culling  (par exemple les débrits ou les particules)

oui j'est plusieur projet, (cf: signature), je programme depuis 4ans avec irrlicht

SleekThink: moteur 3d, sonord, ia, mul-thread, et tout le tintouin orienter sidescrolling game
ImmortalGalaxy: uhm, c'est sencer être un mmorpg nexgen, mais je bosse éssentielement sur le moteur

ex de mon heightfield: http://irrlicht-fr.org/viewtopicaim.php … 069#p10069

Oki, hé bien comme dirait l'autre a méditer la dessus je vais m'employer ! En tout cas c'est sympa de m'expliquer tout ca, merci merci ^^

Ah tiens j'ai une autre question ! Tu penses que le choix du format de fichier pour les modeles est important pour les performances?
Tu utilises quoi toi?

Le format des fichiers ne joue en rien sur les performances. Seul le type de format des vertex peut avoir une influence dans ce cas....

oki donc la ca ne depend que des fonctions du moteur qui chargent les modeles si je comprends bien.

Cela dépend du format des modèles...
Par exemple, si tu as que des modèles en simple texturing, cela ira plus vite niveau rendu que si tu avais que des modèles double texturing par  exemple...

Ah. Ben la je sais pas du tout ce que j'utilise. Je fais ca avec Blender d'ailleurs il me fait n'importe quoi au niveau des textures quand il exporte, il prends pas toujours en compte les modifs et tout. et y a pas trop d'explications sur le net sur comment faire du simple ou du double texturing avec Blender....

l'affichage des texture est représenter suivant des layers
chaque layer nécéssite une matrice spécifique, donc la tu fait le lien avec ce que je t'est dit présédament, plus il y a de changement de matrice plus c'est lent

sous blender, pour le maigre queje sache, c'est chaque texture que tu applique en temps que uv map est exporter et prit en compte comme niveaux de texture
tmyke dit double texturing pour simplifier sont explication, mais ce n'est pas limiter à deux, avec certaine technique tu peut très bien afficher une 100ene de couche de texture, mais le rendue n'en seras que plus lourd

il te faut donc optimiser tes mesh en conséquent pour utiliser le moins de layer possible ( en général 4 sufise largement (texture, glow, specular, bump) )

Dernière modification par Magun (22-06-2011 18:01:57)