me revoila    
 
j'ai une scene que je voudrais l'optimiser car jai remarque que si un (grand)polygone masque une piece ou un objet opengl calcule qd meme ce qui se trouve derriere , ya moyen deviter ca ?

ben ça va peut être pas t'aider mais...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
...chais pas    

airseb a écrit a écrit : ben ça va peut être pas t'aider mais...           ...chais pas

 
 
ben au moins un qui repont    
 
enfait je crois que la technique sapelle occlusing
 
si ca interesse qqn je poste les images du moteur 3d pour linstant (gestion camera, textures, export 3dsmax, reflexion )

Tu fais des recherches sur l'occlusion culling, tes gros objet étant les occluders.
Mais bon, c'est pas forcement hyper rentable, et c'est pas l'optimisation à faire en premier à mon avis.
Bsp, portal, et pvs avant.
Tu va faire faire plein de calcul savant à ton processeur, pour dans le majorité des cas éviter de tracer au mieux 1000 polygones. Maintenant il faut mieux faire de l'optimisation grossiére, et avoir plein de fonctionnalitées, mais bon, c'est qu'une opinion.

 
   tu pourrais rapidement expliquer les mots la ?  
 
heu javais pense a afficher le niveau salle par salle (ex je suis ds la piece 1 (affichage piece 1 et 2) qd on passe ds la 2 (affichage de la 1 la 2 et la 3 (pour la transition) , ds la salle 3 : je laisse tomber la 1 ,....
 
 

Portal: decoupage de ton monde en cellule,
un objet étendu definit le lien entre deux cellules (portail)
a partir de ta cellule courante tu cherches quels sont les portails visibles (frustum culling) puis tu fais le test pour
chaque cellule suivante (en reduisant ton frustum d'autant au dela de ton portail).
 
PVS: potential visibility set. A chaque cellule tu associes une information de visibilité precalculée pour ne pas avoir a faire la traversée des portails a l'execution.  
Cela correspond a avoir une source de visibilité etendue pour chaque cellule, le moyen de le precalculer (ton ensemble potentiellement visible) est de passer par des portails mais a la compilation du niveau, meme si ce n'est pas la seule méthode.
 
LeGreg

Note:  
a l'heure actuelle, pour afficher un simple niveau quake 3
il est aussi rapide d'envoyer de maniere brute les polygones a la carte graphique que de mettre en oeuvre des techniques evoluees.
Cependant, avec un plus grand nombre de polygones ca peut s'imposer (exemple: le moteur d'occlusion Umbra/dPVS qui peut travailler sur des bases d'objets immenses)
 
LeGreg

bon voila un ptit screenshot :
 

 
 
bon ds le dessin ya une trappe (syst de ventilation) si par ex je rentre dedans puis je fait pivote de 180° (donc je suis a linterieur mais je regarde vers la piece) ben le framerate est le meme que ds la piece alors quil devrait etre plus haut  meme chose si je me cache derriere les caisses

red faction a écrit a écrit :        tu pourrais rapidement expliquer les mots la ?     heu javais pense a afficher le niveau salle par salle (ex je suis ds la piece 1 (affichage piece 1 et 2) qd on passe ds la 2 (affichage de la 1 la 2 et la 3 (pour la transition) , ds la salle 3 : je laisse tomber la 1 ,....

 
C'est une technique de portal, l'inconvénient c'est qu'il faut les placer "à la main", et donc avoir un éditeur.
La génération automatique a l'air plutôt difficile.
 
legreg, t'es sur pour quake 3? Le fill rate en prend quand même pas un gros cout?
(Doom 3 utilise des portal, et apparement pas de pvs et bsp(bsp juste pour les collision)).
 
Dans ton cas, si t'as une geforce, ca sera plus rapide de tout afficher que d'essayer de ne pas afficher ce que tu ne vois pas.
 
T'as pas beaucoup de polygones, tu va en éconamiser une 100éne, et de bouffer 10% du poc pour ca.
Pour comparaison, j'affiche 36 000 polygones en 220 images par seconde sur un 4200 (avec l'ani et autre qui tourne).
si c'est des otpimisations que tu veux faire, il faut que ce soit pour au moins 1000 poly minimu (et encore)
type une pièce entière.
 
 

 
par exemple ici pour savoir si lobjet est visible je reagarde les points x et z c ca ? faut que jabandonne mes calllists ?

euh la map de tes caisses elle est à l'envers

  heu oui  comment on fait pour retourner une map ds 3ds ? (je sais c facile mais je debute)

Une display list par objet.
Si tu veut faire du view frustrum de base, tu peux le faire  
sur les sphères englobantes ou sur les boites englobantes (AAB ou ooB).
Il y a plein de doc sur internet pour ca.
 
3ds max ?

red faction a écrit a écrit :     heu oui  comment on fait pour retourner une map ds 3ds ? (je sais c facile mais je debute)

aucune idée

C'est facil sous 3ds max :
Dans les materiaux tu clicke sur xxx.bmp, et ta ensuite des options pour faire des rotations.

 
Bien sur, j'exagere un peu, quand on affiche tout brut de fonderie le FPS en prend un coup (surtout dans les hautes resolutions). En plus dans une situation pratique, le PVS est tres rapide par rapport a d'autres methodes.  
 
Mais il reste qu'un niveau Quake 3 c'est de la gnognotte pour une Geforce3 et aujourd'hui on pourait faire un Quake 3 "jouable" quasiment sans PVS.
 
La photo qui suit, c'est un viewer Quake 3 dans mon framework:
comme je suis en dehors de la map, le PVS ne s'applique pas.
 

 
ps: je bouffe pas mal de mon fillrate avec l'effet de "glow" autour des lumieres mais ca diminue juste un peu les fps.
 
LeGreg

bon je viens de tester la methode frustum ds mon niveau a laide de boite englobantes ( jy ai rajouter pas mal dobjets),  et jai limpression de lavoir fait pour rien. jai pratiquement les meme fps avec ou sans (+-300 ds un mur et 50 qd je regarde les objets high poly)  
 
 
le pire c que opengl travaille encore mieux que laglo : alors que je naffiche un objets que si il est visible ou pas a lecran , opengl travaille par face (si un objet est a 1/2 visible ou entirement les fps changent )
 
ps : je me suis pas trompe, le nb dobjets affiche ds une boite de dialogue correspond a ceux sur lecran et jai teste les autres trucs...

 
Ah la, ca depend de ce que tu veux.... pour des trucs completement statique  a la q3, mieux vaut effectivement le BSP/PVS, par contre pour un evt plus dynamique l'occlusion m'as pas l'air mal du tout
En theorie on devrait faire ca dans notre moteur (enfin, pas la HOM, mais plutot IOM, cf le site de dPVS). Ne serait ce que pour le cote un peu "innovant" de la chose ca promet d'etre sympa
 

 
 
fo voir aussi comment tu traces tes faces ( a coup de glBegin/glEnd) ou quelque chose de plus fin ? (sous entendu : si tu fais ca a coup de glbegin va falloir changer radicalement ta methode )

chrisbk a écrit a écrit :       fo voir aussi comment tu traces tes faces ( a coup de glBegin/glEnd) ou quelque chose de plus fin ? (sous entendu : si tu fais ca a coup de glbegin va falloir changer radicalement ta methode )

 
 
oui je fait comme ca , avec un calllist pour chaque object et ca tourne pas mal 100 fps pour une piece avec 6 torus a 1500 faces sur un tnt2...
 
 
bon si ta une autre idee... explique

 
t'as les glDrawArray dray list et pour des perfs maximale fo se pencher du cote des extension proprio (cf site de nvidia / ati)

 
heu ouais, explique un peu plus

Les display list sont déja très rapide, mais ca bouffe beaucoup de memoire (tes 5000 glVertex/glBegin/glEnd sont dans la mémoire de la carte graphique)

 
 
ok donc si jutilise drawarray, ca reste ds la ram du pc ?? c ca ? et ca ira moins vite ? (ya aussi pas mal de glColor, GlBind ,etc que je met , en fait un tas de trucs qui faudrat rappeller ) et mon frustum ca changera qqch?
 
tu utilise quoi toi ?

Var tutorial:
http://www.uni-karlsruhe.de/~uli2/

pas mal, je connaissais pas, c ca le agp aperture size du bios ?
 
 
mias bon c une extention nvidia( _NV) donc sur les autres cartes  

Pour ATI t'as la même chose, mais j'ai pas encore essayé.

il n'y a pas de reponses a ta question. Quand tu auras atteint les limites des display lists, tu passeras aux vertex arrays c'est tout.
 
LeGReg