Je fais un peu de travail sur certains de nos shaders HLSL, essayant de les faire fonctionner dans SM2.0. J'ai presque réussi, mais un de nos shaders accepte un paramètre:Émulation de VFACE sémantique dans PS_2_0 Shader
float alignment : VFACE
Si je comprends bien MSDN c'est un var automatique calculé dans le cas où je en ai besoin, mais il ne fonctionne pas sous SM2.0 ... donc , comment pourrais-je reproduire cela? Je ne suis pas un programmeur de shader donc tout (pseudo) code serait vraiment utile. Je comprends ce que VFACE fait, mais pas comment je pourrais le calculer moi-même dans un pixel shader, ou dans un VS et le passer dans le PS. Le calculer par pixel semble cher alors peut-être quelqu'un peut montrer un squelette pour le calculer dans un VS et l'utiliser dans un PS?
VS ne reçoit-il pas la face normale du triangle et a-t-il accès à la position/au vecteur de la caméra? Je ne sais pas comment il pourrait accéder à ces derniers, ou même si un _can_ VS passer des valeurs à la PS de toute façon? –
Bien sûr, les VS reçoivent des visages normaux et peuvent également accéder au vecteur de visée (si vous le transmettez au VS). VS peut également transmettre des valeurs au PS. Mais cela ne vous donnera pas VFACE. Du moins pas précisément parce qu'il y a des cas d'angle où les deux normales d'un tri seront détectées comme étant face à face et la dernière face à face (ou deux face à face et une face à face). Il en résulte des artefacts très désagréables (j'imagine que vous utilisez VFACE à des fins d'éclairage latéral). Cela est dû à l'interpolation des attributs dans le rastériseur. La seule façon de le faire correctement est d'utiliser deux passes comme je l'ai indiqué dans ma réponse. – Stringer
La normale _face_ est identique pour chaque sommet d'un triangle, je pense que vous vouliez dire que le VS peut accéder aux normales _vertex_, ou _interpolated_ face normales? Ce n'est pas pour l'éclairage, mais votre point d'artefact reste valide ... mais cela vaut la peine d'essayer. –