Charger une map q3 - Page 2

sBibi :
culler les triangles separement sur le cpu t'oblige dans tous les cas a tout retransferer a chaque frame.

C'est inexact. Tu peux très bien faire du culling sur une copie en ram des données, auquel cas le seul surcout dera dû uniquement à la répétition d'ordres de dessin plus petits au lieu d'envoyer juste un ordre pour tout dessiner. Si le nombre de polygones éliminé est suffisant, tu peux gagner pas mal.

hein?
j'ai peut etre mal compris, mais ce que tu suggere, c'est de:
- avoir tous les triangles sur la carte
- les avoir aussi en ram normale
- recuperer les triangles strictement visibles en faisant un culling sur la copie en ram normale
- dire a la carte de n'afficher que ceux la dans ce qu'elle a en vram?

si c'est ca, chuis mdr la ^^ tu peux aussi te faire un vertex buffer par triangle, culler sur le CPU, comme ca t'as un culling parfait
ou bien afficher tous tes triangles en software, comme ca t'aura pas de triangles de ta geometrie a transferer a ta carte ^2

Si le nombre de polygones éliminé est suffisant, tu peux gagner pas mal.

en prenant en compre le cout du culling de chaque triangle separe (tel qu'il le fait), le temps de transfert via un port AGP, le cout ridicule qu'a le traitement de vertices indexees, et le cout de chaque draw call, certainement pas non

Non justement ce que je propose élimine le transfert des données.
C'est pour ça qu'il n'est pas impossible que ça fasse gagner du temps.
En tous cas par rapport à ce qu'il fait actuellement c'est sûr que ça va faire gagner du temps.

oui j'ai bien compris que ca "eliminait" les transferts des donnees (ce que tu proposes correspond bien a ce que j'ai mis au debut du post?)
si j'ai cite les transferts de donnees en bas, c'est justement pour egalement prendre en compte le soit disant "gain" qu'ils t'apportent, et meme en prenant ca en compte... non.
ca ira peut etre un peu plus vite que sa methode actuelle dans certains cas (et encore, avec le surcout des draw calls j'en doute _bcp_), mais bcp plus lentement que d'afficher de gros batches.
le cout de culling des triangles non visibles sur le GPU est ridicule compare au reste hein... (bon OK ca depend des GPU sur certains vraiment vieux c'est probablement moins marque compare au reste, j'en sais rien, mais sur la carte qu'il a mentionnee, et jusqu'au dernieres, c'est ridicule comme cout.)
et le truc c'est que faire ton culling de x triangles sur le CPU ira certainement bcp plus lentement que laisser le GPU culler ces x triangles (oui meme avec un CPU a 4GHz et un GPU a 450 Mhz)
donc tout ce que tu gagne c'est des draw calls en plus.. (ouee )

Je suis d'accord. Mais ce que je propose a l'avantage de ne pas changer beaucoup sont programma actuel. Pke pour faire propre sinon il faut qu'il modifie beaucoup de choses.

peut etre, c'est a essayer, mais je doute que le surcout des draw calls supplementaires permette un quelconque gain, ca serait plutot l'inverse (sauf certains cas particuliers, mais tellement rares en pratique qu'a mon avis ca servira a rien sinon ralentir... enfin si il veut essayer...)
et heu, pour faire propre... il faut quasiment rien changer hein il faut changer moins de trucs qu'avec ta methode meme... vu qu'il suffit d'ul chaque batch des feuilles en vram, de virer les test de frustum culling des faces, et le reste ca reste pareil, juste qu'au lieu de passer le pointeur vers ses vertex/tc/normales/etc en sysram, il passe l'offset dans le VBO actuel, c'est tout... bcp moins complique que de culler les faces, recuperer les sous batches contigus, et faire les draw calls correspondants. la ca se limite a:

- creer un gros vbo (ou plein de petits vbo, mais ca obligera a faire des glVertexPointer et autres bcp plus frequemment
- balancer dedans tous les batches de chaque feuille du bsp

et pendant l'affichage:
- pour chaque feuille visible
- afficher tous ses batches

(sachant que pour avoir de meilleures perfs il faudra reconstruire les indices des faces, en les offsettant de la position du batch dans le gros vbo. (je sais pas si c'est clair comme explication , ptetre pas.. ))

sBibi :
(je sais pas si c'est clair comme explication , ptetre pas.. )

mais si

ok cool alors ^^

sBibi> ben ça change quand même pas mal de choses. Cela dit je suis d'accord que c'est plus propre hein
J'ai eu le même problème en portant un truc direct3d vers opengl. J'avais le droit de modifier qu'une partie du code, le reste étant figé et soi-disant indépendnat du moteur de rendu. Ben en fait du coup je suis obligé de renvoyer à chaque frame la majorité des objets (parce que je suis pas appelé aux moments qu'il faudrait et je peux pas stocker ce qu'il faut pour utiliser les vbo (ni même les listes d'ailleurs)).
Et après le gars qui m'a demandé de faire le portage dit que opengl rame par rapport à direct3d

pour nous ca nous donnait un fps plus constant et plus elevé. apres que notre methode soit crade je suis sur que oui, 3 semain pour faire ca avec d'autre projet en elect etc... + partiel c tout a fait normal Certainement qu'avec une bonne routine d'affichage c'est ridicule..

Et après le gars qui m'a demandé de faire le portage dit que opengl rame par rapport à direct3d

oue... alors que les draw calls de D3D bouffent enormement plus que ceux d'OGl (et qu'avec les recentes extensions des FBO D3D a plus aucun avantage vis a vis des ex-pbuffer de Gl ^^)
et puis si leur moteur est mal foutu ils peuvent s'en prendre qu'a eux hein z'avaient qu'a le faire en gl des le debut