RESOLUE
Salut à tous.
J'aurais quelques petites questions au sujet des différents types de formats que supporte Irrlicht.
Aujourd'hui j'ai un projet en développement qui ses vite trouver assez gourmand en FPS.
Du coup je me demandais si entre les formats b3d, X, 3ds, md2, obj... il y en avait des moins gourmands que d'autre.
De même pour les textures : jpg, bmp, tga, png...
Aussi, j'ai entendu parler d'une rumeur que de les scènes crées avec Irredit sur les quel on gère ensuite les collisions serait plus lente que les scènes directement codée ! Perso je trouve çà bizarre mais je me trompe peut-être. Quelqu'un est au courant ?
Merci a tous ++.
Dernière modification par nabouill (07-10-2009 21:46:01)
Hors ligne
Pour les meshs animés utilise le b3d, les statiques les obj. par contre pour les textures moi j'utilise le png par habitude mais au niveau performance je ne pourrais pas te conseiller.
Hors ligne
Ca j'ai aussi rencontré des soucis de lenteur avec une 50ène de mesh md2 (genre 40 fps) !!!!
Mais je n'ai pas vérifié si le format était en cause .... je pense que oui ou alors Irrlicht est une usine à gaz (blague)
je te tiens au jus ..
Hors ligne
Merci por vos réponse.
J'utilise des b3d aussi pour les animés mes aussi des b3d pour les statiques, je vais les convertirs enobj pour voir. Par contre les textures, j'en ai essayer plusieurs formats, je ne vois pas de différence.
TUpac :
j'ai aussi rencontré des soucis de lenteur avec une 50ène de mesh md2 (genre 40 fps) !!!!.
C'est un peu mon problème. J'ai 1 perso avec un flingue qui court sur un terrain => 400-500 fps.
J'y rajoute 3-4 arbres => 50 fps !!!
je cherche....
Hors ligne
Quelle résolution tes textures sur tes arbres ? Nombre de polygones pour tes arbres ?
Hors ligne
Ok ben en ce qui me concerne Tmyke m'a donné la piste à suivre :
La texture des mesh était trop grande (détaillé). Dans ton cas des arbres y'a peut-être trop de polys.
Ceci dit je suis en opengl (à tester avec DX ! maybe que c'est mieux optimisé)
Dernière modification par TUpac (02-10-2009 10:33:50)
Hors ligne
OK merci je vais essayer ça.
C'est vrai que mes textures son en 512*512, je vais essayer de les modifier.
Et je ne sais pas en combien de poly son fait mes arbres, mais je vais essayer avec d'autre en obj pour voir.
Je vous tien au courant.
Hors ligne
Ok, ça a été un peu long mais j'ai mes réponses.
1_ J'ai creer un cube different formats : 3ds, b3d, obj, lwo, md2, stl, ms3d ,x et un cube directement dans mon code.
Puis j'en ai inclus 9 cubes de meme type dans une scene. et fait le test avec tous les types chacun leurs tour.
Résultat, aucun des formats est plus gourmand que les autres en FPS !! (j'aurais pas crue)
2_ j'ai refait le test avec Sydney et dwarf en format X, md2 et b3d. en jouant une animation
Résultat, il s'avère que le format X est le moins gourmand , en second le b3d puis le md2. (ceci ne ce joue que de quelques FPS, mais ça plus ça plus ça...)
Par contre je trouve le rendu plus jolie en X.
3_Test en y applicant different type de texture en différentes tailles. un PNG de 64*64 de 62ko et un TGA 1024*1024 de 4Mo.
Le résultat est exactement le même! il y en a pas un qui est plus gourmand que l'autre ! c'est juste un question de temps de chargement au debut.
4_ J'ai fait les meme scene dans un fichier .irr. Les performance sont exactement les même.
En faite mon problème vient des collisions. Beaucoup trop beaucoup trop. Une chance que Irrlicht a été améliorer la dessus sur la version 1.6. Plus j'ai changé mes types de collision sur certain objets, tout est entrain de rentrer dans l'ordre.
Merci pour votre aide, a+
Hors ligne
concernant les mesh statiques, il est normal que tu ne note aucune vrai différence de vitesse
suivant le format chargé, pour la bonne et simple raison que leur représentation mémoire est
identique. Donc, une fois chargé, pour Irrlicht, les mesh sont tous basé sur le même model.
Pour ce qui est des animations, c'est un petit peu plus compliqué.
Dans ce cas, Irrlicht garde les spécificités de chaque format. Par exemple, les format MD2 sont des
animations de type 'keyframes on a per-vertex level'. En d'autre termes, à chaque frame, le moteur
ré-actualise l'ensemble des vertices du mesh pour l'animer. Ce qui pour des model comportant un
bon nombre de faces, peut très vite être très lourd en terme de calcul, surtout si il y a pas mal
de model du même type à afficher.
Pour ce qui est des animation au format B3D par exemple (du moins dans la version supporté par Irrlicht),
la c'est différent. Une fois le modele chargé, il ne change plus. On se contente d'animer les articulation
des différents éléments en respectant la hiérarchie (skeleton animation). En terme de rendu, c'est notablement
plus rapide.
Hors ligne
Ok merci à vous pour vos analyses ça laisse à réfléchir pour gagner du FPS.
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 29 invités en ligne Aucun membre connecté RSS Feed |