25Fermer27
ZephLe 14/02/2012 à 00:14
wow grin

bon, il va me falloir quelques jours pour lire, digérer, tenter d'extraire des infos, comprendre, revenir, poser des questions et boucler à l'étape 1 sur tous ces posts grin Mais merci pour ton temps smile

Je reprends dans l'ordre des posts les trucs qui m'échappent mais pour lesquels je peux encore me raccrocher à quelque chose (parcequ'il y a aussi des trucs hors d'atteinte pour le moment, chaque chose en son temps grin). Ça peut être juste des problèmes de vocabulaires, vu que j'en suis encore à essayer de mettre des noms sur des trucs que j'ai pu lire à droite à gauche ^^
apres, tu te demmerde pour packer tout ca dans un framebuffer avec le nombre le plus faible de rendertargets possibles.

Une "rendertarget", c'est quoi, une image de la taille du rendu final dans laquelle un pixel shader peut enregistrer une info (RGBA) par pixel ? Si oui, je ne savais même pas qu'on pouvait faire autre chose que la rendre, justement, et donc a fortiori qu'on pouvait en avoir plus d'une grin

Faut que je regarde en OpenGL/GLSL comment on fait smile

[edit] bon, dans le lien de Golden ça parle de multi-render target, donc je suppose que c'est bien ça, je saurai quoi chercher quand j'essaierai d'implémenter ça ^^
a la fin de cette passe, t'as deux rendertargets qui contiennent toutes les normales, diffuse colors, spec coeffs, de ta scene, que tu peux rebinder a un autre shader en tant que textures.

Bon d'après ça je vais supposer que ma compréhension du point précédent était la bonne. Du coup c'est surpuissant ce truc, en effet ^^
ensuite, dans une deuxieme passe, tu prends toutes les lights de ta scene, et tu les affiche avec un shader qui prend les deux rendertargets d'au dessus en tant que textures, la depth map, et calcule l'eclairage.si ta light couvre toute la scene, tu la rend avec un fullscreen quad, sinon, t'affiche une primitive basique qui recouvre les zones d'influence de la light a l'ecran (une sphere, ou un carre/rectangle en 2D a l'ecran).

Hey mais c'est énorme ça, donc pour toutes les lumières vraiment éloignées on a potentiellement une toute petite zone à retraiter, j'imagine que le gain doit rapidement pouvoir être énorme... par contre si on veut faire cette optimisation, j'imagine que c'est mort d'envisager gérer plusieurs lumières simultanément dans le shader des lumières (à moins d'avoir deux lumières qui affectent exactement la même zone, mais c'est improbable, sauf pour celles qui prennent tout l'écran, bref). Si je résume, la première passe crée tes deux rendertargets, puis on applique les lumières une à une en partant de ... ? le rendu initial sans lumières, qu'on a aussi calculé lors de la première passe ?

Pour la transparence, je saute pour le moment, j'y reviendrai quand le reste sera moins flou ^^
À propos du light-prepass rendering :
une fois le G-buffer rendu, comme au dessus, tu fais une passe sur toutes les lights.
mais c'est pas le materiau final qu'elles vont rendre.
c'est l'eclairage recu par chaque pixel de la scene : le light-buffer(avec la composante speculaire optionellement dans l'alpha. apres, si tu veux un rendu exact, il te faut du RGB pour le spec aussi, donc il te faut un light-buffer et un spec-buffer separe.)

Ayé je commence déjà à être largué. La composante spéculaire, c'est bien le produit scalaire entre le vecteur "caméra" et le vecteur de direction de la lumière, élevé à une puissance qui dépend du matériau ? Du coup c'est quoi les autres paramètres dont on a besoin et pour lesquels il faut utiliser un buffer RGB supplémentaire ?
Edit: dans les buffers d'au dessus, la depth est rendue explicitement dans un buffer RGBA8 a part, parceque tu peux pas sampler la depth-map directement en DX9 (et tout le rendu de hh est fait en DX9 :/

Heu j'ai du louper un truc, mais vous vous en servez pour quoi de la depth-map ? Je n'arrive pas à voir à quel moment il vous faut la réutiliser ? D'ailleurs je ne comprends pas du tout le screenshot Sanctum_LinearDepthBGRA8.png grin (la valeur de profondeur est codée dans les composante GB ? lapin compris o_O)
Screenshots du post ./15:
normales encodees en coordonnees ecran spheriques (2 composantes R, G) + parametres du modele de lighting (2 composantes B, A)

Hep hep hep, c'est quoi cette méthode pour faire tenir les normales en deux composantes ? grin (et les deux autres c'est quoi ?)
output dans une 2eme rendertarget du meme framebuffer des vecteurs de distortion pour un postprocess de deformation en screenspace, pour simuler la refraction de l'air due a la chaleur (ca peut servir aussi pour la refraction de surfaces diverses, y compris de la flotte)

Rah putain, ça non plus je ne comprends pas à partir de quoi ils sont générés, mais c'est trop classe grin
Bon, pendant que j'y suis, au cas ou tu t'en foutrais pas, des details sur le dernier buffer (Distortion and blur)

Non justement, et j'aimerais bien savoir d'où ils sortent les paramètres de déformation ^^
ah merde heu oui les ombres...

Bon là je zappe, ça fait trop pour le moment, je vais juste bookmarquer tout ça pour le jour où j'aurai compris jusqu'ici grin

Merci encore, beaucoup, vraiment, vous deux smile