Discussion :

[bipcpp]

Bonjour,

Si on considère un PC "moyen" (pentium 4, carte graphique moyen de gamme), combien de GL_TRIANGLE peut-on raisonnablement afficher pour une animation de 10/15 images par secondes ?

Je cherche juste à avoir un ordre de grandeur : 50.000, 100.000, 1.000.000, plus ???

Merci.

[shenron666]

c'est très mais alors TRES dépendant de la carte graphique, de la fréquence du CPU et de la méthode utilisée

a titre d'exemple, un athlon 64 2GHz avec une geforce 6600GT 128Mo doit pouvoir afficher dans les 30 millions de polygones bruts non texturés en utilisant des VBO

je connaissait une appli bien lourde pour tester les vbo, si je la retrouve je transmet

[bipcpp]

Merci pour ta réponse shenron666.

Donc 100.000 ou 200.000 triangles ne lui font pas peur avec des glVertex3d.

[Kaktus]

glVertex3d.

Si justement !!

quand tu as beaucoup de vertices à afficher, glVertex3d est la méthode la plus lente !!
Essaies de voir avec des vbo, ça change la vie

[shenron666]

contrairement aux vbo, les glvertex sollicitent énormément le cpu et la bande passante vidéo

[bipcpp]

Merci pour vos réponses Kaktus et shenron666.

Je vais me pencher sur les VBO.
(c'est peut être pour cela que mon cpu est à 100% lorsque j'affiche un cube !)

[shenron666]

il peut aussi y avoir d'autres raisons telles que la non limitation du nombre d'images par secondes ou le fait que tu ne laisse pas la main à l'OS de temps à autre
même avec des glVertex

[bipcpp]

il peut aussi y avoir d'autres raisons telles que la non limitation du nombre d'images par secondes ou le fait que tu ne laisse pas la main à l'OS de temps à autre
même avec des glVertex

Comment fait-on pour limiter le nombre d'image par seconde ? (calcul manuel ou fonction OpenGL ???)

Pour laisser la main à l'OS, faut-il que j'insère quelques Sleep(1) dans mon code ??

Merci.

[shenron666]

pour limiter le nombre d'images par secondes, on mesure le temps pris par le rendu et on ne lance le rendu d'une nouvelle image que si on ne dépasse pas la limite fixée

un Sleep suffit déjà à passer de 100% à 0% sur un affichage de cube
par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
- calcul du rendu
- traitement des événements
- swap des buffers
- sleep(1)

un sleep d'une milliseconde est suffisant, en réalité ça demandera un sleep le plus court possible mais qui sera de plus d'une milliseconde

à tester en fonction de l'architecture de ton programme là où c'est le moins pénalisant
et en gardant en tête que les appels à opengl sont désynchronisés, par exemple si tu envoies de la géométrie au driver, pendant que le transfert se fera ton cpu sera disponible pour autre chose

[HanLee]

et en gardant en tête que les appels à opengl sont désynchronisés, par exemple si tu envoies de la géométrie au driver, pendant que le transfert se fera ton cpu sera disponible pour autre chose

Euh, ça dépend pas du fait que les commandes OpenGL soient bufferisées ou non ? (cf glFlush()).

[shenron666]

à ma connaissance, les commandes opengl sont bufferisées, elle ne peuvent pas ne pas l'être, ce n'est pas un choix possible

glFlush est autant que possible à éviter car c'est une fonction qui ne retourne que lorsque le buffer est vide, elle existe pour "forcer" les commandes opengl à être exécutées
en fait elle ne force rien, elle ne fait qu'attendre que le buffer soit vide

le problème dans ce cas, c'est que le cpu se tourne les pouces, on perd donc tout l'intérêt de la désynchronisation cpu / gpu