Emuler des lignes

Version imprimable

16/03/2009, 22h40
zeyous

Emuler des lignes

Salut à tous

j'ai besoin de tracer un nombre conséquent de lignes de différentes épaisseur. Jusqu'ici j'utilisais GL_LINES mais c'est lent et je ne peux justement pas faire varier l'épaisseur rapidement.

Je pensais profiter des display list et du calcul de matrices pour transformer un simple carré en une ligne. Avec translate, rotate et scale on doit pouvoir allonger et positionner la ligne correctement. En mettant le petit carré dans une display list (ou pas) je pense que les performances seront meilleures qu'avec GL_LINES.

Ayant encore peu d'expérience dans le calcul de matrices j'ai du mal à voir les transformations que je dois effectuer sur mon carré pour translate, rotate et scale en 3D.

Le problème est simple, j'ai deux points p1(x1,y1,z1) et p2(x2,y2,z2) et un carré centré sur zero (-1,-1), (1,-1), (1,1), (-1,1). Quels transformations je dois effectuer ? Est-il possible de tout faire en une matrice ?

Merci
17/03/2009, 00h50
LittleWhite

Bonjour,

Je ne pense pas que ta methodes de transformation , pour l'affichage des lignes soit plus rapides ...
Quoiqu'il en soit, pour affichier une ligne , il faut faire une interpolation.

Par example:
( En prenant P1 = (x1, y1, z1 ) et P1 = (x2, y2 ,z2 )
Au tout debut ( t = 0 ) , ton point est dessiné à P1
À la fin ( t = 1 ) , ton point est dessiné à P2.
Pour dessiner tout les point intermédiaires c'est juste une interpolation linéaire.
P(t) = P1 * ( 1 - t ) + P2 * t

Qui permettra de faire donc, l'interpolation pour t >= 0 et t <= 1
Tu as juste à dessiner après, les P(t) en faisant par exemple une boucle for modifant t.

Si tu n'as pas compris, je peux réexpliquer ( mieux )

Par contre, je ne pense pas que se soit la solution pour accélérer ton programme.

Est ce que tes lignes changent à chaque images ?

Essaie avec des vertex buffer objects ... peut être
17/03/2009, 10h48
plegat

Citation:

Envoyé par LittleWhite

Quoiqu'il en soit, pour affichier une ligne , il faut faire une interpolation.

C'est une blague? Sous OpenGL? ;)

Citation:

Envoyé par LittleWhite

Essaie avec des vertex buffer objects ... peut être

+1
Mais essaie les display list auparavant.
Si tes épaisseurs de ligne sont assez importantes, tu peux aussi tracer des quads directement plutôt que de passer par des translation/rotation/echelle.

Sinon, montre-nous ton code pour le tracé, tu as peut-être utilisé des constructions qui peuvent être optimisées niveau code.
17/03/2009, 16h36
KorWipe

Il faut faire attention avec les primitives GL_LINES, certaines cartes ont des drivers qui n'implémentent pas ces primitives en hard, d'ou la chute de fps. Heureusement, toutes n'ont pas ce problème mais cela existe !!

Comme cité plus haut, dessine plutôt des quads/triangles strips.

Alors, j'ai essayé plusieurs solutions et j'ai quand même résolu mon problème, même si on peut surement faire mieux, notamment avec les VBO je pense.

Donc finalement j'ai bien réussi à faire mes matrices de transformation, en 2D seulement pour transformer mon simple carré en ligne, bonne longueur et bonne épaisseur.

Voilà ce que ça donne, JOGL:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 float t=1f; //Epaisseur float distance = (float)Math.sqrt(Math.pow((double)x1 - x2,2d) + Math.pow((double)y1 - y2,2d) + Math.pow((double)z1 - z2,2d)); double anglez = Math.atan2(y2 - y1, x2 - x1); gl.glPushMatrix(); gl.glTranslatef(x1+(float)Math.cos(anglez)*distance/2f, y1+(float)Math.sin(anglez)*distance/2f, 1); gl.glRotatef((float)Math.toDegrees(anglez), 0, 0, 1); gl.glScalef(distance/2f, t, 0f); gl.glBegin(GL.GL_TRIANGLE_STRIP); gl.glVertex3f(1, 1, 0); gl.glVertex3f(-1, 1,0); gl.glVertex3f(1, -1, 0); gl.glVertex3f(-1,-1, 0); gl.glEnd(); gl.glPopMatrix();
Cela fonctionne, à des perfs a peu près simillaires que GL_LINES. En revanche si je met le carré dans une display list mes perfs sont divisés de 40% environ. Les display list c'est pour des objets plus complexes je pense, genre une sphere.

Ensuite, une autre approche dessine sans utiliser la transformation de matrices, les perfs sont un peu meilleures, et c'est en 3d (enfin presque). Ce sont en fait deux triangles qui forment un rectangle.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 float t1=0.5f; //Epaisseur point1 float t2=0.5f; //Epaisseur point2 double angle = Math.atan2(y2 - y1, x2 - x1); float t2sina1 =(float)( t1 / 2 * Math.sin(angle)); float t2cosa1 = (float)( t1 / 2 * Math.cos(angle)); float t2sina2 = (float)( t2 / 2 * Math.sin(angle)); float t2cosa2 = (float)( t2 / 2 * Math.cos(angle)); gl.glBegin(GL.GL_TRIANGLES); gl.glVertex3f(x1 + t2sina1, y1 - t2cosa1,z1); gl.glVertex3f(x2 + t2sina2, y2 - t2cosa2,z2); gl.glVertex3f(x2 - t2sina2, y2 + t2cosa2,z2); gl.glVertex3f(x2 - t2sina2, y2 + t2cosa2,z2); gl.glVertex3f(x1 - t2sina1, y1 + t2cosa1,z1); gl.glVertex3f(x1 + t2sina1, y1 - t2cosa1,z1); gl.glEnd();
Des idées pour ameliorer encore cela ?

17/03/2009, 19h02
plegat

Citation:

Envoyé par zeyous

Cela fonctionne, à des perfs a peu près simillaires que GL_LINES. En revanche si je met le carré dans une display list mes perfs sont divisés de 40% environ. Les display list c'est pour des objets plus complexes je pense, genre une sphere.

Ca, ce n'est pas trop normal... quand tu dis "le carré", ça veut dire que tu fais une display list par ligne que tu veux tracer? Si oui, ce n'est pas la bonne méthode. Il faut mettre toutes tes lignes dans la display list. Sur un seul carré, c'est sûr que ce n'est pas rentable...

Citation:

Envoyé par zeyous

Ensuite, une autre approche dessine sans utiliser la transformation de matrices, les perfs sont un peu meilleures, et c'est en 3d (enfin presque). Ce sont en fait deux triangles qui forment un rectangle.

Ce qui revient au même que faire le triangle_strip... pourquoi ne pas directement dessiner un quad?

Citation:

Envoyé par zeyous

Des idées pour ameliorer encore cela ?

Disons que là on ne voit que la procédure de dessin pour une ligne. Ca veut dire que tu as une grosse boucle derrière qui appelle cette procédure pour chaque ligne?
Ce qui me gêne, c'est le nombre impressionnant de calculs que ça engendre. A chaque ligne, tu as un atn, deux sin et cos, des +,-,*,/... ça allourdit et ralentit...
Vu que tu dois avoir un tableau quelque part pour stocker les coordonnées des lignes, rajoute des colonnes pour y stocker toutes les autres informations nécessaires au tracé.
De plus, essaye en utilisant qu'une seule paire d'instructions glBegin/glEnd (là, tu en as une paire pour chaque ligne).
18/03/2009, 14h34
zeyous

Citation:

Envoyé par plegat

Ca, ce n'est pas trop normal... quand tu dis "le carré", ça veut dire que tu fais une display list par ligne que tu veux tracer?

Non, une seule display list, contenant le carré centré sur 0. A chaque tracé de ligne, j'appelle la display list lorsque les matrices de transformation sont définies. Etant donné que mes lignes ne sont pas statiques et qu'elles bougent dans le temps je ne peux pas toutes les mettre dans une display list.

Citation:

Envoyé par plegat

Ce qui revient au même que faire le triangle_strip... pourquoi ne pas directement dessiner un quad?

Les perfs sont les mêmes non ?

Citation:

Envoyé par plegat

Disons que là on ne voit que la procédure de dessin pour une ligne. Ca veut dire que tu as une grosse boucle derrière qui appelle cette procédure pour chaque ligne?
Ce qui me gêne, c'est le nombre impressionnant de calculs que ça engendre. A chaque ligne, tu as un atn, deux sin et cos, des +,-,*,/... ça allourdit et ralentit...
Vu que tu dois avoir un tableau quelque part pour stocker les coordonnées des lignes, rajoute des colonnes pour y stocker toutes les autres informations nécessaires au tracé.

Oui il y a la boucle que tu décrit, il y a effectivement quelques calculs que je pourrais éviter. Je vais voir si stocker ces valeurs est pertinent mais étant donné que la position des lignes change souvent je ne suis pas sûr.

Citation:

Envoyé par plegat

De plus, essaye en utilisant qu'une seule paire d'instructions glBegin/glEnd (là, tu en as une paire pour chaque ligne).

Oui ça c'est fait, c'etait juste pour l'exemple.
18/03/2009, 16h19
plegat

Citation:

Envoyé par zeyous

Etant donné que mes lignes ne sont pas statiques et qu'elles bougent dans le temps je ne peux pas toutes les mettre dans une display list.

Effectivement... à moins de redéfinir la display list à chaque itération, mais je ne suis pas sûr que ça fasse gagner du temps au final.

Citation:

Envoyé par zeyous

Les perfs sont les mêmes non ?

A vrai dire, je ne sais pas. C'était pour voir si il y avait une raison particulière...

Citation:

Envoyé par zeyous

Je vais voir si stocker ces valeurs est pertinent mais étant donné que la position des lignes change souvent je ne suis pas sûr.

Avec Jogl, on ne sait jamais. Essaye d'éviter les calculs dans les lignes d'instructions openGL (même si j'ose espérer que le compilateur fait les optimisations en cours de route).
Teste avec les VBO... même si tu dois redéfinir toutes les coordonnées à chaque tour, ça devrait aller plus vite au final.
18/03/2009, 16h45
Frifron

Salut,

dans le code que tu montres tu n'orientes pas ton quad par rapport a la camera. L orientation de tes lignes est donc dans le monde et ca doit induire un rendu incorrect si tu change l orientation de ta camera dans le monde 3D. Quand je parle de rendu incorrect je veux dire different de celui de GL_LINES car c est ce que tu veux faire sans les contraintes (epaisseurs de ligne identique par batch, epaisseur limitée...).

Donc en gros il faut calculer un vecteur side pour chaque ligne de sorte qu il soit perpendiculaire au vecteur look de ta camera et au vecteur formé par les 2 extremite de la ligne. Tu as ca avec un produit vectoriel. Tu normalises ce vecteur et ajoute la moitié de sa valeur multipliée par l epaisseur de la ligne de chaque coté des 2 points initiaux de la ligne. Ce qui te donne ta ligne avec epaisseur. Utiliser les angles pour faire de la géométrie vectorielle n est pas necessaire dans ton cas et implique du calcul couteux en trop.

Apres pour effectuer ces calculs tu as 3 choix :
_ soit tu fais tout coté CPU et balance les données calculées au GPU
_ soit tu balances des quads et tu fais les calculs coté GPU sur un vertex shader en passant l epaisseur quelque part.
_ soit tu balances des GL_LINES donc juste les 2 points avec une donnée perso correspondant a l epaisseur, tu utilises un geometry shader pour construire un quad puis un vertex shader pour le calcul de l orientation et de l epaisseur. Cela a l avantage de reduire la quantite de donnée a transférer.

Tu dis que tu as des meilleurs perfs avec ta methode qu avec les GL_LINES ? Ca me parait étrange tout de même. Quel a été ta méthode pour affirmer cela ?
19/03/2009, 11h28
zeyous

Citation:

Envoyé par Frifron

Salut,

dans le code que tu montres tu n'orientes pas ton quad par rapport a la camera. L orientation de tes lignes est donc dans le monde et ca doit induire un rendu incorrect si tu change l orientation de ta camera dans le monde 3D. Quand je parle de rendu incorrect je veux dire different de celui de GL_LINES car c est ce que tu veux faire sans les contraintes (epaisseurs de ligne identique par batch, epaisseur limitée...).

Oui c'est très juste, il faudrait orienter les lignes face à la camera, comme un billboard.

Citation:

Envoyé par Frifron

Donc en gros il faut calculer un vecteur side pour chaque ligne de sorte qu il soit perpendiculaire au vecteur look de ta camera et au vecteur formé par les 2 extremite de la ligne. Tu as ca avec un produit vectoriel. Tu normalises ce vecteur et ajoute la moitié de sa valeur multipliée par l epaisseur de la ligne de chaque coté des 2 points initiaux de la ligne. Ce qui te donne ta ligne avec epaisseur. Utiliser les angles pour faire de la géométrie vectorielle n est pas necessaire dans ton cas et implique du calcul couteux en trop.

Çà me parait juste, je vais essayer de faire cela

Citation:

Envoyé par Frifron

Apres pour effectuer ces calculs tu as 3 choix :
_ soit tu fais tout coté CPU et balance les données calculées au GPU
_ soit tu balances des quads et tu fais les calculs coté GPU sur un vertex shader en passant l epaisseur quelque part.
_ soit tu balances des GL_LINES donc juste les 2 points avec une donnée perso correspondant a l epaisseur, tu utilises un geometry shader pour construire un quad puis un vertex shader pour le calcul de l orientation et de l epaisseur. Cela a l avantage de reduire la quantite de donnée a transférer.

Pour le moment je code un moteur 'Compatibility' pour tourner sur le maximum de hardware mais merci pour ces infos, ça me sera utile lorsque je ferais un moteur avec shader :-) Si je peux optimiser mes lignes avec un vertex shader c'est parfait...

Citation:

Envoyé par Frifron

Tu dis que tu as des meilleurs perfs avec ta methode qu avec les GL_LINES ? Ca me parait étrange tout de même. Quel a été ta méthode pour affirmer cela ?

Très bien vu, j'avais bien mal mesuré et les performances sont supérieure d'environ 30% avec GL_LINES. Mais si on appelle glLineWidth() pour chaque ligne, étant obligé de mettre glBegin() et glEnd() dans la boucle, les perfs sont comparables, avec toujours 10% pour GL_LINES.

J'oriente désormais mes quads de lignes en direction de la camera. Ça a l'air de marcher, et c'est ce que je recherchait. Le vecteur camera est un vecteur calculé a partir de la position et de la cible de la camera. Il est donc constant, pour une position de la camera.

Voilà ce que ça donne:

Le tout dans un GL_TRIANGLES
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Vec3f edgeVector = new Vec3f(x2 - x1,y2 - y1,z2 - z1); Vec3f sideVector = edgeVector.cross(cameraVector); sideVector.normalize(); float x1Thick=sideVectorX/2f*t1; float x2Thick=sideVectorX/2f*t2; float y1Thick=sideVectorY/2f*t1; float y2Thick=sideVectorY/2f*t2; float z1Thick=sideVectorZ/2f*t1; float z2Thick=sideVectorZ/2f*t2; gl.glVertex3f(x1+x1Thick, y1+y1Thick, z1+z1Thick); gl.glVertex3f(x1-x1Thick, y1-y1Thick, z1-z1Thick); gl.glVertex3f(x2-x2Thick, y2-y2Thick, z2-z2Thick); gl.glVertex3f(x2-x2Thick, y2-y2Thick, z2-z2Thick); gl.glVertex3f(x2+x2Thick, y2+y2Thick, z2+z2Thick); gl.glVertex3f(x1+x1Thick, y1+y1Thick, z1+z1Thick);
Comme tu l'avais prévu les perfs sont bien meilleures en utilisant les vecteurs plutôt que les angles. En fait elles sont similaires à l'utilisation de GL_LINES, ce qui me ravi :yaisse2:

20/03/2009, 14h52
Frifron
parfait :)

Juste un petit truc,

ton sideVector peut en théorie être nul, si le vecteur look de la camera et le vecteur suivant ta ligne sont colinéaires. Dans ce cas tu te retrouves avec une division par zero lors de la normalisation du vecteur.

A moins que ta fonction normalize() gere deja le cas, il faut gerer ca en amont pour bien faire :
Code:

1 2 3 4 5 6 float norm = sideVector.norm(); if (norm > EPSILON) // EPSILON TRES PETIT sideVector /= norm; else sideVector.set(0.0f,0.0f,0.0f);
Si le normalize gere deja ca, ne tiens pas compte de ma remarque.

Bonne continuation

[EDIT] (g reedité mon edit)
Aussi, pour avoir un comportement vraiment juste, il faut que tu recalcule le vecteur look pour chaque ligne de la camera :
Code:

1 2 look = pointDelaLigne - cameraPos;
N importe quel point de la ligne fera l affaire car quelque soit le point de la ligne utilisé pour calculer le vecteur look, celui ci sera la normale au plan formé par les 3 points : position de la camera et les 2 points de la ligne.

Ca n alourdit que tres peu les calculs (une soustraction de vecteur en plus par ligne, negligeable par rapport au produit vectoriel et surtout a la normalisation) et tu auras un rendu bien meilleur (notamment lorsque le vecteur de la ligne se rapproche du vecteur direction de la camera)

teste les 2 methodes et compare les differences en terme de rendu et de performances...
24/03/2009, 23h58
zeyous

Citation:

Envoyé par Frifron

parfait :)
Aussi, pour avoir un comportement vraiment juste, il faut que tu recalcule le vecteur look pour chaque ligne de la camera :

Oui le cameraVector étant calculé à partir de la position et de la target l'orientation des objets n'est effectivement pas complètement correcte.

Comme tu le propose, recalculer le cameraVector avec un point de la ligne permet d'avoir un rendu nickel. Je ne vois pas vraiment de différence de perfs avec la version précédente.

merci pour votre aide :king:
Je me suis notamment rendu compte qu'utiliser la trigo est bien plus lent que les vecteurs ;)