Charger une map q3 - Page 1

Lu, voilà on a fait avec des potes un chargeur de map q3, le probleme c que celui ci a un fps qui varie bcp meme avec frustrum etc...
Comment faire pour avoir un deplacement fluide sans accous, sachant qu'on utilise glut et qu'on veut un code 100% portable.
Merki

Ça varie de beaucoup, mais entre combien et combien environ ? Parceque j'avais aussi d'énormes variations sur certains niveaux, mais normalement ça ne doit pas casser la fluidité si tu calcules bien tous tes mouvements en fonction des fps (à moins qu'il ne descende vraiment trop bas, mais avec un loader de bsp en Delphi y'avait aucun pb pour les maps de Q3 donc en C/C++ ça devrait passer impec).

Disons qu'avec patch etc... ca varrie de 450 Fps à 70 en gros.

450 ça doit être une map bien vide
sinon heu ça me semble pas si anormal que ça comme écart, 70fps c'est peut-être un peu bas (c'est quoi ta machine ?), mais sinon en adaptant bien aux fps c'est pas fluide ?

non pas forcement vide suffit de bosser sous nux ou ya pas de synchro, ou desactver la synchro sous windows (sous mon ibook je teste meme pas vue comme ses machines sont lentes avec leurs cartes graphique d'y a 20ans..)
pour le 70fps, c une bonne machine pourtant :/
les sauts a 70 fps sont plutot rares.. donc limité le fps pour ca est plutot chian..
On arrive meme a descendre à 40 fps

A oui on utilise pas ARB et fonctionlike beaucoup plus rapide pour le lightmap car cablé, pour compatibilité avec les cartes non opengl.

Vivi je me doute bien que t'as désactivé le vsync sinon ça va pas voler bien haut le fps ^^
Sinon heu je sais pas, même ac un truc codé en delphi, et en activant tout, j'atteinds pas 40fps (ou alors sur des maps vraiment grosses, mais pas avec celles de base de q3). Essaie de voir si t'as autant de variations en désactivant la lightmap, et si oui c'est étrange, ds une même map ça devrait pas changer d'autant :/

Ca depend aussi du pc sur celui de test q3 tourne à 200fps de moyenne.
Et que la map soit grosse ou pas n'est pas forcement significatif.
En ce moment notre programme segfault :/ je peux essayer ton exec delphi?

Oula, ué mais pour ça faudrait que je le retrouve et c'est pas gagné (du tout ), v regarder si je l'ai encore sur un cd :/

ca peut venir de plein de trucs des ralentissements comme ca...
1- c'est quoi la carte sur laquelle tu teste (et le cpu)
2- c'est des a-coups comment? ponctuels? (la plupart du temps ca tourne a 450 fps, mais toutes les 2/3 secondes t'as une frame qui baisse a 70, avant que ca remonte a 450? ou bien c'est plutot du genre.. quand t'es dans un endroit de la map, c'est a 450, tu vas dans un autre, ca baisse progressivement a 200, tu vas dans un autre endroit, 70, dans un autre, 250, etc... ? (ou en fonction de vers ou tu regarde, bref..))
3- t'affiche quoi, et comment (avec quelles fonctions)
4- "A oui on utilise pas ARB et fonctionlike beaucoup plus rapide pour le lightmap car cablé, pour compatibilité avec les cartes non opengl." --> ta phrase la elle veut pas dire grand chose (a partir de "beaucoup" en fait), (et utiliser des extensions n'implique pas que ca marche pas sur des cartes qui les supportent pas).
5- vous utilisez le pvs je presume? (je suppose que oue sinon t'aurais pas dit que la taille de la map c'etait pas significatif
6- c'est du pinaillage, mais c'est "frustum" pas "frustRum", je faisais la faute ya un moment aussi
7- comme dit bob, si tes mouvements sont faits en fonction du temps de calcul la frame, (et ils devraient, ca date de la prehistoire des jeux et autres applis 3D interactives les timesteps fixes avec un fps variable), tu devrais pas sentir de grande difference de fluidite entre 450 et 70 fps (en supposant des changements de fps doux);
8- vous affichez les shaders? (si oui, tous? si pas tous, lesquels? en les desactivant y a tjrs ces a-coups?)
9- pas de 10

ca peut venir de plein de trucs des ralentissements comme ca...
1- c'est quoi la carte sur laquelle tu teste (et le cpu)
>>gforce 4ti4200 64Mo

2- c'est des a-coups comment? ponctuels? (la plupart du temps ca tourne a 450 fps, mais toutes les 2/3 secondes t'as une frame qui baisse a 70, avant que ca remonte a 450? ou bien c'est plutot du genre.. quand t'es dans un endroit de la map, c'est a 450, tu vas dans un autre, ca baisse progressivement a 200, tu vas dans un autre endroit, 70, dans un autre, 250, etc... ? (ou en fonction de vers ou tu regarde, bref..))
>> maintenant on est a 200 FPS stable lorsque l'on compile en mode release sous VC++ (apparement le mode debug accentue les variations.
3- t'affiche quoi, et comment (avec quelles fonctions).
Mesh patch et lightmap et un skybox bourin (+mini map)
4- "A oui on utilise pas ARB et fonctionlike beaucoup plus rapide pour le lightmap car cablé, pour compatibilité avec les cartes non opengl." --> ta phrase la elle veut pas dire grand chose (a partir de "beaucoup" en fait), (et utiliser des extensions n'implique pas que ca marche pas sur des cartes qui les supportent pas).
> cf mon prof:/

5- vous utilisez le pvs je presume? (je suppose que oue sinon t'aurais pas dit que la taille de la map c'etait pas significatif
on utilise BSP PVF FS et FFS, c'est le FFS qui accentuais ces petites chutes

6- c'est du pinaillage, mais c'est "frustum" pas "frustRum", je faisais la faute ya un moment aussi
> ty

7- comme dit bob, si tes mouvements sont faits en fonction du temps de calcul la frame, (et ils devraient, ca date de la prehistoire des jeux et autres applis 3D interactives les timesteps fixes avec un fps variable), tu devrais pas sentir de grande difference de fluidite entre 450 et 70 fps (en supposant des changements de fps doux);
apparement nous ca se sent un peu

8- vous affichez les shaders? (si oui, tous? si pas tous, lesquels? en les desactivant y a tjrs ces a-coups?)
> Non,

Enfin on a rendu notre projet hier, constatation final, il tourne moins vite sous linux que sous win (bien que les 2 aient les drivers off nvidia). Le chargement est remarquablement plus rapide sous Linux que sous Windows. Faut modifier l'alpha sous linux sinon beurk.
sous Windows j'ai essayé /03-> ne marche pas, faudra que je regarde la doc

"maintenant on est a 200 FPS stable lorsque l'on compile en mode release sous VC++ (apparement le mode debug accentue les variations."
oui forcement ca peut aider ^^

"Mesh patch et lightmap et un skybox bourin (+mini map)"
oui nan mais c'est pas ca que je voulais dire... la question etait peut etre pas tres claire aussi, dsl..
bon les lightmaps on s'en fout, juste pour ce qui est geometrie (triangles quoi), vous les affichez avec quelles fonctions Gl ?

"cf mon prof:/"
la vache c'est de lui ca? il sort d'ou??

"on utilise BSP PVF FS et FFS, c'est le FFS qui accentuais ces petites chutes"
FS et FFS == ?

"apparement nous ca se sent un peu "
si ca se sent un peu sans changement de fps brutal (ie: une frame a 400 fps, mais celle d'apres a 40, et celle d'apres a 200, etc...), c'est pas normal

bon apparemment t'en as plus besoin vu que tu l'as rendu, mais qd mm ^^

>>glDrawArrays(GL_TRIANGLES,0,pPatches[i].NbPolygons);
FFS: Frustrum pour les faces

mwai... ok.. (glDrawElements est mieux mais bon DrawArrays est quand meme moins pire que le reste, dc bon )
tu peux stocker ton bsp en vram aussi... ca accelere pas mal (cf l'extension des VBO)

Frustum (sans R ) pour les faces? ca c'est typiquement le truc qui sert a rien a part a ralentir... culler chaque feuille du bsp c'est _largement_ suffisant

dans 80% des cas c'est bénéfique... suffit de savoir quand l'activer

heu je te garantis que non
si c'etait du rendu software ok, mais la ca sert strictement a rien, la carte le fait deja, et c'est bcp plus avantageux d'envoyer de gros batches de triangles que plein de petits batches culles separement..
que t'affiche 500 triangles visibles ou 600 dont 100 non visibles c'est pareil.... (surtour que faire ca t'oblige a retransferer une nouvelle liste de triangles pour chaque feuille a chaque frame).
c'est aussi inutile (et ralentissant) que de chercher a culler les pixels dans un renderer software, et a eliminer totalement l'overdraw...

Dans notre programme, en tout cas si, d'ailleur c'est desactivable par menu constextuel de glut, et on voit tres nettement la difference.
d'ailleur dans tous les cas, on envoit qu'une liste à la cg

mouarf...
si il y a une quelconque difference de visible (et tel que j'ai compris ce que tu fais, j'en doute bcp, mais si tu dis qu'il y en a une de tres visible, j'ai peut etre mal compris), ca ne peut venir que du fait que dans les deux cas tu retransfere tout a chaque frame...

tu fais quoi exactement?
pour chaque feuille de l'arbre BSP, t'as une liste de triangles pour chaque materiau?
et a chaque frame, tu recuperes les feuilles de l'arbre qui sont dans le pvs et dans le frustum?
puis apres pour chaqune de ces feuilles, tu teste tous les triangles de toutes les listes avec le frustum pour construire des nouvelles listes qui ne contiennent que les triangles visibles?

si tu procedais de la meme maniere avec la methode d'affichage la plus efficace, ca te ralentirait. (de toutes facons tu ne pourrais pas vu que ta liste de triangles change d'une frame a l'autre)

oue bon ben c'est ca, cf mon post precedent donc

bein perso dans pas mal de map de quake, on a suprime bcp plus de faces... et on gagne en fps, alors apres va comprendre

c'est bien juste le face frustum culling que tu desactive pour tester? pas le face frustum culling et le frustum culling normal?
si vous gagnez en fps comme ca tant mieux (bien que la difference devrait pas etre si flagrante que ca, mais vous pourriez gagner bcp plus en ne faisant pas de frustum culling au niveau des faces, mais en stockant les feuilles en vram... (vbo)
et quand tes feuilles sont stockees en vram (largement plus rapide que de tout retransferer a chaque frame), culler les faces sur le CPU reviendrait quand meme a retransferer tout a chaque frame, donc d'un cote t'aurais un affichage avec toutes les faces blancees par frame et de l'autre toutes les faces stockees en permanence en vram, avec aucun transfert par le port agp...
c'est con que le projet soit fini, mais vous auriez du gagner pas mal en utilisant des vbo.

tes feuilles sont stockees en vram:
Nous dans tous les cas on retransmet tout il me semble :/ (ou alors j'ai pas trop bien saisi ce que tu m'as dit)
Pour le projet je le reprendrai peut etre, mais a partir de zero, car le code est assez crade quand meme.

oui ben justement c'est ce que je te dis
culler les triangles separement sur le cpu t'oblige dans tous les cas a tout retransferer a chaque frame. et faire ca, meme avec bcp de triangles en moins, sera bcp plus lent que d'avoir tout en vram et afficher des triangles supplementaires...

comment fait tu pour tout mettre en vram?

t'utilise soit les VBO (vertex buffer objects), soir les VAR si t'es sur une NVIDIA qui supporte pas les VBO mais qui supporte les Var, ou bien si t'es sur une NVIDIA qui supporte aussi les VBO, mais que t'as envie d'un tout petit peu plus de prefs... (ya l'equivalent des VAR chez ATI, mais les VBO c'est la version standardisee cross-carte )

t'as les specs des vbo dans l'opengl extension registry ici: http://oss.sgi.com/projects/ogl-sample/registry/
et plus precisement: http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

oky merci

heu mais ca suppose que toutes les feuilles tiennent dans la vram non?

que toutes les feuilles visibles tiennent oue, apres quand t'as une feuille qui est affichee mais qui est pas encore en vram, le driver s'occupe de l'y envoyer, et elle y reste jusqu'a ce qu'elle se fasse jarter, mais ca reste tres rare, surtout pour des maps comme celles de Q3, les vertex + texcoords + normales + indices + couleurs devraient largement tenir en vram, meme sur des cartes relativement anciennes...
(dr)

oky