Map openGl affichage différentes fréquences

Bonjour à tous,

je viens de terminer une partie d'un programme permettant de convertir une image bmp en une map openGL constituées de triangles via des VBO. Le seul problème est que, le fichier bmp ayant des dimensions de 256*256, le nombre de triangles avoisine les 300 000 (enfin plutot le nombre d' index) ce qui ralentit considérablement le programme à chaque "recoloriage" de la scène, update très fréquent (de l'ordre de 1 par 30ms).
Le problème est bien évidemment que le nombre de vertex à afficher est trop important pour pouvoir se permettre une update aussi fréquent (de toute façon ça le ralentit étant donné que le temps d'affichage est supérieur au temps entre chaque update).
Du coup, cela ralentit le programme et les évènements ne sont pris en compte qu'avec un délai important (normal).
Je voulais donc savoir si il existait un moyen simple (et efficace) d'afficher un VBO à intervalles très grands (pour la map, de l'ordre de 1 update par 5secondes) et de bouger la caméra, donc d'update la scène, beaucoup plus souvent, autrement dit est-il possible de dissocier un "plan" d'un autre car je me doute bien que si on efface la scene pour bouger la camera il faudra redessiner la map ce qui n'est pas avantageux.

N'hesitez pas a me poser des questions si vous n'avez pas compris mon problème, j'explique très mal ^^

Sinon pour votre aide précieuse ;)

Bonjour,

Sur quellle carte travaillez vous? Les performances devraient etre plus elevees a mon avis, pour la methode que vous decrivez, meme pour un update toutes les 30 ms.
Comment ecrivez vous dans le VBO? Comment l'avez vous construit?

Cdt,

Voici ma carte :
ATI Mobility Radeon HD 5850 c'est pas le dernier modèle mais elle est quand même bien puissante je pense puisque je fais tourner des jeux comme starcraftII en mode graphismes élevés donc je ne pense pas que le problème vienne de la.

En ce qui concerne mes vbos, j'ai regardé leur contenu avec GDebbuger et je n'ai observé aucune anomalie concernant les buffers, tous contiennent les bonnes valeurs. J'ai testé une carte de 64*64, cela marche sans aucun ralentissement. Je ne vois pas ou peut se situer le problème surtout que tout me semble correct.

Je peux vous fournir des morceaux de code si vous le désirez ;)

Cordialement

Edit : je viens de comparer les fps, effectivement j'obtiens un score pitoyable ^^ 3/4 FPS pour une map de 256*256, et seulement 10/15 pour une map de 64*64

Votre carte est largement suffisante pour effetuer cela.

Pouvez-vous poster la partie du code qui s'occupe de la mise a jour du VBO?

En fait je pense qu'il y a un problème lors de la création des vbos car le vbo index contient plus de 11500000 éléments ce qui je pense est la cause de ce ralentissement, je pense que je vais revoir mon algo de génération de terrain :mrgreen:

Edit : Je pense qu'il s'agit d'une erreur toute bête qui expliquerait la tendance exponentielle du rallongement de la liste d'index. En effet, lorsque j'ajoute des parties de vbo au vbo lui meme, je réalloue une zone de mémoire sans supprimer la précédente, ce que je pense occasionne de grandes pertes et non libération de mémoire, confirmées par gdebugger. Affaire a suivre donc :mouarf:

Que vous fassiez un seul VBO et IBO m'étonne beaucoup ... Une map ce conçois généralement en régions de même tailles, seul les VBOs diffèrent, pour un même IBO. Ainsi, vous pouvez déterminé par le CPU quels régions affiché a l'écran. Ils peuvent aussi être actualisé en priorité. Ainsi vos performance seront bien booster ...

et si vos modification sont localisé, pas besoin de rechargé tout les VBOs, seulement les VBOs des régions modifié.

Oui exactement c'est à cela que j'avais pensé mais je ne sais pas du tout comment le réaliser ! :aie:
Je n'ai pas en effet d'idée concernant la façon dont il est possible d'afficher prioritairement certaines régions de l'ecran au CPU. Pouvez-vous m'aiguiller ? :mrgreen:
Faut-il utiliser plusieurs thread auxquels on attache une priorité plus ou moins importante ? Où existe-t-il une autre manière de faire ? Une fonction spécifique à openGL ?

Merci par avance :ccool:

Citation:

---

Faut-il utiliser plusieurs thread auxquels on attache une priorité plus ou moins importante ?

---

Attention, un thread peut avoir qu'un seul contexte OpenGL a la foit et un contexte ne peut être qu'attaché qu'a un seul thread.
Il est possible d'avoir deux contextes qui contient les même éléments, on dit qu'il son partagé (ils partages leurs VBO, textures etc ...) mais il est déconseillez de faire le rendu sur deux thread. Cette configuration deux thread (ou plus, je monte jusqu'à 4 personnellement) OpenGL est utile pour les chargement "on the fly". Peut être que sa peut vous intéresser pour l'actualisation des VBOs sans interrompre le rendu. C'est performant car lors d'un rendu, la bande passante entre CPU-GPU est très peut utilisé, car il dessine avec les VBOs stocké sur la memoir GPU.

Code:

---

Une fonction spécifique à openGL ?

---

Attention, OpenGL reste spécialisé pour le rendu graphique, les opérations mathématiques de pré-rendu (calcul des matrices liées au objets, physique, collision etc...) sont conseilliez à être fait par CPU (ou OpenCL) ... Donc non, il n'existe pas de fonction OpenGL pour cette fonctionnalité. C'est le rôle du moteur graphique, en l'occurrence le votre qui doit s'en charger. ;)

Code:

---

Où existe-t-il une autre manière de faire ?

---

Donc oui ! :ccool:
Ba généralement, deux threads, l'un qui fait le rendu OpenGL d'une frame, pendant que l'autre calcul/prépare la fram suivante. Ainsi vous pouvez vous permettre de faire du "culling" qui consiste simplement à tester si chaque région est dans le cadre de l'écran. Si il ne l'est pas, alors on affiche pas. Ainsi ce second thread liste les régions a afficher, et ensuite, au changement de fram, le premier se contente de faire le rendu que des régions listé. Donc au moment de l'actualisation, vous pouvez accéder a cette liste, et ainsi actualisé ses éléments en priorité.

Globalement, il suffit de savoir si la sphère contenant l'ensemble de votre région est contenu dans le cône lié a la vue de votre camera. Avec la matrice de view-projection calculer pour les uniforms peut être ainsi utilisé.

Sinon d'un point de vbo, je me base sur un exemple. Nous souhaitons charger par exemple une carte de 512x512. Alors on va crée des régions de 16x16 faces, donc 17x17 vertex. Ce qui nous fait 32x32 régions au total.
Notez qu'il vous faudra alors 513x513 vertex ... Ce n'est pas grave, vous pouvez artificiellement prolongé votre terrain pour les 2 cotés ainsi rajoutés. ;)
Donc certain vertex peuvent appartenir à 2 régions si il sont sur un bord d'une région, voir même 4 régions si il sont sur les coins. Sinon il appartienne qu'à 1 régions.
Donc sa nous fait 32x32 VBOs a charger sur la mémoire GPU, mais un seul IBO (Index Buffet Object) non plus conçu pour un VBO de 256x256 vertex, mais bel et bien de 17x17 vertex ! :D C'est une assez grande optimisation mémoire, d'autemps plus que des unsigned short int suffisent au lieu d'unsigned int pour les indices car il y a moins de 65536 vertex par VBOs.

Pour le rendu, vous sélectionnez dans tout les cas votre IBO, puis vous rendez chacun des VBO associé aux régions listé par le thread de calcul, avec le même IBO.

Notez qu'il vous faudra un troisième thread si vous souhaitez avoir un chargement "on-the-fly" pour ne pas interrompre aussi le thread de calcul.

Merci beaucoup c'est exactement la réponse que j'attendais :ccool:
Reste plus qu'à s'y mettre maintenant ! ;)