Discussion :

[lison1]

Bonjour,

j'espère que je poste mon message dans la bonne catégorie ...

Donc voila, je travail sur un projet (scolaire) dont le but est l'utilisation de shaders. Je code en XNA et mes shaders sont en hlsl. (on doit ensuite faire marcher le projet sous xbox 360)

Il y a quelques question que je me pose et je suis sure que des gens pourront me répondre ici

En fait, j'ai compris que les vertex shader, puis le pixel shader remplacent des parties du pipeline graphique. Je vois donc a peux près le fonctionnement quand on a un pixel shader et un vertex shader.

Mon problème est quand on veux exécuter plusieurs shader à la suite. Comment ça se passe?
J'ai vu qu'on peux faire différents "pass", mais comment ça marche?
(je comprends pas trop puisque chaque pixel shader renvoie une couleur donc qu'est ce qu'on en fait?, comment on spécifie comment le programme doit les combiner ou laquelle il doit choisir?)

par exemple, je veux faire un shader de shadow map. il faut donc, après avoir calcule la shadow map dans un shader, récupérer celle ci dans une texture puis appliquer un test a chaque objets. seulement, mes objet ont déjà un effet...

Je ne sais pas si je suis très compréhensible, mais en gros, j'aimerais comprendre le fonctionnement des "pass" quand il y en a plusieurs.

Merci de votre aide !

[acx01b]

??? tes objets ont déja un reflet

c'est à dire ?
ce sont des mirroirs ? ils sont éclairés ?

pour les shadow map il faut faire comme ça:

affichage de la scène vu de la lumière
z-buffer -> texture
affichage de la scène vu de l'oeil, et dans le pixel shader, on teste si le pixel est dans l'ombre en consultant la texture que tu viens de créer

pour ça il faut utiliser les matrices pour passer des coordonnées oeil aux coordonnées lumière (calcul dans le vertex shader --> interpolation --> utilisation du résultat dans le pixel shader)

le truc du "calcul dans le vertex shader --> interpolation --> utilisation du résultat dans le pixel shader" est utilisé dans 99% des shaders

je sais pas si ça répond à ta question mais on enchaine pas les shaders, on enchaine les rendus ! (comme si une fois sur 2 on affichait toute la scène vue de la lumière, puis toute la scène vue de l'oeil)

[lison1]

Merci de ta reponse,

non, mes objet n'ont pas de reflet, mais un effet (un shader).

en fait, j'ai ma scène et j'applique un shader différent à chaque objet. (phong, shader de bois, etc...).

j'ai mon shader de shadow map, mais je sais pas comment m'en servir.
pour calculer la shadow map, pas de problème, je regarde la scène vu de la lampe et je retourne le résultat du pixel shader dans une texture.

Mais je voudrais maintenant appliquer mes ombres à ma scène. Faut-il que j'intègre le "test" d'ombre dans chacun de mes shaders? ou il y a une solution qui me permettrai de le faire dans un shader séparé?

Et si je veux appliquer d'autres shaders a la totalité de ma scène, "par dessus" les autres, comme un brouillard ou un depth of field. De quelle maniere combiner les shaders?

et à quoi servent les differents pass?

[lison1]

Bon, j'ai toujours pas compris comment marche l'enchainement des passes, donc si quelqu'un en sait un peu sur le multipass, je prends les info.

sinon, j'ai un autre soucis,

je doit gérer plusieurs sources lumineuses dans ma scène, et donc, je doit envoyer plusieurs shadow map a mes shader. Mais hlsl n'a pas l'air de vouloir gérer des tableau de texture, comment je peux faire?

[LeGreg]

Les passes servent à couper un calcul trop complexe en plusieurs passes équivalentes (ou suffisamment proches) arithmétiquement.

Exemple : tu veux que ton renderer calcule texture * (diffuse * shadowtest + ambiant)
C'est à dire pour s'abstraire A * (B*C + D)
Problème ta plateforme (une très vieille carte graphique..) ne sait faire qu'une seule multiplication par passe de shader. Mais a aussi la capacité de faire du "blending" simple c'est à dire de combiner le résultat du rendu précédent avec celui du rendu courant.

Solution possible à ce problème :
tu rends d'abord Depth + ambiant. Tu ne rends que l'ambiant sans texture ni rien d'autre dans le premier pixel shader. Tu fais ça pour tous tes objets.
Ensuite tu mets le depth test à "equal", tu mets le blending en mode additif (prends le contenu de la rendertarget qui contient l'ambient et combine en additionnant avec la passe courante). Le pixel shader courant va faire l'opération B*C, c'est à dire tu vas prendre la valeur de l'éclairage diffus à cette position multipliée par la valeur du test de shadowmap (0 ou 1). Grâce au blending et au test "depth equal", pour chaque pixel tu vas avoir B*C + D.
Maintenant pour la troisième passe, tu mets toujours le depth test à equal, tu mets le blending en mode multiplicatif (prends le contenu de la rendertarget qui contient l'ambient et la lumière diffuse et combine en multipliant avec la passe courante). Le pixel shader courant va simplement lire la couleur depuis la texture puis grace au blending multiplicatif, tu auras le resultat du shader multiplié par la couleur du pixel déjà dans le back buffer. Au final ton back buffer contiendra donc texture * ( (diffuse * shadowmaptest) + ambiant) c'est à dire ce que tu voulais au départ modulo les erreurs de saturation et d'arrondi.

C'est pour un exemple très simple, que la plupart des cartes graphiques modernes pourraient facilement faire en une seule passe mais ça te donne une idée du concept mathématique de base.

En gros tu as une opération complexe que pour une raison X ou Y la carte graphique ne pourrait pas faire en une seule passe (trop de lumière par passe, trop de textures, trop d'interpolants etc.) et donc tu dois la décomposer en N opérations que tu appelles "passes".

Bien entendu ce n'est pas possible pour tous les cas, il faut que l'opération à décomposer soit dans une classe très particulière d'opérations (c'est à dire que les passes ne communiquent que par le biais d'une seule variable temporaire stockée dans le back buffer et que cette temporaire peut souffrir d'être à précision réduite si ton buffer est en ARGB8). Et cela ne peut pas bien marcher s'il faut utiliser le blending pour autre chose (objets semi-transparents).

La plupart des limitations disparaissent si tu généralises le concept de passe en n'utilisant non pas le blending avec le backbuffer mais le render to texture, beaucoup plus flexible (N textures par passes de shader et les opérations peuvent êtres plus complexes que multiplication, addition etc.). C'est la base de beaucoup d'algorithmes dit de "deferred shading", mais la limitation (du moins sous Direct3D9) est la perte des infos de multisampling dans le render to texture (beaucoup de jeux programmés pour le deferred rendering ne peuvent plus activer l'antialiasing).

Voilà j'espère que la réponse te suffira.

[lison1]

Merci beaucoup, je comprends un peu mieux !

en fait, on peux ajouter, ou multiplier les couleurs rendu par les différents passes.

Je vais essayer de faire ça. J'espère que ça va marcher !

Au moins, ça me permet de séparer mon test d'ombre du reste, ce qui est, je trouve un peu plus propre.

Merci beaucoup !

[LeGreg]

Merci beaucoup, je comprends un peu mieux !

en fait, on peux ajouter, ou multiplier les couleurs rendu par les différents passes.

Je vais essayer de faire ça. J'espère que ça va marcher !

Au moins, ça me permet de séparer mon test d'ombre du reste, ce qui est, je trouve un peu plus propre.

Non, pas plus propre, dans l'idéal tu ne sépares les passes que si tu y es obligé. Le faire par "propreté" c'est la porte ouverte aux performances faiblardes parce que chaque passe rajoute au coût CPU et de changements d'état (hardware). Les passes inutiles sont la première chose à éliminer. La méthode c'est : tu mets le maximum de choses dans une passe. Ensuite tu vois comment batcher au mieux les textures avec les constantes et les renderstate en conflit (cela implique parfois de faire des compromis au niveau du rendu..). Et tu introduis plusieurs passes pour les hardware qui n'en peuvent pas plus.

Ou tu choisis une approche deferred. Les approches deferred ont des profils de performance différents.
Pour un exemple, tu as le dev de GSC gameworld (Stalker) qui explique comment ils ont mis au point leur système de rendu deferred dans GPU gems 2. Leur approche était jusqu'à récemment la plus radicale qu'on puisse trouver dans un jeu commercial (peut-etre battu depuis peu par certains jeux consoles mais tous les devs n'ont pas publié leurs algos).

LeGreg

[lison1]

J'ai essaye de faire ça, et ça marche pas mal, mais j'aimerais mettre le blending en mode multiplicatif.

j'utilise ça : (dans xna)

graphics.GraphicsDevice.RenderState.BlendFunction = BlendFunction.Min;

mais si je n'ajoute pas a une couleur (0,0,0,1) chaque pixel, les zones claires deviennent transparentes.

Je ne trouve pas comment faire pour utiliser le mode multiplicatif. Je n'ai accès qu'a l'addition, la soustraction, le min et le max.

ha aussi, est-il possible de faire une opération du genre :
(A*B)+(C*D)

?? et comment??

mon problème est que je veux combiner un effet par objet, les ombres portées, et plusieurs sources lumineuses.

j'ai intégré le calcul des multiples sources lumineuse dans chaque shader, mais je ne peux pas passer un tableau de shadow map à mon shader.
Il faudrait donc plutôt que j'intègre mon test d'ombre dans chaque shader et que je fasse ensuite une somme sur mes sources lumineuses?
(ici j'en veux que 3, nais si j'en avait 8 ça serait vraiment lent, non?)

En tout cas merci, j'ai deja mieu compris comment "combiner" les rendus.

[smashy]

Pour repondre a la question initiale, il faudra bien incorpore les effets que tu veux (ombre , brouillards ...) au shader de l effet "normal" (bois , ...)

Pas simple a cause de la combinatoire (0 shadow_map , 1 shadow_map , 2 shadow_map +- brouillard ....) le nombre de shader explose.

La plusieurs methodes possible :

-generer le code du shader a la volee (en gros des copier-coller de fragments de programmes)

-le defered shading (voir stalker par exemple) : Dans le defered shading, tu calcules pour tout point de l'ecran des donnees qui peuvent etre utiles pour la suite des effets (position du pixel dans le repere camera , normal , couleur ambient diffuse speculaire ...) et ensuite tu appliques les effets que tu veux dans une seconde passe sur toute la scene. Note que toutes les donnees de la premiere passe utilisent plus de 4 composantes (R,G,B,A) , on utilise donc traditionnnellement le MRT (multiple render target).

[lison1]

Merci de vos réponses !

J'ai maintenant fini le projet (c'était un projet scolaire) mais je n'ai pas réussi à faire tout ce qui était demandé.

Il fallait faire une nature morte en 3d, avec au moins 4 objet et chacun un shader différent. Il fallait des ombres porte et au moins 3 source lumineuses. Il fallait également un autre effet de lumière et un shader de post process.

Il fallait également que le projet tourne en temps réel sur xbox360 et qu'on puisse se déplacer dans les 6 degrés de liberté avec la manette.

Et tout ça dans un temps très court, avec plein d'autres projets a faire en parallèle !

J'aurais bien aimé faire un truc mieux, mais bon j'ai pas réussi, malgré vos explication, a intégrer mes ombres au reste...

donc voilà, si vous voulez voir ce que j'ai fait :
http://fr.youtube.com/watch?v=Ev0v8UHVb1I

encore une fois merci pour votre aide !

[Harooold]

Moooh,
si c'est pas trogon les petits coeurs sur la tapisserie

Il y a quand même un petit problème au niveau de la shadow map, causé par ton cullface je suppose, vu que tu élimines les faces intérieures de la teiere et que le couvercle n'est pas assez large, ben on la lumière passe

C'est pas bête de faire des videos et mettre sur youtube !
Je cherchais un moyen simple et pratique de montrer un peu ce que je fais sans avoir à m'enquiquiner avec une compilation windows et tout les problèmes de distribution qui vont avec ...

Merci pour l'idée :p

[lison1]

Oui, pour la shadow map, cest sans aucun doute une histoire de backface culling, mais c était un détail, alors j ai même pas essaye de le résoudre

pour les vidéos, à vrai dire, je n y avait pas pense non plus, mais ici les prof nous demandais une vidéo youtube comme rendu, en plus du code et d un rapport expliquant le code. Mais c est vrai que c est une façon sympa de montrer ce qu on fait.