Discussion :

[tickyletroll]

Bonsoir,

Je viens vers vous car j'ai besoin d'une aide pour optimiser un tracé d'algorithme en openGL de lignes.

Je travaille sur un logiciel d'astronomie en mode fisheye et je dois tracer les contours des constellations (ci dessous tout est en blanc)
Je suis passé du logiciel avec des primitives en opengl2 à des primitives en opengl4




Mon travail a pour but d'améliorer l'algorithme suivant:

algo 1 :
POUR chacune des 88 constellations:
- sélectionne le shader
- sélectionne/calcule les points --−> un vector de taille variable transmis avec un glbufferData
- sélectionne/calcule la couleur --> un simple vecteur de 3 floats transmis avec un uniform
- glDrawArray
- gluseProgram(0)
FIN_POUR

Je suis arrivé à ceci:

algo 2 :
sélectionne le shader
POUR chacune des 88 constellations:
- sélectionne/calcule les points --−> un vector de taille variable transmis avec un glbufferData
- sélectionne/calcule la couleur --> un simple vecteur de 3 floats transmis avec un uniform
- glDrawArray
FIN_POUR
- gluseProgram(0)

Ce changement d'algorithme m'a permis de diviser le temps d'exécution par 2

Mais je souhaiterai faire encore mieux en créant l'algorithme 3 :

algo 3 :
sélectionne le shader
POUR chacune des 88 constellations:
- sélectionne/calcule les points --−> un vector de taille variable transmis avec un glbufferData
- sélectionne/calcule la couleur --> un simple vecteur de 3 floats transmis avec un ???????? <--------------comment transmettre à la CG cette information ?
FIN_POUR
- glDrawArray( tout en un quoi !)
- gluseProgram(0)


sauf que pour l'algo 3, je ne sais pas comment passer ce vecteur de 3 floats qui reste constant pour chaque calcul de point.

Je veux dire que les données sont de cette forme:

Constellation1
- vector<24 floats> [12 points]
- couleur <3 floats> [1 couleur]

Constellation2
- vector<328 floats> [164 points]
- couleur <3 floats> [1 couleur]

Constellation3
- vector<100 floats> [50 points]
- couleur <3 floats> [1 couleur]

...

Constellation88
- vector<46 floats> [23 points]
- couleur <3 floats> [1 couleur]


Je suis bloqué sur mon travail car je ne sais pas comment dire au shader que la couleur est la même pour le paquet de données de taille variable.



Merci beaucoup de m'aider !

[LittleWhite]

Bonjour,

C'est très bien de diminuer le nombre de draw call. Pour passer des donner constantes (pour toute exécution d'un shader) il faut utiliser les variables uniformes.

[tickyletroll]

Sauf que je ne sais pas comment faire cela.

je prend un exemple avec des nombres au pif mais pour bien expliquer

J'ai ceci a envoyer à la carte graphique en une seule fois
pos: 5 4 6 8 2 9 4 8 2 6 (10 floats)
color : 0.1 0.2 0.1
pos: 10 5 2 7 2 6 (6 floats)
color : 0.1 0.3 0.5
pos: 8 7 5 6 9 4 2 8 5 7 9 5 3 5 2 1 0 8 (18 floats)
color : 0.4 0.2 0.7

le nombre de pos n'est pas constant, jamais le même.

Aussi comment puis je dire à la carte graphique, en un seul passage que :les 5 premiers points tu les mets en color : 0.1 0.2 0.1 , les 3 suivant en color : 0.1 0.3 0.5 et les 9 derniers en color : 0.4 0.2 0.7 ?

Sur l'exemple, ce que j'ai dans mon programme représente 3 appels à gldrawarray ou j'ai la couleur passée en variable uniform.
mais ce sont trois appels.

[dragonjoker59]

Mouais, je serais toi, je stockerais tous les points de toutes les constellations, avec les couleurs dans un seul VBO, et je dessinerais tout en un seul draw call.
En VRAM ça va prendre quoi, quelques Ko ? C'est ridicule comme poids, même sur mobile, donc je tenterais d'abord ça.

Je me pose par contre une question sans rapport avec le rendu : Où as-tu obtenu les coordonnées des limites des constellations ?

[tickyletroll]

Je travaille sur un dérivé de stellarium.

Les étoiles ont des coordonnées. Elles sont "fixes"dans le ciel. Aussi il suffit de dessiner autour des constellations les lignes que j'ai représenté. Pour cela, un codage a été fait (dans stellarium) pour les lignes représentés par des points désignant les frontières entre les étoiles.

En tout cas merci de ta réponse !

Pour info l'algorithme 3 implémenté va 6 fois plus vite que l'algorithme 2 qui lui même va 2x plus vite que le 1 issue de l'opengl2


12 x plus vite ....

Merci pour vos réponses !!!