Bonjour,
 
J'ai un petit probleme en OpenGL (enfin plus exactement en OpenSG mais mon probleme viens de l'openGL...)
Dans mon prog, je modifie le Display Buffer (GL_RGB).. Le probleme c'est que lors des déplacements, on voit l'image normale puis l'image modifiée... ce qui fait un scintillement tres désagreéable
 
Le code:

 
L'idéal serait de rendre le displayBuffer mais sans l'afficher .. mais je ne vois pas du tout comment faire ...
 
Une idée ?
 
Meric d'avance !

y'aurait pas double emploi entre mgr->redraw et glutSwapBuffers ?

Non non, puisque le mgr->redraw sert à afficher la scene, puis je récupère le displayBuffer (le GL_RGB), je le modifie (glDrawPixels) et le glutSwapBuffers sert à réafficher le displaybuffer...
 
sans le premier, mon displayBuffer est vide, sans le deuxieme, les modifications apportées ne sont pas prises en compte...

déjà à la base c'est le mal ce que tu essaies de faire, mais bon passons, ensuite tu récupère tes composantes sous forme de flottants... c'est voulu ?

par contre si tu vois l'image rendu puis l'image modifiée, c'est probablement que gr->redraw(); fait un glutSwapBuffers()...

 
En fait je veux colorer certains pixels.. Je ne vois pas d'autres méthodes directes...
Ca va pas les GL_FLOAT ? il faut quoi ?

bin disons que c'est méga lent !!!
 
à la base Read/Draw c'est pas top (download/upload sur l'AGP, enfin si c'est pour faire un bench pour montrer la supériorité du PCI Express sur l'AGP)
 
le framebuffer a ses composantes en entiers 8bits si tu est en 32bpp, passer par des flottants fait que glRead/DrawPixels doivent faire des conversions entier->flottant, flottant->entier....
 
après ça dépends de ce que tu veux faire (specs minimales de la carte 3D & perfs), mais si ton traitement n'est pas compliqué, une implémentation moderne serait plustôt de faire un rendu en texture et d'utiliser un fragment shader......
(ou de verrouiller le framebuffer et de passer un shader par dessus)
 
après ça dépends si t'as une carte qui peut supporter de l'OpenGl >= 1.4 ~1.5 (voir 2.0 ché pas j'y connais rien en OpenGl)

 
 
Oui c'est vrai que c'est lent !
Et comme je travaille sur le DepthBuffer aussi, je fasi un autre glReadPixels ! Donc je te raconte pas les perfs !
Mais je ne vois pas du tout d'autres solutions...
Le probleme c'est que mon appli doit tourner apres sur opengl ES (version pda de openGL), et je ne pense pas que les fragmentBuffer existe...

Si tu n'as pas de RTT (render-to-texture), passe au moins par l'API texture (CopyTexSubImage).  
ReadPixels/DrawPixels c'est à peu pres ce qui se fait de plus lent en OpenGL.

Ok merci beaucoup ! je vais chercher vers la...

Bon pour le GL_FLOAT, je dois rester avec ca, il me faut des valeurs entre 0 et 1...

c'est quoi l'idée de ton traitement ?
ça implique plusieurs pixels ? (matrice de filtre...)
ça peut s'émuler par un lookup dans une texture ?

En fait, je dois colorer les pixels qui sont à une certaine profondeur (qui est lue dans le depth buffer)...
Donc effectivement ca impliqie plusieurs pixels
 
C'est quoi le "look up" ?

non c'est pas ça que je veux dire... je voulais savoir si pour modifier un pixel(x,y), il te fallait les pixels(x-1,y), (x+1,y), etc.... pour procéder à un filtrage maison.
 
si ta relation de modification est uniquement liée à la profondeur du pixel désiré, alors normalement tu peux faire directement dans le pixel ou le vertex shader (suivant le dégré de précision désiré).
 
car ta relation altération couleur par rapport à sa distance, c'est ce qui est plus ou moins fait pour le brouillard....
 
un texture de lookup, c'est une texture 1D/2D ou+ qui permet d'émuler une fonction mathématique complexe:
 
par exemple pour une exponentiation: nouvelle_valeur=pow(valeur,exposant), tu peux utiliser une texture 2D avec la valeur en X, et l'exposant en Y.... (au lieu de calculer tu vas lire une texture => table de précalcul)
 

je ne pense pas pouvoir utiliser le pixel ou vertex shader..
déja, comme je l'ai dit plus haut, je dois faire tourner ca sur openGL ES, et je ne pense pas que les chipsets embarqués integrent des pixels ou vertex shaders.. (a verifier tout de meme..)
De plus (je me trompe peut etre, je connais tres mal les shaders), dans ce que je dois faire, on sélectionne des zones au clavier (les profondeurs..), et je ne pense pas pouvoir faire ca avec des shaders..
 
Ca m'arrangerait vraiment de pouvoir faire ca qu'avec openGL...
j'ai pensé a une technique...
 
* récupérer le depth buffer par la meme méthode (parce quej'en vois pas d'autre...)  
* créer un buffer ou les pixels à colorer sont en rouge, et afficher ce buffer par dessus l'image...  
Mais je ne vois pas comment faire cette derniere opération...  
je pensais à un plan qui serait affiché devant la camera, avec de la transparence, mais j'ai peur niveau perfs... (quoi que ca ne peut pas etre pire )
 

Je viens de voir que OpenGl ES possédait son langage de shaders...
http://www.khronos.org/cgi-bin/fet [...] g_language
 
je vais voir un peu si je peux résoudre mes problemes vaec des shaders (notemment l'interaction.. c'est ca qui me fait peur..)

Je pense que je vais partir vers les shaders.; mais je n'y connais rien du tout !
Déja, est ce qu'il est possible d'utiliser des pixel Shaders avec OpenGL 1.5 ?  
Si oui, avec quel langage (GLSL, Cg, autre..) ?  
 
merci d'avance !

alors avant de t'orienter définitivement vers les shaders, il y a encore des choses a évaluer....
 
tu dis que tu renseigne la zone de profondeur au clavier...
 
en gros c'est quoi, tu as deux profondeurs pour définir ta zone d'interêt ?
ensuite tu altères les pixels dans cette zone ?
 
parceque si c'est ça c'est plus simple, tu utilises le stencil plus ou moins à la doom3 (enfin de loin hein ):
 
1) clear stencil+Zbuffer
2) test < et update Z activés  
3) traçage scène
 
4) désactivation update Z (le test reste)
 
5) stencil en mode incrémentation
 
6) traçage d'un quad face à la caméra à Z=fin de zone
 
7) traçage d'un quad face à la caméra à Z=début de zone
 
(ou inversement)
 
=> les pixel dans la zone d'intêret ont le stencil à 1.
 
porqué ? comme le quad n'incrémentera le stencil que si le pixel est plus proche que dans le Z-buffer, et que le stencil est à 0:
 
après 6)
- la partie après la fin de zone (zone Z max) restera à 0
- la partie avant la fin de zone sera à 1
 
après 7)  
- la partie après le début de zone (zone Z min) restera à 1
- la partie avant le début de zone sera à 2
 
ce qui fait que tout ce qui est avant le début de zone est à 2, après la fin de zone à 0, et dans la zone à 1.
 
dans la technique je cherche à conserver le même critère de test Z (pixel traité si inférieur au Zbuffer), pour faire ami-ami avec les techniques de Z-Buffer hiéarchique des cartes 3D modernes que l'on a sur PC.
 
enfin si je dis pas de conneries.
 
maintenant si ce que tu veux faire c'est autre chose qu'altérer des pixels dans une zone Z...
 
la blague étant que là ça marche pour une zone, si tu veux plusieures zones, il faut reboucler sans retraçer la scène en cleanant le stencil (mais il faut altérer des pixels dans la boucle)

ben ce que je veux faire c'est bien ca ! exactement ca meme !!
je te remercie !!
D'autant plus que depuis j'ai eu des nouvelles contraintes, je ne peux pas utiliser les shaders, ni les glReadPixels et glDrawPixels...
Merci mille fois pour cette technique ! Je ne connaissais pas....

à terminer avec un:
 
8) test Z désactivés, test stencil = 1
 
9) traçer un quad avec une couleur unie et un blending à 50/50 pour altérer les pixels dans la zone (par exemple)

en fait la règle si tu veux de la vitesse, c'est de rester le plus possible local à l'accélérateur 3D, quitte a faire des trucs tordus au premier abord.

sinon tu peux ptet jouer avec les clip planes si tu les as, mais ça impose 3 traçages de scène:
 
un pour la scène avant le début de zone (clip plane < zone_Z_min), un après la fin de zone (clip plane > zone_Zmax), et la dernière passe avec deux clips planes pour être dans la zone (tu auras deviné)....
 
mais j'ai peur que tu aies des problèmes de clipping (ptet des trucs bizarres aux liaisons)....
 
aussi ptet juste en jouant avec les zmin/zmax de la matrice de projection....
 
---
 
sinon tu peux aussi traçer la scène, mettre deux clipplanes, et la retraçer avec d'autres propriétées de matériaux avec blending... (genre multipasse classique à la quake quand y'a pas de multi texturing)
 
enfin si je dis pas de conneries, j'ai pas non plus trop expérimenté ce genre de conneries

J'ai quelques questions a propos de ton algo:
 
* Comment tu fasi pour désactiver l'update mais pas le test ? je ne vois que la commande glEnable (Gl_DEPTH_TEST)...
* Les quads que je trace effacent ma scene... est ce que c'ets justement du au test de Z ? ou alors je dois faire un glutSwapBuffers juste apres le tracage de la scene ?
* Quand tu parle de test stencil = 1, c'est glStencilMask (1) ?
 
merci d'avance !! et merci encore !
 

le glutSwapBuffers c'est pour faire l'échange entre le front et le backbuffer, donc non jamais ça. (hormis a la fin que tu est sûr que tout est fini)
 
oué pour les quads, il faut aussi couper l'écriture de la couleur des pixels en eux-mêmes... (il faut juste tester le quad contre le ZBuffer et actualiser le Stencil en conséquence)

alors j'ai regardé dans google les trucs qu'il fallait faire:
 
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
 
ça coupe l'écriture vers le buffer couleur.
 
glDepthMask(GL_FALSE), ça coupe l'écriture dans le Z-Buffer...
 
a toi de les placer au bon endroits....