bonjour,
je veux effectuer du supersampling en opengl pour l'antialiasing sans utiliser les accelerations hardware ( aucune extension ARB, WGL )
mais je ne vois pas comment implementer ca sous opengl??
 
Faire un render texture de grande taille puis le plaque sur un poly gone en 2D???
 
help me, please
je ne vois pas de solution

c'est quoi (en gros) l'algo du supersampling ?

 
ben justement je comprend le principe mais je vois pas l'algo openGL...

 
en gros, c'est tres con.
 
si tu veux une image finale de 128x128, tu calculs une image de 512x512 et tu applique un filtre de resize pour obtenir du 128x128
 
methos : oué ptet ben, tu rends dans une grosse texture te servant de pseudo back buffer et hop tu la réaffiche avec un vieux bilinear par ex... (par contre oublie de rendre ensuite un gros poly noir dans ta texture pour faire le clear..)

bah faut faire du render vers une texture, et ensuite plaquer la texture vers un quad... ca semble tout con non ?
 
Y'a des sources pour un render to texture sur mon site

le probleme c'est qu une texture de 2*1024 par 2*768 ne semble pas passer sur mon ordi ( matrox Geforce2)
 
chrisbk : au fait keske t appele un filtre resize??

matrox geforce2 ... o_O
... et ce serait pas une texture de 1024 par 768 plutot ??

si c'est un rendu en 1024*768 en fsaa 2x, avec ta technique faudrais faire le rendu sur une texture de 2048*1536, et en 1600*1200*fsaa4x (ca reste benin, meme si ca ralenti beaucoup), ca ferais 6400*4800 !
 
vous etes sur que c'est comme ca qu'il faut faire ?

ben c est ce que j avais compris...
Mais les cartes le font toutes seules sans passer par des textures surement.
moi je dois pas me servir des ameliorations hardware alors je vois pas d'autre solution a part filtrer la scene avec des matrices mais j y arrive pas . Mais je pense que ca sera aussi lent car parcourir tout les pixels d'une image et leur appliquer un filtre serait long aussi.
J'en suis donc rester au jittering qui marche bien mais qui est tres lent
 
argghhh!!!!!

oui, c'est pour ça que le supersampling a été abandonné. C'est une technique n'offrant aucune flexibilité et avec laquelle on arrive rapidement à des résolutions aberrantes pour un résultat bien mais pas top    
 
Et sinon pour revenir à la question : oui, il faudrait faire le rendu dans une texture, puis afficher cette texture sur un QUAD avec un MIN_FILTER LINEAR. Je note juste que pour faire un rendu sur texture dont la taille soit supérieure à celle de la fenetre et cela sans extension, ça va etre galere (mais possible)
Je note aussi que rendre la texture sur un QUAD (à la fin) revient à utiliser de fait l'accélération hardware pour effectuer le resampling.  
 
C'est un exercice pour un cours quelconque ou c'est pour le fun?

les samples tu n'es pas obligé de tous les prendre en meme temps dans une gigantesque surface.
 
Surtout si c'est pour faire des screenshots, tu peux alterner la position dans une meme surface de 1024x768.  
 
Dans l'idéal, tu pourrais faire du "jitterring" prendre la meme image à des positions relatives de moins d'un pixel de différence, en pratique ça risque d'interférer avec les méthodes de filtrage de texture (pas d'amélioration de qualité en cas de bilinéaire simple) et en plus il y a une "hard limite" lié à la précision interne de la rasterisation (mais c'est plutot théorique).
 
Je pense que le mieux c'est de rendre quatre fois quatre quadrants d'images (pour du supersampling 4x) et de faire le downfiltering à la main. L'inconvénient de cette méthode c'est que contrairement à la première tu n'as pas de controle sur la position effective des samples et donc tu dois en prendre "plus" pour une qualité de lissage de bords équivalente.  
 
Si tu as réfléchi un peu, tu vois que l'inconvénient de le faire en plusieurs fois dans un buffer de taille normal par rapport à une seule fois c'est le cout du "replay", ce qui est acceptable pour un screenshot mais inacceptable pour du rendu temps réel normal. C'est la raison pour laquelle les cartes graphiques en mode AA (en plus c'est du multisampling) ne feront que la version avec le buffer large.
 
LeGreg

pour ceux qui se demandent la différence entre le super sampling et le multisampling.
 
Le multisampling (au sens hardware du terme..) est nécessairement accéléré par hardware (pas émulable via rendu classique) et ne rend qu'un sample par pixel en général. Sauf dans les cas où le triangle ne couvre qu'une partie du rectangle du pixel (pixel coverage) dans ce cas il stocke des informations de couleurs supplémentaires + l'information de coverage.
 
En pratique, la plupart des cartes utilisent un super buffer de taille x4 et rendent la meme info de couleur pour tout le pixel et ne différent qu'au moment de finaliser l'écriture de la couleur dans le buffer de couleur qui n'affecte que les samples couverts par le triangle courant. Il y a des variantes (parhélia), des méthodes de compression (pour la bandwidth) etc.. mais le principe reste le meme.

merci , je savais meme pas qu'il y avais le super sampling et le multisampling

 
Ma remarque

visait justement à souligner qu'en l'absence d'extension, on ne peut faire de rendu sur une portion plus grande que la taille de la fenetre (cf pixel ownership), donc on est obligé de faire un rendu par morceau (dont la taille est <= à la taille de la fenetre) et se débrouiller pour le compositing.

 
Pour mon stage dans une boite de développement.    
 
 
 
bon j'ai finalement essayer le jittering qui est tres lent a cause de l'accum buffer...J'ai essaye de faire un rendu plus grand que ma fenetre et (sans extension) je n'y arrive pas, ou alors je suis nul.  
 
Sinon j'aimerais bien comprendre pourquoi je ne trouve que des extensions  opengl pour le multisampling ( ARB, NVIDIA ) et pas pour le supersampling (=FSAA si je ne trompe pas   ) alors que la methode employée aujourd'hui semble etre du FSAA.
 
 J'en conclue que l'antialiasing se fait tout seul (dans la config de la carte ) et n'a plus besoin d'etre implemente ??? Alors a quoi sert le multisampling????  
 
allez LeGreg je suis sur que tu as la reponse
 

bon je me repond a moi meme, en fait je me corrige!!
Mon erreur est due a la confusions des termes sur les sites de press.  
Le FSAA = Multisampling ( et ne peut etre implemente sans extension )et non supersampling

les extensions n'existent que pour le multi sampling, tout simplement parce que c'est la seule méthode que les gens qui font de la 3d temps réel veulent pour faire leur rendu.
 
Le super sampling a un cout supplémentaire qui ne se justifie pas aujourd'hui.
 
Ceci dit, si tu vas chercher auprès des cartes très chères de Evans & Sutherland ou Quantum 3D, ils proposent peut-etre des modes de rendu par supersampling dans leurs extensions OpenGL, je n'en sais rien vu que je n'en ai jamais vu une de près.

Multisampling (hardware) et supersampling sont toutes les deux des méthodes de FSAA (full scene antialiasing indépendamment de l'ordre et de la méthode de rendu).
 
On peut discuter du fait que le supersampling est plus full scene que le multi mais bon, c'est pour résumer.

C'est ce que j'essayais de t'expliquer plus haut. Tu ne peux pas faire de rendu plus grand que la fenetre sans extension car le contenu du framebuffer est indéfini pour les zones en dehors de la fenetre. Donc tu ne peux pas faire un CopyTex/ReadPixels sur une zone plus grande que la fenetre.
 

Comme expliqué par LeGreg, FSAA = full-scene antialiasing. Multisampling et supersampling sont deux approches différentes pour implémenter le FSAA. Le supersampling a été utilisé au tout début du FSAA (dans le matos grand public), en particulier avec le lancement des GeForce 2 GTS. A cette époque, on ne pouvait l'activer que via le panneau de config du driver. Dans les générations suivantes, le supersampling a été remplacé par le multisampling, plus performant. Du coup il n'y a jamais vraiment eu d'extension pour activer/désactiver le supersampling.  
 
Cependant, quand ARB_mutlisample a été intégré dans le core (OpenGL 1.3), ils ont modifié certaines choses pour supporter (via l'API) à la fois le multisampling et le supersampling. C'est un peu con, parce que ça introduit une confusion entre fonctionnalité et implémentation.  
Mais bon, vu où OpenGL en est, on ne se soucie plus vraiment de l'élégance maintenant.
Tout ça pour dire : les GF2 ne supportent pas le multisampling (le vrai). Elles n'exposent donc pas ARB_multisample (normal). MAIS comme le driver implémente 1.3 (ou +, je sais plus), tu peux quand meme utiliser l'API qui s'appelle multisampling (dans le core) pour faire en réalité du supersampling. C'est beau non?
 

En définitive oui. Il s'agit de toute maniere d'une option type  enable/disable, que ce soit via le panneau de config du driver ou via une API.
 
Alors pour résumer :  
soit il y a un support matériel pour le FSAA (que ce soit super- ou multi- sampling), et dans ce cas c'est tres simple, il suffit de demander un pixel format qui va bien (ou cocher l'option dans les propriétés graphiques), Enable/Disable, et ça se fait tout seul;  
 
soit il n'y a pas de support pour le FSAA et dans ce cas tu peux essayer le jittering, mais comme tu t'en es rendu compte, c'est lent (l'accum buffer n'est pas supporté en hard sur les vieilles cartes). Tu peux aussi essayer de faire le supersampling à la main (comme je pensais que tu voulais faire au début), mais c'est galere à implémenter et probablement tres lent (vu que les cartes qui vont executer ce path sont par définition vieilles donc lentes, sinon elles auraient un support matériel du FSAA).  
 
Ceci dit, si tu veux tenter le coup et qu'il ne s'agit pas d'un exercice pour un prof idiot ( ) tu peux essayer de profiter au maximum de ce qui est disponible sur ta plateforme pour accélérer les choses; je pense par exemple aux PBuffers (en attendant mieux) pour effectuer ton rendu sur texture. Premierement t'as pas de readback sur le framebuffer, donc ça va plus vite que la méthode traditionnelle. Ensuite, ça te permet d'avoir un buffer plus grand que la fenetre, ce qui évite de faire un rendu par morceau. WGL_ARB_pbuffer est dispo sur à peu pres tout ce qui existe( TNT, intel i810, Rage 128)
 
Voila  

Merci pour ces explications qui clarifient tout.
 
Par contre il  n'y a pas  WGL_ARB_pbuffer sur ma geforce2mx/SSE ( version 1.4.0 ) si j'en crois  
 le Get extensions...
Mais j'ai teste le jittering sur les nouvelles cartes et ca passe bien sauf que finalement elles n'en ont plus besoin car elles font du FSAA.
 
une derniere chose qui m'intrigue, il semble que la gestion de ARB_multisample soit tres recente chez ATI (la radeon 9000 ne le gere meme pas)
Mais si j'ai bien compris ce n'est pas grave car leur drivers le gere (par le biais de openGL 1.3). Et le programmeur n'a donc pas besoin de s'en preocuper.
C'est bien ca non?
 
ps:désolé, tout ca n'est pas tres clair pour moi, je decouvre juste tout se charabia d'extension, driver, soft, core, hard...