ca consiste a koi??  des images a l apui car j en entend parler mais personne n est capable de me dire ce ke c vraiment comme procédé :?:  
 
thx

Bon je vais me tenter à une réponse un poil plus prècise que celle ci dessus, ça sera ptet un poil technique aussi mais c'est difficile à expliquer sans rentrer dans les détails
 
Donc Pixel Shader en très gros c'est ce qui remplace l'application de texture câblée des anciens chips 3D en offrant beaucoup plus de contrôle au programmeur.  Dans la pratique c'est un ensemble d'instructions qui sont de deux types :  
 
-les instructions d'adressage : qui servent pour aller chercher une valeur dans une texture, texture qui perd alors son rôle classique de simple "papier peint" apppliqué à un polygone pour devenir une sorte de tâble de précalcul on appele ça une look up texture en anglais.
 
-les instructions arithmétiques : qui servent comme leurs noms l'indique à effectuer de l'artihmétique signée au niveau des pixels.
 
Concrètement ça sert à quoi ? Et bien comme je l'ai dit à offrir plus de contrôle au programmeur. Traditionnelement l'application de texture n'avait qu'un rôle basique, petit à petit ce rôle a évolué pour offrir des effets plus évolué comme le multitexturing (application de plusieurs textures pour simuler certains effets) mais aussi une forme limitée de bump mapping. Petit à petit de nouveaux modes de combinaison de textures sont arrivés pour gérer des effets spécifiques et l'ensemble à commencer à devenir très lourd à manipuler car ce n'était pas prêvu pour à la base. Avec l'évolution des GPU il a été possible de supprimer toutes ces recetes de cuisine offrant des effets câblés (un exemple connu : l'EMBM ou environmental bump mapping apparu avec la G400), pour quelque chose de plus souple, c'est là qu'interviennent nos fameux Pixels Shaders. Grâce aux Pixels Shaders tu peux faire quelquye chose comme ça : bon je peux t'expliquer comment c'est fait mais je doute que ça t'intéresse juste un détail c'est que grâce aux Pixels Shaders tu peux approximer du Phong shading c'est à dire qu'au lieu de calculer l'éclairage aux sommets tu le calcules directement aux Pixels. Bon c'est juste un survol mais i lfaut savoir que les Pixels Shaders c'est le nom que Microsoft leur a donné sous DirectX, le Flipper par exemple n'a pas les Pixels Shaders mais autorise un certain contrôlle du pipeline de rastérisation au niveau de l'adressage des textures et au niveau des opérations sur les pixels qui permet d'offrir des fonctionnalités similaires.
 
Bon j'ai été interrompu dans ma rédaction ce qui fait que j'ai oublié des tas de truc s que je voulais mettre mais je complèterais lorsque ça me reviendra

merci   personne n a pas un exemple avec un jeu?

 
Par exemple

thx

 
alors pixel shader ou pas ?  :?:

g pas le souvenir ke la PS2 gére le pixelshader, donc nan sen ai pas (a mon avis perso bien sur)

bien sur que c'en n'est pas ,PixelShader(tm)  est un nom deposé pour dire que tu peux faire des effets de texture au pixel.
 
Tu peux malgres tout faire des effets de texture sur  ps2 ,dans une mondre mesure ,en multipasses

 
c donc 1 illusion du pixel shaders c ca ?

 
c donc 1 illusion du pixel shaders c ca ?
 
Non c'est du rendu multipasse c'est ce que je décrivais donc mon message comme ce qui existait avant les pixels shaders. Certaines opérations sont impossibles et c'est moins souple, mais ça permet de faire des trucs jolis quand même (surtout sur console où on code directement "to the metal" ). Par contre certains effets sont impossibles et surtout c'est gourmand.

en effet ,en particuler sur des questions de 3dtextures.
 
T'as des exemples des exemples de trucs impossibles (sachant que le dot3 le fur et le  3dtexture dynamic lighting on etes refabriqués sur ps2)
?

Ben forcément y'aura toujours un moyen de faire ça en software en modifiant 'on the fly' la texture en VRAM ...
Mais pour un algo water qui peut être pris 100% via le pixel shader, la différence de performance est assez importante... pour certains algos elle est telle qu'il est impensable de le faire en temps réel en software donc oui le pixel shader permet de nouveaux effets en temps réel.

il ne permet pas de nouveaux effets .... il permet d'utiliser des effets trés gourmants sur l'autre machine ( donc inutilisable en pratique !  fais voir un jeu PS2 Fur + dot3 Bm ) dans la pratique et sans une perte de ressource préjudiciable !

la profondeur de champ et les perturbations atmospheriques ne sont pas franchement  nouveaux sur ps2 ...(je me doute que ce que tu decris  permet d'autres choses.. )
 
Pour le DoT3 c'est 4 passes.

Oui oui mais je pense que sur PS2 c'est plutôt obtenu en effectuant des manipulations dans le frame buffer ce qui ne doit pas être très coûteux vu la bande passante de celui ci. La profondeur de champ et les effets atmosphériques c'était deux exemples sur GC qui m'ont traversé l'esprit et que je pense réalisé grâce à ça mais à la base c'est essentiellement utilisé pour faire du perturbed UV bump mapping ou plutôt environmental bump mapping comme l'a baptisé Matrox.
 
En tout cas ça autorise des effets intéressants

bah si le GS peut pas le faire ils ont contourner le prob d'une façon ou d'une autre chez naughty dog (effets de chaleur sur les torches dans Jak and Daxter)

par contre la technique de profondeur de champ en passant par des mipmap c'est pas mal comme idée
 mais pour la ps2 je pense comme koren que c'est un traitement direct dans le framebuffer, apliquer une sorte de blur dont l'intensité est determiné par le z-buffer

Sauf que vos perturbations se sont au niveau des vertex et pas au niveau des pixel, allez donc modéliser des micro perturbations avec des vertex et vous aurez des artefacts d'affichage.

tu genere un UV par pixel ?? ...

 
Bah les UV sont définis aux vertex et interpolés par pixel bien sûr

decidement ,je pige pas
 
Des peturbations a l'UV et des perturbations au vertex ,c'est pareil,a part la 3d en plus pour les vertex.
( les VUs peuvent creer des vertex a la volée (pas les vertexShaders).
 
a moins que tu ne parles de textures perturbées proceduralement au pixel (comme l'eau dans le premier unreal ) ?

en faite tu veux dire que la dependance texture perturbe les UV de l'autre texture pendant la rasterisation meme du poly pour chaque pixel et pas seulement l'UV du vertex?
 
dans ce cas effectivement c'est interressant
 
edit: remarque en reflechissant c'est logique sinon ca n'aurait effectivement aucun interet

 
Exactement
Les lectures de texture se font dans le pixel shader, shader qui est appliqué à chaque pixel rasterisé.

donc en faite tu utilise seulement 2 gros Poly qui couvre l'ecran sur lequel tu aplique la texture depandante (rendu de la scene) perturbé par une texture procedural en resolution d'affichage et t'a des perturbation au pixel pres

hmm. ca doit manger du fillrate ce genre de truc (un full screen procedural)..?

 
C'est l'astuce effectivement, maintenant je dis pas que c'est effectivement fait comme ça sur NGC c'est juste une idée que j'avais qui me semblait bien coller à l'architecture de la machine. Mais au fait maintenant que t'as un PC t'as quoi comme carte vidéo ? Parce qu'il y a des démos très intéressantes dans lesquelles justement lorsque tu affiches la scène en wireframe tu t'aperçois qu'il y a au final très peu de polygones. Dans ce domaine il y a une démo d'EMBM dans le SDK DirectX avec des effets d'eau impressionnant, eau réalisée avec seulement deux triangles !

j'ai une toute petit GF4mx
 
oui pour l'eau je vois bien ce que ca permet

le truc couteux ca doit etre quand meme de generer la texture procedural si c'est au pixel pres