VORTEX [OPENGL DEVCPP]
BeLZeL
Messages postés
110
Date d'inscription
mardi 10 octobre 2000
Statut
Membre
Dernière intervention
20 décembre 2005
-
2 oct. 2004 à 16:10
BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005 - 10 oct. 2004 à 17:09
BeLZeL Messages postés 110 Date d'inscription mardi 10 octobre 2000 Statut Membre Dernière intervention 20 décembre 2005 - 10 oct. 2004 à 17:09
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/26532-vortex-opengl-devcpp
https://codes-sources.commentcamarche.net/source/26532-vortex-opengl-devcpp
10 oct. 2004 à 17:09
J'ai mis la toute dernière version vendredi soir. Il y a même deux versions. Dites moi si ca semble ramer chez vous ou pas.
Et pour celles et ceux qui ont d'autres méthodes plus efficaces pour afficher un vortex, je suis preneur :)
9 oct. 2004 à 21:25
8 oct. 2004 à 22:37
Pour la nouvelle version (dispo très bientôt) :
J'ai utilisé glTexImage2D comme avant. J'ai juste retiré la fonction glGenTextures qui bouffe toute la mémoire. Là le prog doit prendre 10 Mo en mémoire.
Impossible de jouer sur les UV, car il y a des pb de raccords entre les textures. Je mettrais quand même les sources, et le "hack" que j'ai fait pour estomper le problème.
Sinon, j'utilise la matrice de la texture, mais on doit ensuite la remettre en mémoire avec glTexImage2D.
5 oct. 2004 à 19:22
mais certaine plus que dautre
comme glbindtexture(),glbegin(), glrotate(),...
fait un tour sur le site ti verra ya un forum avec bp de personne qui sont pret a taider!!!!
5 oct. 2004 à 17:25
5 oct. 2004 à 10:17
5 oct. 2004 à 10:14
mais je tiens a signaler une erreur de ma part ds le post precedent; glbindtexture() c lui qui permet de dire a opengl quel texture utiliser pour ce que l'on doit dessiner, evidement glbindtexture aussi bouffe du fps, et c'ets pour cette raison quil fo autant que possible trier les meshs par texture pour en faire le moins possible.
si on a qu'une seule texture il faut donc faire ca:
chargement de la texture(); //glTexImage2D() inclu
designeraopengllatextureaappliquer(); //glbindtexture();
boucle:
affiche mon ou mes mesh(); //qui utilise cette texture
fin boucle
on delete tout();
---------- si on a plusieurs textures le shema ideal (dans le cas ou on a une seule texture par type de mesh) -------
chargement des meshs(); //ca depend de vous ca!!!
chargement des textures(); //glTexImage2D() inclu
// jai detaillé la boucle sans optimisation structurelle
boucle:
designeraopengllatextureaappliquer(); //glbindtexture();
afficher les meshs qui ont cette texture();
designeraopengllatextureaappliquer(); //glbindtexture();
afficher les meshs qui ont cette texture();
...
fin boucle
on delete tout();
4 oct. 2004 à 21:59
tu l'affirmes. je suppose que c'est vrai. mais moi j'ai besoin d'être convaincu, il faut qu'on m'explique pourquoi c'est comme ça, ça me permet de bcp mieux retenir, et puis aussi d'extrapoler dans des situations apparentées.
si tu sais pq, je te demande juste de l'expliquer. merci ;)
4 oct. 2004 à 21:56
4 oct. 2004 à 17:34
4 oct. 2004 à 11:02
-il y a plusieurs textures à afficher, et dans ce cas il existe quelques methodes d'optimisation en triant par texture les meshs.
- si on fait une texture procedurale
voila je repond à la question de Kirua
et pour Belzel, pourquoi tu n'utilises pas la matrice de la texture à la place?
4 oct. 2004 à 11:02
-il y a plusieurs textures à afficher, et dans ce cas il existe quelques methodes d'optimisation en triant par texture les meshs.
- si on fait une texture procedurale
voila je repond à la question de Kirua
et pour Belzel, pourquoi tu n'utilises pas la matrice de la texture à la place?
3 oct. 2004 à 19:14
-> pour détruire une ou plusieurs textures... ;)
Sympa sinon ^^
3 oct. 2004 à 17:09
Kirua : effectivement, ca ne change rien, peut être même que c'est #define hypot(x,y) sqrt(x*x+y*y). Je plaisante :) Le pb de vitesse est dû uniquement aux 256*256 calculs à réaliser. Mais c'est bizarre que ca rame chez toi, je regarderais cette semaine sur mon PC de compet'.
Kleidp : Effectivement, il y a apparemment un gros pb de mémoire en recréant à chaque fois une nouvelle texture. C'était la première idée qui m'ait venu à l'esprit.
Je sais comment créer une texture (gluBuild... ou glTexImage...) mais pas moyen de supprimer cette texture de la mémoire (sauf en quittant le prog) ! J'ai rien trouvé dans la doc. Donc cette méthode est à proscrire.
Je vais modifier le programme en conséquence. Je vais jouer sur les UV (ce sont les coordonnées des textures, et non la texture elle-même, fonction glTexCoord2f), pour faire une sorte de morphing. Ca me permettra de ne pas faire 256*256 calculs, mais de le faire sur un quadrillage de l'ordre de 10*10 ou 100*100 (selon la qualité que l'on veut).
Pour le fading sur les côtés, je peux jouer sur la couleur des Vertex (fontion glColor3f).
Le seul soucis, c'est qu'il y aura plus de polygones à afficher (10*10 ou 100*100). J'ai essayé avec 256*256 points et ca marche. On ne pourra pas afficher la texture sur un SEUL polygone.
Si j'arrive à faire ce que je souhaite (ce qui n'est pas gagné), on peut multiplier les FPS par 5. Je ferais ca pendant la semaine, donc si ca vous intéresse, revenez samedi prochain ;)
3 oct. 2004 à 13:56
Par contre j'ai trouvé un bug qui fait ramer :
le programme augmente constament en mémoire, peut être parce que tu recréer une texture à chaque frame.
3 oct. 2004 à 12:12
il y a une fonction dans cmath qui fait ça: hypot(x, y);
http://www.sthoward.com/docs/libm_22.html
ça ne change ... rien? mais voili voilou ^^
3 oct. 2004 à 12:07
en fait, je me demande si c'est un bon choix que recréer une texture à chaque frame. est-ce que c'est pas possible de juste appliquer des déformations à la texture? j'en sais trop rien à vrai dire ^^
2 oct. 2004 à 23:12
Note pour moi-même :
J'ai recréé une texture pour chaque nouvel affichage.
-> Conserver la texture pour chq nouvel affichage mais jouer plutôt sur les UV.
2 oct. 2004 à 22:02
2 oct. 2004 à 16:10
gluBuild2DMipmaps ( GL_TEXTURE_2D, GL_RGB, 256, 256, GL_RGB, GL_UNSIGNED_BYTE, texture);
par
glTexImage2D ( GL_TEXTURE_2D, 0, GL_RGB, 256, 256, 0, GL_RGB, GL_UNSIGNED_BYTE, texture);
On peut également améliorer les perfs en diminuant le nombre de traitements. Ici, texture de 256*256, donc forcément ca prend du temps pour les calculs.