[OpenGL] Problème de rapidité

**mplant** · 04/01/2007, 11h20

Bonjour,

Je recherche des idées pour accèlerer l'affichage d'une scène en 2D.

Sur un exemple simple je n'arrive pas à afficher plus de 3000 textures avec un framerate décent (~ 10 fps sur un AMD 3500+ / Geforce 6100), ce qui me parait peu

Pour l'info c'est en java avec l'API JOGL.

J'ai déjà essayé quelques techniques (display list, etc) mais le framerate n'évolue pas d'un iota :o

Initialisation :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
gl.glOrtho(-width / 2, width / 2, -height / 2, height / 2, -1, 1);
 
gl.glBlendFunc( GL.GL_ONE, GL.GL_ONE_MINUS_SRC_ALPHA );
gl.glEnable( GL.GL_BLEND );
gl.glDisable( GL.GL_DEPTH_TEST );
gl.glDepthMask( false );
 
gl.glEnable (GL.GL_CULL_FACE  );
gl.glCullFace ( GL.GL_BACK );
 
gl.glEnableClientState( GL.GL_VERTEX_ARRAY );
gl.glEnableClientState( GL.GL_COLOR_ARRAY );
gl.glEnableClientState( GL.GL_TEXTURE_COORD_ARRAY );
 
m_textures = new Texture[TEXTURES_COUNT];
for (int i = 0; i < TEXTURES_COUNT; i++)
{
m_textures[i] = TextureIO.newTexture(TextureIO.newTextureData(new File(PATH + i +".png"), GL.GL_RGBA, GL.GL_RGBA, false, TextureIO.PNG));
m_textureWidth = 128;
m_textureHeight = 128;
}

Boucle d'affichage :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
gl.glClear(GL.GL_COLOR_BUFFER_BIT);
 
for(int i = 0; i < m_meshCount; ++i)
{
float x = random.nextFloat() * m_width - m_width * 0.5f;
float y = random.nextFloat() * m_height - m_height * 0.5f;
int textureId = random.nextInt(3);
 
m_textures[textureId].enable();
m_textures[textureId].bind();
 
gl.glBegin(GL.GL_TRIANGLE_STRIP);
 
gl.glTexCoord2f(0, 0);
gl.glVertex3f(x, y, 0.f);
 
gl.glTexCoord2f(1, 0);
gl.glVertex3f(x+ m_textureWidth, y, 0.0f);
 
gl.glTexCoord2f(0, 1);
gl.glVertex3f(x, y + m_textureHeight, 0.0f);
 
gl.glTexCoord2f(1, 1);
gl.glVertex3f(x + m_textureWidth, y + m_textureHeight, 0.0f);
 
gl.glEnd();
 
m_textures[textureId].disable();
}

Si vous avez des idées, je suis preneur.
Merci à tous

**Laurent Gomila** · 04/01/2007, 11h37

Faut aussi penser au framerate (taux d'affichage de pixels). Si tu affiches tes 3000 textures sur des carrés qui occupent beaucoup de pixels, 10 FPS peut être un bon score.

**mplant** · 04/01/2007, 14h03

(Tout d'abord merci d'avoir répondu si vite.)

En effet, les textures sont assez grosses et beaucoup de zone ont de l'alpha ou sont transparentes.

J'ai pensé faire un découpage plus précis en appliquant mes textures sur des polygones plus complexe que des carré afin d'éviter l'affichage des zones superflues, mais le gain ne semble pas énorme.

Il n'y a pas d'autres techniques pour éviter d'afficher les pixels transparents d'une image ?

**shenron666** · 04/01/2007, 14h05

tes drivers sont à jour ?
pas de problème de fluidité avec d'autres applis opengl ?

**Laurent Gomila** · 04/01/2007, 14h18

Il n'y a pas d'autres techniques pour éviter d'afficher les pixels transparents d'une image ?

Si tu utilisais l'alpha-blending alors tu peux utiliser l'alpha-test, ce sera un poil mieux.
A part ça il n'y a pas de miracle, ta carte graphique ne pourra jamais afficher plus de pixels à la seconde que ce qu'elle est capable de faire (quelques milliards de pixels par seconde pour les cartes actuelles).

Avec un fillrate théorique de 10 000 MPixels par secondes par exemple (GeForce 7800 GT), et 3000 quads texturés de 500x500, ça te ferait tourner dans les 13 images par seconde.

**mplant** · 04/01/2007, 15h08

Effectivement l'alpha test me fait gagner quelques fps.

Par contre, je pensais que l'on ne pouvait pas activer les deux en même temps (alpha-blending et alpha-test) mais ça à l'air de marcher ?!?.

Et je ne peux pas désactiver le blend car la plupart de mes textures ont des dégradé en alpha.

En tout cas merci pour les réponses

**Laurent Gomila** · 04/01/2007, 15h17

Par contre, je pensais que l'on ne pouvait pas activer les deux en même temps (alpha-blending et alpha-test) mais ça à l'air de marcher ?!?

Rien n'empêche de les utiliser en même temps, ils ont des rôles bien distincts.

**superC** · 04/01/2007, 20h35

vous pensez quoi de la compression de textures dans ce cas précis ?

**shenron666** · 05/01/2007, 10h51

que je soit sûr, on ne parle pas d'un png que tu décompresses, on parle bien d'une texture compressée qui reste compressée en mémoire vidéo (format dds, le S3TC / DXTC)

auquel cas, utiliser des textures compressées pourrait te faire gagner du frame rate si tu es limite en bande passante

par contre, si ta carte sature au niveau fill rate (vitesse de remplissage à l'écran en gros) tu ne gagneras rien

il faut tester pour voir le résultat

**superC** · 05/01/2007, 11h31

oké j'avais pas pensé au fill rate :-/

**mplant** · 05/01/2007, 14h17

Dans ce cas précis, le gain en DXTC est minime comparé à la perte de qualité que cela engendre, c'est bien le Fillrate qui est limitant

**bafman** · 05/01/2007, 14h25

Envoyé par mplant

Dans ce cas précis, le gain en DXTC est minime comparé à la perte de qualité que cela engendre, c'est bien le Fillrate qui est limitant

pas forcement. N'oublions pas qu'il travail sur une GF6100, donc probablement avec turbo cache qui partage la memoire central avec la carte graphique, donc il risque d'avoir des gros transferts de memoire sur le port PCIe qui peuvent être la cause de sa "lenteur" et donc la compression peut être benefique dans son cas... mais la, il faut vraiment faire des tests pointu pour en être sûre et on risque de tomber sur des "optimisations" de moteur propres à une carte graphique bas de gamme qui risquent de ralentir les carte plus haut de gamme

**Octopod** · 06/01/2007, 00h01

Pas étonnant que ça ramouille

... le changement de texture est l'un des changements d'état les plus couteux pour le GPU.

De plus, si le total de mémoire qu'occupe toutes tes textures ne tient pas dans la mémoire vidéo, le driver va forcement en laisser une partie dans la mémoire AGP (moins rapide que la RAM video). Tu serais sans doute mieux à utiliser du DXTC pour loger le plus possible de textures dans la RAM vidéo. Peux-tu controller l'emplacement ( AGP ou RAM video ) des textures que tu charges avec OpenGL ? Je ne suis pas sur...

Si ton affichage consiste à afficher des sprites, désactive le Z buffer ( write et test ) et tris toi même tes quads pour les afficher du plus lointain au plus proche. Tu va beaucoup gagner avec ça.

Enfin, je dirais que à moins que les surfaces de tes quads ne se recouvrent jamais, tu peux optimiser le fillrate en n'affichant pas les quads cachés derrières d'autres ou en affichant uniquement les portions visibles. Si tes textures ont de l'alpha, il faut déterminer pour chaque la surface minimale totalement opaque. C'est un peu hardcore d'en arriver la

...

Au fait, à quoi te sert d'afficher 3000 textures ?

Alexis.

**bafman** · 06/01/2007, 11h26

Envoyé par Octopod

Peux-tu controller l'emplacement ( AGP ou RAM video ) des textures que tu charges avec OpenGL ? Je ne suis pas sur...

on peut en partie avec glPrioritizeTexture qui permet de donner une priorité au texture pour être placée en memoire video... après le problème c'est de savoir comment les drivers le gerent effectivement etant donné que ce n'est quasiment jamais utilisé, il y a peut de chances que ca ai un effet transcendant

Envoyé par Octopod

Si ton affichage consiste à afficher des sprites, désactive le Z buffer ( write et test ) et tris toi même tes quads pour les afficher du plus lointain au plus proche. Tu va beaucoup gagner avec ça.

la ca depend complètement de la carte graphique... si elle est plus rapide à lire dans le depth buffer et à faire une comparaison de profondeur qu'a ecrire dans ce même buffer, il faut mieux activer le depth test et les afficher du plus proche au plus lointain... mais encore une fois, c'est le genre d'otimisation propres à une carte donnée qui risque de ralentire les autres cartes...

**mplant** · 09/01/2007, 09h12

Si ton affichage consiste à afficher des sprites, désactive le Z buffer ( write et test ) et tris toi même tes quads pour les afficher du plus lointain au plus proche. Tu va beaucoup gagner avec ça.

Les sprites sont triés par ordre d'affichage sans le Z-Buffer, mais ça n'évite pas les superpositions inutile pour autant.

Enfin, je dirais que à moins que les surfaces de tes quads ne se recouvrent jamais, tu peux optimiser le fillrate en n'affichant pas les quads cachés derrières d'autres ou en affichant uniquement les portions visibles. Si tes textures ont de l'alpha, il faut déterminer pour chaque la surface minimale totalement opaque. C'est un peu hardcore d'en arriver la

...

Malheureusement aucun des sprites n'est jamais complétement caché

Au fait, à quoi te sert d'afficher 3000 textures ?

Chaque personnage du jeu (qui est en 2D) est composé de centaine de texture, (pour les yeux, les bras, les mains etc).
Donc on arrive vite à 3000 en rajoutant le décors etc...

**Laurent Gomila** · 09/01/2007, 09h17

Chaque personnage du jeu (qui est en 2D) est composé de centaine de texture, (pour les yeux, les bras, les mains etc)

Curieux. Qu'est-ce qui nécessite une telle séparation ? Tu animes chaque partie indépendamment ? Autre chose qui ne peut pas être fait à l'initialisation ?

**mplant** · 09/01/2007, 09h27

Envoyé par Laurent Gomila

Curieux. Qu'est-ce qui nécessite une telle séparation ? Tu animes chaque partie indépendamment ? Autre chose qui ne peut pas être fait à l'initialisation ?

Cela permet à la fois la customisation complète des personnages, et la possibilité d'avoir des centaines d'animations sans rajouter de poids.
Les animations sont juste une suite de transformations sur chaque élement (mains, jambes etc).

**Laurent Gomila** · 09/01/2007, 09h54

Ok. Ca doit être chouette à voir

**Sivrît** · 09/01/2007, 11h27

Faudrait tester pour voir si c'est le nombre changements de textures qui limite et à quel point, par ex en affichant plusieurs fois les mêmes et en en sautant d'autres (ou en en faisant moins mais plus grosses).

Ca pourrait amener à afficher par texture plutôt que par personnage et autres jongleries du genre.