Salut,
Voila je viens de terminer la programmation d´un jeu de Golf mais le probleme c´est que les perfs ne sont vraiment pas su RDV donc j´aimerais un peu l´optimiser pour qu´il tourne sur de moins bonnes becanes que la mienne.
Tout d´abord je voulais savoir si l´utilistaion des PickMatrix pour la detection de collision etait conseillee: balle qui touche un mur ou un bloc...
Les listes d´affichage c´est efficace et effectif sur les perfs?
Une difference de 100 entre les ZNEAR et ZFAR est ce beaucoup?
Les parties cachées par le FOG sont elles automatiquement non calculees?
Les Nurbs c´est vraiment gourmand?
Sinon si vous avez d´autres recommandations elles sont les bienvenues.
Amicalement.
 
PS:j´oubliais charger des objets WaveFront .obj c´est gourmand?

 
ca depend
 

c'est statique donc a la riqueur pour les petit objets...
 

non, faut pas rever , ca c'est a toi de le determiner, tu gagne juste en fillrate
 
c'est koi les PickMatrix ?

Decidement je reve debout:
Les parties cachées par le FOG sont elles automatiquement non calculees?  
non, faut pas rever  , ca c'est a toi de le determiner, tu gagne juste en fillrate  

-->il faut donc que je fasse un algorithme qui dise quels objets doivent etre affiches (ceux a l´avant du Fog et dans le point de vue)?
 
Sinon, le pickMatrix permet de specifier une fenetre pour faire de la selection graphique. au fait c´est comme si tu faisait correspondre un point de l´espace d´affichage a une fenetre de tres petite taille 5*5 par exemple. La OpenGL est capable de te renvoyer le nom des objets croises par ordre de profondeur.

ok, c'est ce qu'on appel aussi le picking, c'est ca?

 
oui, on appel ca le view frustum culling (le frustum c'est le champ de vision, plus precisement ce qui se trouve ds les 6 plans de la vue)

tu me conseillerais de le faire moi meme ou des algos existent?
Sinon, c´est bien le picking...

ya des algos qui permette de faciliter ce genre de traitement, en divisant l'espace
 
un algo de partionnement spatiale facile a mettre en place est le quadtree ou octree
 
octree c'est un peu plus compliquer mais reelement utile seulmenet si tu compte faire un view frustum culling en 3d, sinon si ton jeu ressemble plus a doom (cad que ton  monde 3d est surtout bati sur un niveau, si tu vois ce que je ve dire sinon c pas grave) utilise plutot un quadtree
 
le principe est tres simple, prenont le cas du quadtree :
 
tu vois c'est quoi un arbre binaire? ben la c'est la meme chose sauf que chque noeud a 4 fils
 
au depart tu consider un carre (axe sur le repere) qui englobe ton monde, et tu le divise en 4 autre carre (les 4 fils)
et tu fait ca recursivement jusqu'a aavoir atteint par exemple pour chaque carrer un nombre minimal de polygone
ton monde sera alors un quadrillage de carre de differente taille suivant la densité de polygone, et pour etablir un view frustum culling, koi de plus simple puisqu'au lieu de faire tes calculs complexe sur des plygone tu les fera sur un  simple cube axe sur le repere, c'est chouette non?

 
Pour etre vraiment efficace tu ferais mieux de detecter les collisions indépendamment de OpenGL et, mieux encore, d'utiliser une librairie spécialisée.
 

 
Les listes d'affichage sont ce qu'il y a de plus rapide.. (en terme d'efficacité CPU). Mais bien evidemment tout dépend ce que tu veux faire. Et bien entendu leur efficacité réelle dépend de ou se trouve ton goulot d'etranglement et comment est écrit le driver.
 

 
Franchement tu veux une réponse ?
 

 
Tout ce qui tu demandes de tracer est tracé.
Il n'y a pas de fonction magique qui devine que quelque chose est caché par le brouillard.
 

 
Tout dépend de l'utilisation que tu en fais..
Bien évidemment aucun hardware ne traite les nurbs en natif
donc c'est converti en triangles avant d'etre affiché.
 

 
...
 
LeGreg

 
Les liste d'affichage (display list) sont des series d'instructions qui sont compilées pour le driver ce qui les rend trés trés ... trés rapides à exécuter.  
Le problème c'est qu'étant compilées ces listes ne sont pas modifiables. Pour les modifier il faut les détruire et les recréer.  
Les display list sont donc à utiliser (à imposer !   ) pour tous les éléments statiques de la scène. Attention lorsque je dis statique c'est au niveau de l'objet... Par exemple pour une voiture assez complexe, on peut utiliser une DL et ne modifidier que la matrice s'appliquant en amont pour modifier la position... Mais là le défaut c'est que la voiture est considérée d'un bloc et donc tu ne peux plus bouger les roues .
Donc dans le cadre d'un jeu de golf, tu peux les utiliser pour tous les éléments statiques : arbres, batiments... etc...
 
ND

Salut,
ndela a tout à fait raison pour ce qui concerne l'impossiblité de modifier la géométrie d'une séquence englobée dans une DL.
Mais les performances sont assez bonne, surtout si tu utilise des routines "glBegin(...) glEnd()" pour tracer. Là tu gagnera  pas mal coté framerate, sans pour autant a avoir à partitioner ton espace (c'est chargé en polygone un terrain de golf ?).  
Il me semble qu'au niveau hardware, le fait de placer du code dans des listes d'affichage fait que les données géométriques vont transiter une fois par le bus, puis être stockées directement en mémoire GPU d'où le gain substentiel.
Après ça, tu peux aussi utiliser les tableaux openGL et indexer des vertices/normales/coord de texturs pour éviter d'être trop gourmand en mémoire. Par contre je trouve que l'utilisation de tableaux OpenGL offre un gain moindre qu'une liste d'affichage. Avec ces tableaux, tu peux par exemple tracer tout ton terrain en une seule commance (glDrawElements() où tu indique où se trouve le tableau d'indices, le nombre et le type de primitive à tracer (triangles, quads). Mais par dessus tout utilise le DL.
 
Un autre point qui peut jouer sur les performance est le texturing. Evite de tracer des faces "n'importe comment" mais essaie d'organiser le tracé de telle sorte à ce que tu es le moins de changment de texture possible (glBindTexture()). Car charger et décharger des textures a foison au lieu de tracer toutes les faces d'une texture donnée, puis passer aux face possédant une autre texture peut faire pas mal de différence à la sortie.
 
Vouala, il y a encore des tas de trucs, mais mes compétences se voient limitées.

Merci beaucoup les guys...
Reste une question fondamentale-> Le tracage d'objets complexes, pour cela j'aimerais loader des objets preexistants au format WaveFront par exemple (*.obj)
Mais le probleme c'est que je ne sais pas si c'est gourmand et quelle lib utiliser...

pour charger des .obj ? Moi preso je connais pas de lib. Tu vas lire directement deans les fichiers comme peut le faire nate Robins dans ces tutoriaux pour glut. Après c'est selon ce que tu veux prendre en compte.
Et la lecture de ces fichiers obj te permet de remplir ta structure de données (en gros tes tableau de vertices/coord de text/normale et tables d'indices aussi).
Tu peux également prendre en compte les matériaux. Si tu as 3DSMAX, t'as des plugins qui te permette d'exporter en .obj des modèles (et les matériaux avec un .mtl).
Y'a un plug OBJ2MAX et un autre MAX2OBJ sur ce site :
cadalyst.net
tu trouvera ça dans la section import/export dans la partie consacré à MAX 5.
Sur ce site t'as aussi des modèles tout fait (comme sur 3dcafe.com.
En espérant que ça puisse t'aider.
Ah oui, aussi, les fichier OBJ sont des fichiers textes, pratique pour le debugging. Pas comme les .3DS binaires (chais pas si il en existe des versions texte pour les misérables humains que nous sommes).