Une sorte de FSAA "progressif"
 
Voila l'idée : Quand est-ce qu'on a le temps de voir les effets d'aliasing ?  
 
Quand on run a 100 Km/h dans une map a Quake3 apres ce trou du cul de bot qui a toujours un frag de plus que vous ?
 
Quand on fragge tout ce qui bouge dans RTCW ?
 
Quand on vole sur notre X-Wing a l'assaut de dark vador dans son Tie Bomber en rase motte sur Mon Mothma ?
 
Nan, c certain, on a pas le temps.
 
Ca bouge trop vite pour qu'on puisse imprimer dans notre oeil l'image fixe d'une arete, et de voir que merde c un escalier en fait.
 
Par contre, quand on joue a NFS5 avec la bagnole la + maniable (et donc la + lente, zont toujours été originaux ce style de jeu), quand on regarde dans quake3 a l'arret la beauté d'une map maculée de sang apres un quad damage de folie...
 
La on a le temps de le voir.
 
D'ou l'idée de ne PAS L'IMPOSER tout le temps, comme on fait actuellement. Style tout le temps FSAA2x, Quincunx, ou 4X (voire +), mais bien de le faire suivant L'ACTION DE LA SCENE ACTUELLEMENT DECRITE
 
Ca serait parfait ! Si on s'arrete, paf, on grimpe d'un cran, FSAA4x, on peut, c'est magnifique, ca bouge pas...
 
on se met a bouger, paf, le framerate descend... zut, on soulage le proco, et on met du 2x...
 
On s'arrete et la repaf, y a de la marge, on fout le FSAA4x, car c'est plus beau et on a la puissance nécéssaire.
 
On pourrait l'implémenter de +sieurs facons en plus :
 
-On mesure l'intensité de la charge du GPU, la bande passante mémoire, ou le framerate a la sortie (si tant est que cette valeur est calculable) et on agit selon celle ci. Plus il bosse, moins on peux faire de FSAA... Donc on obtient une sorte de compromis que le joueur devra effectuer DANS les pilotes.
 
-On prends des parties de l'image comme point de référence, et on regarde entre chaque frame le nb de pixel ayant changé de couleur... si c'est important, on bouge bcp => on baisse le FSAA...
 
Evidemment, cela suppose que 'lon puisse changer la technique de FSAA a la volée, et ce sans interruption visible par l'utilisateur... mais pourquoi pas, vu qu'il s'agit d'un callcul effectué sur une frame unique, donc il suffit de changer le mode de calcul a la frame d'apres, ou betement de ne pas le faire ?
 
Ca vous semblerai pas génial cette idée
 
Moi ca me botterai
 
Et que dire de l'utilité d'une telle fonction sur des consoles !  
 
Vous croyez pas ?
 
j'attends des interventions intelligentes bien sur, sur la faisabilité ou non de la chose ...
 
barbarella, je t'attends particulièrement !
 
Yoyo3d aussi

Que dire, à part KESKETATTEND pour programmer le driver ?
 
Bien sûr que c'est une bonne idée, je me posais la même question à propos de la profondeur de champ ce matin dans la voiture.

a mon avis les transitions fsaa 2x/fsaa 4x risquent de faire crade en temps réel, genre saute d'image

C'est ce que je pense aussi.

Brillant !
tu pourrais présenter ton idée à ATI et devenir ingénieur ché eux !
mets vite un brevet sur ce système aussi    
sinon graphiquement ça le ferait !
pkoi personne y a pensé ?

 
Pas dit !
 
Car qu'est ce qui se passe : c'est du HRAA, donc uniquement certaines parties changeront...
 
mais il faudrait que cela soit bien fait, au bon moment, cad au moment ou la puissance disponible commence a etre la... et que le joueur se déplace encore afin que la transition se fasse de facon transparente...
 
Un réglage fin devrait permettre de faire ca facilement ! Style le FSAA4x s'enclenche quand tu boufge encore légèrement...
 
Si tu t'arrete brusquement, l'intervalle de changement ne sera pas d'une seconde mais de quelques frames ( 1 ou 2 en théorie) et  la ca se fait donc en 1/75ème de seconde...

 
J'aimerai tant m'y connaitre assez pour pouvoir le faire
 
J'ai jamais touché a un driver de ma vie !
 
Et je doute qu'on puisse le faire dan l'état actuel du FSAA (ou on ne peux le changer sans redémarrer le jeu)

c pas con comme idée mais d'un autre coté faudrait aussi que les jeux soit programmé pour ça  ( ex : nfs5   >100 kmh fsaa 1 voir 2x <50kmh fsaa 8x )

ark a écrit a écrit : Brillant ! tu pourrais présenter ton idée à ATI et devenir ingénieur ché eux ! mets vite un brevet sur ce système aussi     sinon graphiquement ça le ferait ! pkoi personne y a pensé ?

 
, je n'ai pas ces prétentions...
 
mais c vrai que l'idée est alléchante

 
Ou tu peux le rendre indépendant en monitorant toi meme la charge du GPU...

 
Ca risque pas de ressembler un peu à une "usine à gaz" ton truc ?
Le driver qui fait monitoring de la bande passante mémoire restante afin de switcher de mode de calcul (et donc d'algo)...  
 
Sinon l'idée de FSAA progressif est alléchante.
J'avait un pote qui bossait en R&D sur les cgs et autres rendus 3D l'année dernière. Dommage qu'il soit parti vers d'autres aventures (Suisse), ton idée l'aurait sûrement intéressé...

[jfdsdjhfuetppo]--Message édité par zi_ril_wanou--[/jfdsdjhfuetppo]

ben un des problemes c que tu veux faire changer la fonction en fonction de quoi exactement ? en fonction du deplacement du bonhomme (deplacement spatial ) ou tout simplement en fonction du déplacement de la souris... ? parce qu'en fait les images seront toujours en mouvement ... et tu peux faire défiler les images aussi vite en restant immbobile qu'en courant dans un couloir..
a ce moment la faut faire un systeme de compression style mpeg 2 ou on a une comparaison d'image et juste mettre le fsaa sur les objets qui changent réellement
nan.?

Q : comment un gpu pourrait t'il savoir qu'il va être à genou pour le calcul de la scène à venir ?
 
A: bein il peux pas, un gpu n'est pas une voyante!
 
Q: en ce cas, pourquoi ne pas intégrer une mémoire au gpu qui garderai trace des variations du temps mis à calculer les dernières frames affichées (la charge instantanée)?
 
A: a proiri c'est pas trop le boulot d'un gpu ni d'un driver, mais plutot d'un moteur 3d temps réel, puisque c'est le sujet qui nous interesse.

[jfdsdjhfuetppo]--Message édité par robochito--[/jfdsdjhfuetppo]

robochito a écrit a écrit : Q : comment un gpu pourrait t'il savoir qu'il va être à genou pour le calcul de la scène à venir ?   A: bein il peux pas, un gpu n'est pas une voyante!   Q: en ce cas, pourquoi ne pas intégrer une mémoire au gpu qui garderai trace des variations du temps mis à calculer les dernières frames affichées (la charge instantanée)?   A: a proiri c'est pas trop le boulot d'un gpu ni d'un driver, mais plutot d'un moteur 3d temps réel, puisque c'est le sujet qui nous interesse.

 
Et ce travail pouvant etre généralisé a tous les moteurs 3d car IDENTIQUES (sans aller jusqu'a la précision de l'objet, trop néorme actuellement), pourquoi ne pas le foutre dans les drivers ?
 
robochito : Une frame de retard, soit 1/60ème de second au pire... est-ce si grave que cela ?

 
non ca ne se percoit pas je pense    
 
mais bon les tecnhniques d'antialias en haute rez deviendront un rigolade dans un futur proche :
 
l'antialiasing prends un temps constant qq soit l'image sur laquelle il est caluclé. Donc quand les gpus seront suffisement puissants pour plier ça sans rogner sur le reste des calculs, on n'y pensera même plus.
 
à l'heure actuelle on a encore de pauvres gpus qui sont gravement pénalisés par la somme de calculs que représente un fsaa 4x. Je dirais 50% du temps sur une grosse nvidia.  
Je parie que dans 3ans cela prendra moins de 10% en plus sur le temps de calcul d'une scène moyenne de quake5.
 
donc tout le monde sera en fsaa4x sans pertes de perfs perceptibles ou presque.

[jfdsdjhfuetppo]--Message édité par robochito--[/jfdsdjhfuetppo]

slyde a écrit a écrit :     Revoie tes classiques de star Wars, tu nous a bavé un horrible truc qui n'a pas de sens (tu fais des razmot' sur la leader de l'Alliance rebelle toi ? ).   - L'un des petits problèmes c'est qu'actuellement pour moi un jeu charge le proco à 100% tout le temps : s'il y a pas grand chose à rendre, il render plus de frames / sec. S'il y a trop de choses à rendre, le framerate se casse la gueule.   - Les 3DFX permettaient de passer en FSAA à la volée à coup de touches sur le clavier une fois le truc reglé dans le pilote. Honte à vous.   - J'imagine aussi que le passage 2x -> 4x doit mal rendre.   - La carte elle sait pas que ca bouge : elle crache bêtement ce qu'on lui demande. Les optimisations dont tu parles seraient plutôt à faire du coté appli   - La "technologie" serait sans doute plus couteuse à mettre en place question temps que d'appliquer directement un FSAA 4x partout.   Le plus faisable finalement serait de moduler le niveau de FSAA des textures par rapport au LOD, et/ou utiliser en prime un truc encore plus gore que le Trilineaire.

 
Ouai bon star wars euh
 
Le passage FSAA2x => 4x rendra peut etre mal, peut etre bien... On ne peux finalement statuer.  
 
C vrai que ca passe d'un effet de flou inférieur a un supérieur... ca va etre visible.
 
La carte ne sait pas ce qui bouge. Nous, on peut lui dire si ca a bougé ou non, en comparant des pixels, en regardant la chharge disponible dans le GPU (merci de lire ce que j'ai mis... le coup du truc qui bouge, c de la vulgarisation bete et méchante. )
 
La technologie sera certainement couteuse a mettre en place, c clair. Mais Nvidia a deja programmé le HRAA, qui lui ne s'applique QUE sur les bords des polygones, et plus sur chaque pixels de l'image... c'est deja assez pointu, et a été implémenté. Face a ca, mon truc, c du pipi de chameau en boite.
 
Pour le Lod, ouai, a voir... Je vois pas ca du tout comme ca  en fait.

Ce serait pas plus simple de pousser les constructeurs de cartes grafik de nous faire des cg pouvant afficher un Q3 ou autre a 2000*2000 en etant fluide tout le tps?

Donc en gros vous qui gueulez que vous devez upgrader vos config tout le temps, vous demandez  de nouvelles cartes  encore plus puissantes, mais betes et méchantes...
 
Désolé, mais je pense que l'optimisation des facons de calculer, d'afficher, d'appliquer des effets et aussi importante  que de dispoer de cartes + puissantes pour faire les trucs de base, algorithmes de boeufs, + rapidement.

PS : slyde : c'est exactement ce style de réponses la que je cherche

Euuh, je me pose une question, l'application du FSAA ne se fait pas au chargement des textures ?? Car en fait si ca marche encore au supersampling il charge les textures en plus grande résolution (non pas au niveau du moteur du jeu mais au niveau du GPU) et applique un filtre de redimensionnement, et dans Quake 3 pour changer de résolution il faut se taper un /vid_restart pour recharger les textures en mémoire. Ca c'est si j'ai bien comris le truc.
 
Bref, je sais pas si c'est faisable en temps reel ...
 
EDIT : Je viens de lire la reponse de slide sur le switch du FSAA en temps reel sur la 3Dfx et la je passe pour un con  

[jfdsdjhfuetppo]--Message édité par ZeTortue--[/jfdsdjhfuetppo]

Le FSAA se fait a la toute dernière étape, une fois que tout a été appliqué (textures, etc)...
 
 
laquelle ca correspond prrrrrrrt
 
en tout cas, tu as du mal capter ce qu'était le FSAA vu que sur Voodoo en tout cas on peux le changer en temps réel...

oui ben voila kwoa , t'as vu toi meme
 
Le FSAA ne s'applique pas sur les tecutres mais bien sur l'image de fin allant etre dessinée sur le monituer ...
 
Le but c pas d'avoir des tectures plus fines, mais d'enlever l'effet d'escaliers des polygones (Anti-Aliasing)

ON A UN PAERCU RAPIDE (tres succint), du changement de FSAA a la volée :
 
http://www.nvnews.net/previews/gef [...] ison.shtml
 
Sympa
 
Chargez les images et cliquer ensuite sur les liens, ca bascule automatiquement !

C'est sur que c'est super beau !!
 
Mais le FSAA n'est valable que dans les hautes résolutions pour en mettre plein la tronche, sinon ca fait trop "bouillie" a mon gout.
 
Mais bon, essayer le FSAA c'est une grosse erreur !! Genre avant que ma TI 500 ne parte en fumée je m'était amusé a balancé du Quake 3 en 1600x1200 en Quicunx la 3D ultime mais non jouable, puis apres tu reviens en 1280x1024 normal et la t'a beau faire tu vois plus que ca, les effets d'escaliers !!  
 
Alors tu finis par te dire "Tain, la geforce 3 c'est pas encore ca !!". Alors tu galere, tu change 1000 fois de résolutions, tu met un petit coup de filtre anisotrope en 2x, puis 4x mais ca tourne plus tres bien, alors tu baisse ta résolution et tu met du FSAA Quicunx, puis non ca va pas parce que quand le cyborg te saute a la tronche ca se met a ramer, alors tu switch encore et encore jusqu'au moment final ou t'en peux plus et tu laisse tomber, tu reviens en 1280x1024 et tu sent super heureux que ca tourne !!
 
J'ai la meme histoire avec le regalge du contraste...
 
Perturbé, moi ??  

[jfdsdjhfuetppo]--Message édité par ZeTortue--[/jfdsdjhfuetppo]

ZeTortue a écrit a écrit : C'est sur que c'est super beau !!   Mais le FSAA n'est valable que dans les hautes résolutions pour en mettre plein la tronche, sinon ca fait trop "bouillie" a mon gout.   Mais bon, essayer le FSAA c'est une grosse erreur !! Genre avant que ma TI 500 ne parte en fumée je m'était amusé a balancé du Quake 3 en 1600x1200 en Quicunx la 3D ultime mais non jouable, puis apres tu reviens en 1280x1024 normal et la t'a beau faire tu vois plus que ca, les effets d'escaliers !!     Alors tu finis par te dire "Tain, la geforce 3 c'est pas encore ca !!". Alors tu galere, tu change 1000 fois de résolutions, tu met un petit coup de filtre anisotrope en 2x, puis 4x mais ca tourne plus tres bien, alors tu baisse ta résolution et tu met du FSAA Quicunx, puis non ca va pas parce que quand le cyborg te saute a la tronche ca se met a ramer, alors tu switch encore et encore jusqu'au moment final ou t'en peux plus et tu laisse tomber, tu reviens en 1280x1024 et tu sent super heureux que ca tourne !!   J'ai la meme histoire avec le regalge du contraste...   Perturbé, moi ??

 
La, ca deviens grave...

heu...en fait vu que le FSAA c est vraiment utile que dans certain jeu... soit ca marche et c est nickel ( nfs5 et autre jeux de caisse je pense) ou alors ca marche et en fait on a pas le tmp de voir la difference ( Q3, unreal ) ou alors ca marche po ....
 
donc mon avis c est qu il faudrait que le jeu controle le FSAA vi le moteur graphique... genre qd le moteur graphique calcul une scene importante ( genre bcp de texture et autres effet qui font tout ralentir ) il vire le FSAA etc...
 
mais dans ce cas si on utilise le FSAA c est pour ameliorer la qualite de l image donc son activation implique un resultat visible donc si on voit une amelioration de l image lorsqu on acitive le fsaa on peu logiquement supose qu en cas de diminution de celui ci la qualite de l image diminuera aussi et que le joueur verra une image moin belle
 
la baisse de qualite de l image sera t elle alors suportable ??
parce que qd je vois la diference entre le 1024*780 sans FSAA et le 1024*780 fsaa 4x ben heu c est pas vraiment la meme chose
 

 
ps: desolai pour les fotes
ps2 : j ai dis des conneries ??

Kaori Makimura a écrit a écrit : heu...en fait vu que le FSAA c est vraiment utile que dans certain jeu... soit ca marche et c est nickel ( nfs5 et autre jeux de caisse je pense) ou alors ca marche et en fait on a pas le tmp de voir la difference ( Q3, unreal ) ou alors ca marche po ....   donc mon avis c est qu il faudrait que le jeu controle le FSAA vi le moteur graphique... genre qd le moteur graphique calcul une scene importante ( genre bcp de texture et autres effet qui font tout ralentir ) il vire le FSAA etc...   mais dans ce cas si on utilise le FSAA c est pour ameliorer la qualite de l image donc son activation implique un resultat visible donc si on voit une amelioration de l image lorsqu on acitive le fsaa on peu logiquement supose qu en cas de diminution de celui ci la qualite de l image diminuera aussi et que le joueur verra une image moin belle   la baisse de qualite de l image sera t elle alors suportable ?? parce que qd je vois la diference entre le 1024*780 sans FSAA et le 1024*780 fsaa 4x ben heu c est pas vraiment la meme chose     ps: desolai pour les fotes ps2 : j ai dis des conneries ??

 
euh
 

 
Arretez les délires comme ca
 
Réfléchissez un peu
 
Si chaque moteur devait faire ca...
 
Quant au début, ben relis : tu piques ce que j'ai dit, quasi mot pout mot.

En fait, le fsaa se fait à la fois en première et en dernière étape: le fsaa, ça consiste à calculer une scène dans une haute résolution, puis à l'afficher dans une basse résolution. C'est une opération qui est donc loin d'être simple, et qui ne peut pas se faire "à la volée" selon l'intensité de la scène. C'est comme de dire qu'on pourrait faire un driver qui est en 800x600 quand ça va vite et en 1600x1200 qd ça va lentement...

 
Le FSAA consiste à changer la couleur d'un pixel via les pixels adjacents, surement que ca passe par une résolution supérieure exact...
 
J'y avais pas pensé, on est encore en supersampling...
 
Donc en fait, celui de 3dfx passais car on étais loin du supersampling avec eux... ahlala.
 
Bref, j'aimerai bien des infos sur cette histoire car ca commence a devenir confus.

 
Finalement, ta technique marcherai avec des 3DFX et non avec des NVidia!!!  
 
 

[jfdsdjhfuetppo]--Message édité par partymaker--[/jfdsdjhfuetppo]

en fait pour ce qui est de la voodoo (4 et 5 uniquement il me semble) il y a bien une option pour "enlever" le fsaa. le probleme, et ils le precisent bien, c'est que au niveau materiel, le fsaa est tj active et pompe donc tj le gpu et la bp mais il n'est pas affiche. cela n'a donc aucun interet dans le debat. le but de ce truc la c'est soit de comparer ou alors d'ameliorer la qualite graphique (ex: je sais pas chez vous mais chez moi le fsaa sur nfs5 rend l'image tres sombre sur certaine map c'a devient injouable).
 
sinon je trouve l'idee interessante mais je rejoint l'idee de certain a savoir que ce serait surment une usine a gaz ton truc. j'entend par la que ca risque de pomper pas mal de calcul rien que pour savoir quand l'appliquer ou non (a moins de faire un systeme de choix extremement simple donc largement moins interessant) et le gain final ne risque t'il pas dans certaines scenes de degrader simplement la qualite ou le framerate sans raisons.
la je parle pas des bugs, tout le monde connait deja des deboires hallucinantes avec ses drivers je sais pas si ca vaut le coup d'en rajouter une couche (tout le monte se souvient du hsr qui pose encore bp de probleme, meme sur les derniers drivers).
 a suivre donc mais j'y croit pas et vu l'evolution actuelle, meme si je pense pas que ce soit la bonne solution, on s'oriente certainement vers la solution de facilite a savoir des gpu qui nous afficheront 400 i/s tout le temps et qui nous couteront la peau du cul (solution de facilite pour les constructeur bien evidemment)
 
edit: j'ajouterais qu'avec l'augmentation constante des resolution d'utilisation, le fsaa risque de devenir inutile a moyen terme

[jfdsdjhfuetppo]--Message édité par princo22--[/jfdsdjhfuetppo]

la je suis pas sur de ce que j'avance, en tout cas pas dans l'exactitude mais le fsaa des 3dfx ne fonctionne pas exactement comme ca. en fait la carte(voodoo 5) calcule quatre (fsaa X4) images au lieu d'une. donc au lieu de calculer une image tout les 1/40 de sec par exemple, elle va calculer une image tout les 1/10 de sec et "additioner" les quatres pour en obtenir une seule. bien sur ca c'est la theorie en en pratique la carte sera dans ce cas loins de 4 images tout les 1/40 de sec...
donc sur une 3dfx le fsaa se fait purement au depend du framerate (et on le sent d'ailleurs)

[jfdsdjhfuetppo]--Message édité par princo22--[/jfdsdjhfuetppo]

Y'a quelques points que je voudrais aborder :
 
Le problème principal, c'est de switcher les modes, c'est dans le principe du système changer la résolution voir la méthode d'antialias lors du shrink de la résolution de render à la résolution de l'affichage.
 
Et là y'a bcp de choses qui interviennent, quand on change un mode de traitement d'une scène ( résolution, nb de couleurs, technologie d'algo, traitement des fonctions du GPU ), y'a un délai, ça ne se fait pas à la volée.
 
Tout simplement parce que la carte reconstruit l'environnement complet à ce moment là.
 
Disons qu'on passe d'un 2X -> 4X, la mémoire déjà ne sera pas occupée de la même manière, ensuite les fonctions hardware ne sont probablement pas les même, c'est à dire que le GPU est prévu pour être optimisé sur un mode choisi mais pour changer de mode et devoir changer la façon de traiter les infos de la même manière
 
Ca nécessiterait donc plus des capacités/fonctions hardware que software. On peut toujours le faire par drivers mais là on perdrait quand même je poense des perfs, ce qui aménerait à rendre le jeu plus agreable et moins saccadé ( surtout si ca switch souvent ) en laissant carrement le FSAA.
 
Ensuite il faut peut etre aussi que DirectX le gère, parce qu'entre le moteur et les drivers, il se pose en plaque tournante des fonctions 3D ( ou OpenGL, c'est idem )
 
Faut voir aussi que lorsqu'on switchera par exemple en 4x, les perfs vont morfler d'un coup et il voudra en voyant la baisse de perfs repasser en 2x ( la cata, il aura juste switché pour tuer quelques frames et il le fera sasn arret quand c'est fluide en 2x ). Du coup on gérera un timer avant que ça reprenne le test, mais qui va le gérer ça ? Qui va gérer de dire "ça rame" ou "c'est fluide" ? Bah faudra bien surement que ce soit le moteur et le CPU central Le GPU il aime bouffer des polygones, des textures, des effets, des modes, etc... Mais c'est pas son taf de gérer un timer, une staturation etc... Lui on lui dit tu traites ça, tu prends tout ce qui t'arrives, et tu recrache sans réfléchir avec toutes tes super fonctions qui vont bien...
 
Je pense donc que si ça doit être fait un jour, ce sera en hard sur la carte et implémenté comme fonction dans DirectX en plus
 
Mais par contre le vrai problème pour eux est de gérer le switch de mode sans perturber la struture ( mémoire, traitement en cours ) du fonctionnement de la carte, sans être obliger de reinitialiser certaines choses ( ce qui parait difficile déjà si on doit changer la résolution de l'image construite avant resize/algo d'antialias )
 
Bref un gros casse tête, je pense que l'idée n'est pas nouvelle, mais qu'elle pose un certain nombre de problèmes qui la rende peut être moins pratique que de faire une carte assez puissante pour etre fluide toujours en 4x dans le futur ( )
 
En tout cas, je pense franchement que ce n'est pas viable par un driver uniquement, déjà pour les problème de switch qui seront très visibles ( reinit de certaines choses ) et ensuite parce que là, il faudrait je pense feintouiller DirectX

[jfdsdjhfuetppo]--Message édité par Sly Angel--[/jfdsdjhfuetppo]

Remarque: (peut être totalement Off Topic )
 
La fonction "adaptive supersampling" (jusqu'à 12 je crois), notament sur les wildcats de 3D labs, ça serait pas déjà une ébauche de ce système? Bon je suis sur que le driver analyse pas s'il s'agit d'un jeu de caisse ou de quake, mais plutot qu'elle antialiase de façon inconditionnelle ou ça en a besoin. Mais quelqu'un connait?

Magic_Poussin a écrit a écrit : Remarque: (peut être totalement Off Topic )   La fonction "adaptive supersampling" (jusqu'à 12 je crois), notament sur les wildcats de 3D labs, ça serait pas déjà une ébauche de ce système? Bon je suis sur que le driver analyse pas s'il s'agit d'un jeu de caisse ou de quake, mais plutot qu'elle antialiase de façon inconditionnelle ou ça en a besoin. Mais quelqu'un connait?

 
Ca m'interesse aussi de savoir tiens
 
Je pense ( si c'était mon idée ) que ce serait tout simplement l'algo d'antialias qui serait plus intelligent et ne s'appliquerait qu'aux endroits où il y a un brusque changement de couleurs, je veux dire là où on détecte une cassure dans le dégradé, genre on fait la moyenne uniquement sur des points qui ont une grande différence de valeur de couleur.
 
Le seul truc qui me chagrinne c'est que ça n'intervient en optimisation que sur le resize de l'image, à moins qu'il y ai une bidouille du même genre dans les zones de textures qui sont générées dans la résolution d'arrivée...
 
En tout cas si c'est sur l'algo d'antialiasing lors du resize, c'est plus simple à gérer, y'a juste que le calcul est un peu différent, on ne switch aucun mode...
 
Si quelqu'un a une URL d'une bonne doc complète sur ce sujet...

 
 
donc aparement ca passerai mal si en passant par les drivers... mais si on passait par le moteur du jeu + driver
 
d apres ce que j ai ( mal ) compris, une parti du fsaa consiste, en une egalisation des couleur afin de masquer l effet d escalier ?? et pourqoi ca serai pas le cpu qui s en cargerai ??
 
on a des gros cpu et je pense pas que ca les gene bcp de faire qque calcul en plus nan
 
vu que aparament un des probleme du fssa c est la baisse de perf si au lieu de switcher de mode de fsaa on donnai certain calcul en plus au cpu au lieu que ce soit la cg qui calcul tout
 
 

Kaori Makimura a écrit a écrit :     donc aparement ca passerai mal si en passant par les drivers... mais si on passait par le moteur du jeu + driver   d apres ce que j ai ( mal ) compris, une parti du fsaa consiste, en une egalisation des couleur afin de masquer l effet d escalier ?? et pourqoi ca serai pas le cpu qui s en cargerai ??   on a des gros cpu et je pense pas que ca les gene bcp de faire qque calcul en plus nan   vu que aparament un des probleme du fssa c est la baisse de perf si au lieu de switcher de mode de fsaa on donnai certain calcul en plus au cpu au lieu que ce soit la cg qui calcul tout

 
Bah disons que si c'est pour le faire en software, c'est con de l'avoir implémenté dans le GPU
 
Comment dire, en fait la puce a été faite pour traiter les fonctions de FSAA avec des optis et des capacités faites en interne ( fonction faite en hardware bien plus rapide que par le drivers ), donc si tu fais un truc que la carte ne gère pas en interne, c'est le CPU qui s'en occupe et là tu peux limite le faire avec n'importe quelle carte graphique
 
Tu perds toutes les perfs du processeur dans le domaine

Désolé, c'est pas franchement ce qu'on peut appeller très "technique" ( ) mais ça donne un bon apperçu de comment fonctionne le supersampling made in 3D labs  
 
Edit, je suis un crétin, j'ai oublié l'url... et j'ai mis 3 ou 4 h à m'en rendre compte
 
  http://www.3dlabs.com/product/tech [...] iasing.htm

[jfdsdjhfuetppo]--Message édité par Magic_Poussin--[/jfdsdjhfuetppo]

un FSAA dynamique? Je crois que ça existe déjà... mais côté calcul c'est peut être encore plus gourmant...