Discussion :

[swain.dakota]

Bonjour,

je viens d'implémenter un loader de format IQM et j'en suis plutôt content puisque ça fonctionne super bien pour l'affichage(rendu normal + animation) d'un seul modèle.

Le soucis c'est qu'en essayant d'afficher 3 "entités"(chacune avec une animation différente ) avec un seul modèle(donc 1 seul VBO), je perds à peu près 1300 fps (pour une base de 1700 j'arrive à 3xx)

En effet le la fonction animate est appelée 3 fois à chaque tour de boucle, je ne sais pas trop comment faire autrement...en mettant un timer je descends à 1600 fps seulement mais l'animation est identique pour les 3 entités...

Quelqu'un a-t-il une idée ?

merci beaucoup

[Lintel-oo]

300 fps cela reste beaucoup.
Je m'étais déjà posé la question dans ce genre de cas et effectivement les fps diminuent très vite.
Mais pas de panique essaie d'afficher plein d'objets animés (plus que 3) pour voir si effectivement il y a un problème mais c'est fort probable qu'il n'y en ait aucun

[LittleWhite]

Bonjour,

J'ai l'impression que le ralentissement vient du code C++ (et non de l'affichage en lui même, donc non d'un bottleneck du GPU).
Est ce que le code de la fonction d'animation est optimal ? Peut être vous devriez le profiler.

[swain.dakota]

Merci pour vos réponses.

Alors Lintel-oo, j'ai essayé d'en afficher encore plus et je descends à 40 fps

LittleWhite, je pense que la fonction est optimale puisque c'est quand même le créateur du format qui la propose(le gars est plutôt bon dans le domaine donc je lui fait confiance).

Le truc c'est que c'est pas du c++ mais du D, mais je ne pense pas que ça vienne de là(je vais quand même vérifier )

Le fait d'apeller une fonction qui fait plein de calculs X fois par boucle ça me parait logique qu'au bout d'un moment ça puisse poser problème non ?

Sur un autre forum on m'a proposé de faire le "skinning" côté GPU, je pense donc que je vais aller voir de ce côté là.

Merci

[LittleWhite]

Bah, un coup de profiling confirmera les doutes, alors ...

[_gan_]

Salut, j'ai recemment eu le meme probleme que toi, (mega bottle neck Cpu au niveau des anims) Je l'ai resolu de la maniere suivante:

Deja en comptant les perf en ms/frame plutot qu'en frame/s : ca simplifit les calculs et on s'appercoit vite qu'un drop de 1300 a 300 ce n'est que 2 ms de plus, et que les problemes n'arriveront pas avant une dizaine d'entités de plus

Ensuite, tu peux threader si ce n'est pas deja fais, en ajoutant tout tes mesh a un pool et en faisant tourner un certain nombre de threads qui piochent dedans et font les calcul tu peux facilement doubler le nombre de vertices animés et liberer ton thread de rendu pour faire autre chose avec pendant que les threads se bouffes les calculs (OpenGL ne supportant pas le rendu depuis plusieurs threads, il vaut mieux degager le plus possible le thread de rendu pour pouvoir avoir un maximum de temps consacré a OpenGL)

Si tout ca ne suffit pas, l'ultime solution est de tout faire sur le gpu (dans les vertex shaders ou via OpenCL), il est prevu pour ca a la base !

Si tu fais du morphing, tu passe les positions des frames precedente et suivante en attribs pour les interpoler dans le vertex shader.
Si c'est du skinning, tu passes un array contenant toutes tes matrices au shader et tu passe un vecteur contenant les poids d'interpolation ainsi qu'un vecteur contenant les index des matrices a utiliser en attribs !

Si tu deplaces tes calcul vers le GPU, tu pourra animer une quantité astronomique de vertices sans probleme (100k passe impec chez moi)

En esperant aider, gan_

[MaximeL]

Si tout ca ne suffit pas, l'ultime solution est de tout faire sur le gpu (dans les vertex shaders ou via OpenCL), il est prevu pour ca a la base !

Si je me souvient bien, avec des drivers supportant openGL 4.3, y'a même plus besoin d'OpenCL grâce aux compute shader, même si ça me semble un poil disproportionné dans ce cas

Sinon, les threads, c'est super, mais bien garder en tête que c'est toujours dangereux si on a pas prévu une organisation inter-thread hyper clean. Le mieux étant d'avoir une organisaiton minimale permettant de rapidement isoler les problèmes éventuels (parce que débuger un problème de thread, c'est à s'en arracher les cheveux).

[_gan_]

Si je me souvient bien, avec des drivers supportant openGL 4.3, y'a même plus besoin d'OpenCL grâce aux compute shader, même si ça me semble un poil disproportionné dans ce cas

L'openCL c'est aussi de l'overkill pur et simple, mais au moins tu as l'avantage de pouvoir faire tourné tes kernels sur ton CPU si t'as pas une carte adaptée =D