Paramétrage de shaders

[TheToune]

Bonjour,

J'ai aujourd'hui un moteur qui fait un rendu sur le pipeline T&L classique en directx9 et je voudrais maintenant implémentés la gestion des shaders. J'ai lu pas mal de docs et je pense avoir saisi dans les grandes lignes comment permettre d'appliquer un shader dans mon programme et comment le paramétrer. (Je ne me suis pas encore vraiment penché sur l’écriture proprement dite que je n'ai que survolé)

Mais si j'ai bien compris qu'on devait définir dans le shader les paramètres à échanger avec le programme, il y a une information que j'ai du mal à trouver : Que deviennent les données du T&L comme les textures, les données de matériaux et des éclairage que j'utilise actuellement ? (SetTexture, SetMaterial, SetLight etc .... )

J'ai bien compris qu'on pouvais paramétrer ce qu'on voulait dans le shader, mais est ce que sa signifie que si je veut l'appliquer sur un objet je dois le paramétrer moi même avec ces données ou est ce que j'ai aussi accés au données transmise via device->SetTruc() dans le shader ?

Je me pose également des questions sur le coût d'un changement de shader et la façon dont ont le paramètre. Par exemple si j'utilise un shader différent sur certains objets de ma scène c'est pertinent où il faut éviter ? Et lors du changement de shader est ce que je doit tout reparamétrer ou est ce qu'il conserve ses paramétrés précédent ?

Merci

[ac_wingless]

Dans un shader, on n'a pas besoin, et d'ailleurs on ne peut pas, définir des matériaux ou lumières au sens de DX7.
On est censé écrire le programme qui va faire la même chose que T&L (ça c'est le coté ennuyeux, où il faut faire nous même des choses qui venaient sans effort auparavant), mais en contrepartie on peut choisir ce qu'on fait.

Il y a les VS ("vertex shader"), qui récupèrent en entrée des sommets 3D. C'est là par exemple qu'on peut calculer des lumières, voire des déplacements dus aux textures utilisées. On doit aussi faire des choses qui étaient "gratuites" auparavant en DX7, comme les projections. C'est intéressant car on n'est pas coincé dans un format de matrices 4x4 bien cadrées, mais c'est embêtant au début, car il faut faire soi même les calculs triviaux de projections. Cependant, il y des exemples déjà complètement mâchés dans le SDK.

Les PS ("pixel shaders") arrivent plus tard, après rastérisation (la rastérisation est d'ailleurs la seule étape de T&L qui a survécu en hard non configurable, et franchement c'est aussi bien, je vois pas l'intérêt de programmer des rastérisations spéciales, et les mésaventures de Larrabee semblent le démontrer). On a en entrée des coordonnées écran (à une matrice près), et tout ce qu'on a rajouté, et c'est là que c'est intéressant: par exemple on peut promener des numéros d'entité depuis le VS (du genre: deux pixels aux paramètres par ailleurs identiques peuvent être différentiés par des informations de très haut niveau), mais il y a plein d'autres astuces, y compris calculer des lumières beaucoup plus localement que ce qu'on peut faire dans un VS.

Il y a maintenant beaucoup d'autres types de shaders (depuis DX10 et 11), mais la base, c'est VS+PS, ça permet déjà de faire bien mieux que T&L.

Donc je vous conseille de retourner lire encore plus en détail les principes des shaders, (encore mieux: les pratiquer), pour voir de quoi il retourne, la plupart de vos questions tomberont d'elles-mêmes. Faire vraiment et attentivement, ligne par ligne, les 14 tutoriaux du SDK devrait vous amener directement à un niveau où vous pourriez répondre à presque la totalité de votre post, et ce en un ou deux jours de travail maximum.

Votre dernier point est plus délicat (cout de changement d'un shader), puisqu'il ne se réfère plus aux possibilités, mais aux détails de leur implémentation. En gros, les fabricants conseillent de grouper les appels à Draw par shader, ce qui est normalement peu adapté à une approche de haut niveau basée sur des meshes. Ça fait partie de la tambouille normale et attendue quand on se rapproche du métal. Par contre, un shader n'a pas de "paramètres" au sens de DX7, puisqu'il contient en lui même l'algorithme qu'il implémentera: pas la peine de le configurer.
Évidemment, un shader peut très bien utiliser des paramètres (qui sont fournis par des "variables"), mais on n'est pas dans le cas T&L où il faut rechanger toutes les lumières, matériaux etc.

Pour essayer de vous faire comprendre un peu mieux, on pourrait imaginer un shader qui implémente exactement le pipeline en dur de DX7. Il serait général au point de pouvoir faire tout ce que faisait DX7, et donc il aurait alors besoin de plein de paramètres, comme celui de DX7. La seule différence serait alors la manière de passer les paramètres: par des variables pour le shader, au lieu d'appels à l'API.
Dans un cas normal, on fait un shader pour implémenter ce qu'on veut, et il faut alors normalement beaucoup moins de paramètres. Surtout, les paramètres n'ont aucune raison d'être partagés entre shaders, donc pas besoin de reconfigurer juste parce qu'on change de shader.

[TheToune]

Merci beaucoup de cette réponse qui ne m'arrange pas mais qui confirme ce que je pensait ( craignait ^^) .

Evidemment j'ai l'intention de pratiquer et de comprendre. En fait si je pose cette question c'est parce que j'aimerais bien faire ces essais sur ce que j'ai déjà mit en place et que je préfère réfléchir un minimum avant de coder quoique ce soit ( surtout si c'est pour faire un truc qui ne pourra jamais marcher). Ma question ne vise pas tellement à savoir comment afficher un objet unique avec un shader mais plus à comprendre comment gérer le passage d'un shader à un autre dans une scéne. Je pense utiliser l'API CG qui apparemment et populaire.

J'ai aujourd'hui dans mon moteur ( directx9 ) un graphe de scène qui contient des objets faisant référence a des ressources à disposition dans un gestionnaire. Ce gestionnaire peut contenir des objet de textures(entre autres) avec une fonction qui ressemble à :

Code :

1
2
3
4
CRessourceTexture::SelectTexture(int sampler)
{
device->SetTexture(sampler, pTX /* pointeur sur ma texture */ ) ;
}

Mes matériaux et ma gestion des lumières fonctionne de la même façon.

Avec la possibilité de récupérer ce paramètre dans les shaders je n'aurais eu qu'a activer mon shader et même le gérer exactement de la même façon qu'une ressource standard sans me soucier de modifier la façon dont mes textures sont sélectionné. Et dans un monde de bisounours il me suffisait donc de faire un SelectShaders() pour changer l'effet sur un objet sans me soucier des paramètres "commun" de ma scène.

Du coup maintenant je vais me retrouver dans un contexte ou les paramètres de base change en fonction du shader ( et peuvent même changer de nom d'un shader à un autre dans l'absolu ).

Maintenant la texture n'est pas tellement un problème, j'imagine qu'un code comme celui ci devrait fonctionner :

Code :

1
2
3
4
CRessourceTexture::SelectTextureShader(char *nom_param)
{
  device/*ou api shader genre cg*/->SetParametreShader(nom_param, pTX /* pointeur sur ma texture */ ) ;
}

Par contre en ce qui concerne les matériaux (qui deviennent des variables du shader ) et surtout les lumières je sent que je vais avoir plus de difficulté, surtout la lumière en fait.

Mettons que ma scène dispose de 3 lumières ( ambiante, directionnelle et un spot ) avec une scène dont les objets utilise des shaders différents je doit donc reconfigurer mes variables définissant la lumière dans le shader ( peut être différemment ) chaque fois que j'en change ?
Apparemment l'API CG posséde des possibilités pour créer des variables communes entre shader. C'est une solution usuelle et viable pour gérer les sources lumineuse ou c'est une mauvaise pratique ?

En fait si je trouve et comprend comment marche un shader individuel j'ai beaucoup plus de mal à comprendre quel est la meilleure façon de gérer les informations d'une scène pour pouvoir les implémenter correctement. C'est surtout autour de ça que tourne mes questions.

[stardeath]

plutôt que cg, regarde directement hlsl.

il ne faut pas non plus s'en faire tout une montagne des shaders, de ce que je vois, tu utiliseras les shaders comme des matériaux et pas pour appliquer des effets plus exotiques.

pour toi ça ne changera pas grand chose, il te faudra programmer un shader ne demandant que les paramètres actuels de tes matériaux existants, et ensuite au lieu de faire un SetMaterial, tu feras un SetShader.

pour les lumières, ce n'est pas loin d'être la même chose, sauf que tu auras à programmer les shaders adéquats.

les exemples du sdk sont plutôt bien fait et utilisent les effets pour simplifier le passage au pipeline programmable.