il faut trouver comment calculer les trois valeurs au debut du snippet d'au dessus:
- pixel_normal
- pixel_position_in_viewspace
- specular_power
pour pixel_normal et specular_power, c'est pas complique, on les a dans les textures du GBuffer rendu a la passe precedente.
par contre, pixel_position_in_viewspace... bah.. soit tu rajoute une rendertarget dans le GBuffer pour stocker la position du pixel ... en viewspace \o/ donc float4, au mieux half4
soit tu utilise la depthmap
t'as les coordonnees x, y du pixel a l'ecran (gl_FragCoord.xy), et la profondeur du pixel -> tu peux reconstruire sa position.
Hep hep hep, c'est quoi cette méthode pour faire tenir les normales en deux composantes ?(et les deux autres c'est quoi ?)
tu prends la normale en screenspace.
vu que les normales sont normalisees, tu as:
1 = sqrt(x^2 + y^2 + z^2) = x^2 + y^2 + z^2;
z = sqrt(x^2 + y^2);
donc deja, si tu stocke juste x et y, tu peux reconstruire le z de la normale
(enfin, si tu stocke x*0.5 + 0.5 et y*0.5 + 0.5 en R, G)
aussi, vu que c'est une projection d'hemisphere, la normale peut etre soit dans l'hemisphere qui te fait face, soit dans l'autre, typiquement elle sera dans l'hemisphere qui te fait face, MAIS..
- avec les normalmaps, tu peux avoir des normales qui pointent dans l'autre sens (DANS l'ecran, pas en dehors), et concretement ca te fout plein d'artefacts de merde dans ton rendu)
- la precision des normales sur les bords de l'hemisphere est nulle a chier...
tu peux grandement ameliorer ces deux points en faisant:
RG = sqrt(z * 0.5 + 0.5) * normalize(xy);
ca remappe la normale dans une cercle qui est le depliage de la sphere des normales, dont la seule singularite se trouve au pole le plus eloigne de l'ecran, celui qui pointe dans l'ecran, et que tu vois en gros jamais.. hmm bref.
ca fait chier faudrait vraiment remettre la main sur ce talk de crytek, ils expliquent ca avec des images et tout, c'est quand meme plus clair...
bon bref...
les deux autres, c'est:
- ce qu'on appelle pour hh la shinyness (une valeur entre 0 et 1, plus ou moins 1/spec_power. 0 represente une surface parfaitement reflective, 1 une surface parfaitement diffuse... bon ok en fait ca devrait plutot s'appeller diffuseness, ou diffusitiveness, ou.. bref.. voila quoi
)
- le "normal reflectance factor", c'est un parametre du modele d'approximation de BRDF qu'on utilise (les approximations de BRDF, c'est genre phong, blinn/phong, cook-torrance, ward, beckmann, etc... c'est differentes approximations du comportement d'une surface soumise a de la lumiere. un BRDF, c'est une fonction a 4 dimensions, la "Bidirectional Reflectance Distribution Function" (go google si ca t'interesse, c'est un topic a part entiere ca
))
bref, donc voila, pour notre modele d'approximation de BRDF, on a besoin de ca en plus.
le normal reflectance factor, ca va dire en gros quel pourcentage de lumiere est reflechie par la surface lorsque le reflection_vector.light_vector == 1. ca permet de simuler les surfaces comme la peau (et beaucoup d'autres), qui sont speculaires pour les angles de vues rasants, mais tres diffus pour les angles de vue perpendiculaires)
Rah putain, ça non plus je ne comprends pas à partir de quoi ils sont générés, mais c'est trop classe Non justement, et j'aimerais bien savoir d'où ils sortent les paramètres de déformation ^^
c'est plus ou moins un fake. dans les exemples d'au dessus, le shader refracte le view-vector sur cette normalmap:
va chercher la depth dans le depth buffer a l'endroit du pixel rendu (c'est une approximation tres moche), et calcule la distance d'intersection entre le plan a cette profondeur et le rayon refracte. (au final niveau calcul c'est tres simple, c'est tout des plans alignes a l'ecran), et ecrit les composantes x,y du vecteur refracte * cette distance / distance du pixel a l'oeil, dans le buffer de deformation
pour les surfaces de flotte, ca serait juste la normale de la surface au lieu de la texture au dessus...