Bonjour à tous,
 
voila je suis en train de développer un programme avec DirectX, il gère la souris le clavier, les lumieres ,le son et la 3D.....mais voila, sur certaines machines les frames par secondes sont faibles   (140 fps avec une GeForce 2 et 360 avec une GeForce Ti4200), c'est loin d'être Unreal Tournament 2003  
 
Comme il s'agit de mon premier moteur 3D je pense avoir du boulot sur l'optimisation. Est ce que quelqu'un à des conseils sur le sujet. Toutes vos astuces me seront utiles    
 
merci

Petites précisions, j'utilise des fichiers x, qui sont texturés, les lumieres sont omnidirectionnelles, et il y a une texture de 418Ko   , les textures sont-elles trop volumineuses ?

140 fps tu trouve ça faible ?
 
au dessus de 60 fps on fait vraiment pas la différence, alors moi je trouve ça pas mal quand même...
 
bon, évidement ton truc ça doit faire du 2 fps sur un ATI Rage Pro mais bon

Optimiser un moteur 3D, ca se fait comme pour n'importe quel autre programme :
- Arrange toi pour ne pas utiliser plus de memoire que celle que tu disposes. Que ce soit la memoire centrale et la memoire de la carte video
- Utilise un profiler pour trouver ce qui prend le plus de temps et optimises le
 
Repete le point 2 autant de fois que necessaire

Et bien non 140 fps ce n'est pas faible mais le jeu n'est pas terminé et mes fps vont tendre vers 0. Il est difficile de juger la quantité de travail a effectuer par la machine, je pense trouver cela faible etant donné ce qu'il y a l'écran.
 
Je ne connais pas les profilers, comment cela fonctionne et quels sont les plus pratiques  ?

Un profiler, c'est un programme qui te permet de mesurer l'allocation du temps dans ton programme.
 
Peut-etre va tu te rendre compte que 97% du temps CPU consome dans ton programme l'est dans une fonction de 300 lignes qui en fin de compte ne fait qu'une simple addition ( situation caricaturale )
 
Utilise google pour chercher un bon profiler. Si ca avait ete sous Linux j'aurais pu te repondre facilement

ok merci  

 
vtune d'intel, malheureusement limite dans le tps. Si je ne confonds pas il te permettait meme de juger de l'overdraw que tu as dans une scene, ca peut etre interessant. (bon au pire, ca tu peux le faire a la main, c juste du blending aditif)
 
AMD a aussi un profiler (code analyst) mais il a  jamais voulu marcher chez moi. Dommage parce qu'il est illimite, lui
 

Et la toute derniere etape si tu es vraiment pres a tout, qui necessite de porter ton code pour Linux ou d'attendre que le portage de l'outil soit fait :
 
- valgrind
 
C'est un outil d'analyse de l'utilisation du cache proc et qui sert aussi a detecter la bonne utilisation de la memoire.

je ne sais pas si je pret a cela, je vais y aller progressivement  

l'optimisation d'un moteur 3d est différent de l'optimisation d'un programme lambda.
 
les goulots sont liés au principe de la 3d.
donc fo:
 
1) chercher à éliminer ce qui n'est pas visible dans le champ de vision (tests par rapport au frustrum), ou caché par d'autres objets (portals de vision / d'occlusion), etc etc..
 
c'est d'abord l'architecture et l'organisation des structures qui priment (quake3 utilise une table PVS donnant la visiblité zone par zone pour rejeter rapidement ce qui n'est pas dans le champ de vision, ou caché, et se sert d'un arbe BSP pour calculer les collisions rapidement)
 
2) une fois que tu ne traçes que ce qui est "nécessaire", il faut traçer -rapidement-, pour cela:
 
a) rien d'autres que du vertex buffer+index buffer
 
b) on limite les changements d'états, on gros en réuni les primitives qui ont les mêmes propriétés matériaux/tetxures dans le même bloc
 
c) pour de bonnes performances géométriques, le flux d'index doit être optimisé vis à vis du cache Post Tnl (et Post Vertex Shader c'est le même).
en gros les triangles indépendants partageant les mêmes vertices doivent être traçés de manière contigu afin le cache Post Tnl fasse son office.
de la même manière une fois que l'index buffer est organisé de manière correcte, tu peux aussi réorganiser le vertex buffer afin que les vertexs utilisés ensemble soient contigus.
 
exemple:
 
flux non optimisé:
 
triangle 1 vertexs 64,63,60
triangle 2 vertexs 800,802,806
triangle 3 vertexs 65,64,7800
....
....
triangle 16, vertexs 0,1,8
triangle 17, vertexs 800,803,802
triangle 18, vertexs 7800,64,812
....
....
....
triangle 500, vertexs 0,1,2
triangle 501, vertexs 800,802,799
triangle 502, vertexs 7800,812,3
triangle 504, vertexs 64,812,200
....
....
 
flux optimisé au niveau index buffer (cache Post Tnl friendly):
 
triangle 1, vertexs 64,63,60 // 3 v transformés (1)
triangle 2, vertexs 65,64,7800 // 2 v transformés (3)
triangle 3, vertexs 7800,64,812 // 1 v transformé (18)
triangle 4, vertexs 7800,812,3  // 1 v transformé (502)
...
...
...
 
etc etc..
 
donc là on un flux optimal pour le cache post Tnl, car on a un réutilisation de vertexs déjà transformés.
 
flux optimisé index buffer & vertexbuffer (cache Post Tnl & cache "général" friendly):
 
on remappe les vertexs afin qu'ils soient contigus en espace mémoire:
 
64=>1
63=>2
60=>3
65=>4
7800=>5
812=>6
3=>7
 
ce qui donne au niveau index buffer:
 
triangle 1, vertexs 1,2,3
triangle 2, vertexs 4,1,5
triangle 3, vertexs 5,1,6
triangle 4, vertexs 5,6,7
...
...
...
 
les données du vertex buffer doivent donc être "défragmentées" on fonction de la table idéale.
 
ces optimisations des données est aussi valable en opengl, les pratiques sont les mêmes.
 
edit: j'avais dit une bêtise pour quake 3

la première clé est donc une question d'algorithmique:
 
"comment le objets de mon monde sont-ils organisés entre eux, comment puis-je rejetter ceux qui ne seront pas visibles rapidement et assez tôt"
 
et ensuite une question d'implémentation. "comment tirer un max de jus du hardware".
à partir de là fo se plonger dans comment fonctionne la carte 3D, et quelles fonctionnalitées te permetterai de booster en rendement.

normalement, ton modèle 3D ne doit pas être traçé quand tu il est est clairement hors du champ de vision.
donc tu peux faire un test sphere/frustrum, bounding box/frustrum.
 
par exemple perso je commençe par un test centre de sphere/frustrum
 
si le centre est dans le frustrum => on traçe
si le centre est à une distance supérieur de plus du rayon de la sphere => on traçe pas / entitée suivante
si le centre est à une distance inférieure au rayon de la sphere => on teste avec les boundings box du modèle, ce test rejettant alors ou pas le modèle 3D.

[bug]
Il a été démontré
que l'utilisation d'un trop grand nombre
de commentaires rallentissait les programmes
 
(trop de commentaires -> le programmeur passe son temps à les écrire, les lire et à les maintenir -> moins de temps pour optimiser -> programme plus lent)
[fin du bug]
 

 
nan serieusement juste drapeau..
je suis fatigué là..
 
LeGreg

En fait, la technologie BSP est deja consideree comme obsolete. En effet, les moteurs 3D les plus performants se doivent d'afficher des tonnes et des tonnes de polygones. Hors, si la scene a rendre contient tellement de ces polygones, le BSP devient tres complexe et trop lent a utiliser pour faire des calculs d'occlusion. En conclusion, la technique la plus efficace actuellement ( UT2003 et probablement Doom 3 a sa sortie ) est l'utilisation des portal/anti-portal. Ces derniers ne sont pas aussi utiles que les portal mais ca aide quand meme.

 
et l'Incremental Occlusion Map dans tout ca, hein ?

 
Et c'est quoi ca ?

 
http://www.hybrid.fi/dpvs_download.html
+
http://www.hybrid.fi/download/dpvs_manual.zip
 
C'est l'algo qu'on essaye d'implante dans notre moteur. Ca se base sur les Occlusion map de Zhang, tout en ameliorant les choses. Le choix des occluders se fait en re-utilisant les infos de la frame d'avant (autrement dit tu choisi comme occluder ce qui occlude reelement qqchose), ca essaye d'eviter au max de faire du boulot (ca hierarchise a tout va, delaie les operations au max.....)la doc est tres interessante, meme pour ceux que l'IOM interesse pas (dedans on trouve un algo d'extraction de silhouette utilisant la temporal coherence, par ex)
 
Plus ca gere les environnement completement dynamique en un tournemain

Et ca gere les scenes a tres grosse densite en polys tout ca ?

 
ils ont l'air de le dire. Les calculs se font sur base de modele degrade, leur implantation utilise une base de donne spatial pour rapidement degager tout ce qui est inutile sur les bords.
 
Couplé a des portals ca peut faire des ravages (occlusion de portals) (comme d'hab, les meilleures solutions sont generalement des melanges de bonne solution)