you're welcome
) pour refaire passer ma normale en view space avant de la mettre dans le G-Buffer, et faire ça pour chaque pixel ? Ça me parait spécialement violent, j'ai du passer à côté d'un truc ?
hmm okay pourquoi pas, tu vas ptet te faire un peu chier pour implementer tout ca de maniere efficace ouai
Ensuite, les normales : je viens de réaliser que c'était des normales en view space qu'on voyait dans ton screen (en même temps vu qu'on a plus les modèles au moment de rendre les lumières, ça pouvait difficilement être dans le model space). Mais si je veux faire du normal mapping, je suis à un moment obligé d'avoir ma normale en tangent space pour pouvoir la manipuler dans le même repère que la normal map. Ça veut dire que dans ce cas je dois calculer la matrice inverse ("inverseTangentModelViewMatrix" du coup) pour refaire passer ma normale en view space avant de la mettre dans le G-Buffer, et faire ça pour chaque pixel ? Ça me parait spécialement violent, j'ai du passer à côté d'un truc ?
bearbecue (./35) :
par contre, heu.. OpenGL ES?hmm okay pourquoi pas, tu vas ptet te faire un peu chier pour implementer tout ca de maniere efficace ouai
(mais bon tant pis, ça m'amuse d'avoir un résultat qui tourne dans un browser)- fetch de la normale en tangent space dans la normalmap, viespacenormal = tangentspacenormal.x * tangent + tangentspacenormal.y * normal + tangentspacenormal.z * tangent.w * cross(tangent.xyz, normal);
| tangent.x tangent.y tangent.z | | normal.x normal.y normal.z | | bitangent.x bitangent.y bitangent.z |
(bref))))
Zeph (./36) :Wow ça doit être carrément pratique ça, tu l'as acheté où ?
je vais sortir mon bloc-note et mon crayon 3D
bearbecue (./37) :
bah ca revient a construire une matrice de rotation 3x3 avec chacun des axes de la nouvelle base qui represente ton tangent-space en viewspace quoi
'tangent' c'est l'axe X de la base, 'normal' c'est l'axe Y, et binormal (donc tangent.w * cross(tangent.xyz, normal)), c'est l'axe Z
) compris cette technique, c'est autrement plus modulable que mon ancien gros shader qui gérait 4 lumières et mes N passes pour cumuler les scènes plus complexes ^^
). C'est possible que sous OpenGL ES il y ait un antialiasing automatique, ou un filtre qui pourrait expliquer la différence ? (je ne sais pas exactement quoi googler pour trouver l'explication).
), est-ce que c'est la même méthode qui va être utilisée, ou bien est-ce que ça se fait habituellement avec une autre technique ?
le but c'est de faker l'illumination globale de la scene, qui serait trop couteuse a calculer en temps reel. l'ambiant, c'est la lightmap du pauvre, qui est elle meme l'illumination globale du pauvre 
)
) pour un exemple aussi simple () tu pourrais faire ca de plein de facon differentes... par contre, des que t'as des cas un peu moins triviaux, genre un vaisseau au milieu () qui projette une ombre sur un des murs, le nombre d'options diminue pas mal
), et... bref.. ca pue un peu du zgeg
)
)
)
bearbecue (./46) :
1- bah, c'est un peu space la formule la
).btw, je suis pas sur de ce que c'est "diffusePower" dans ta formule, mais si c'est un parametre du materiau, alors ca peut etre inclus dans "diffuseColor" (et c'est pas la meme chose que "specPower", qui typiquement permet de controller la taille de la tache speculaire, et qui dit, grosso modo, a quel point le materiau est diffus ou reflechissant: plus la specPower est elevee, plus le materiau est reflechissant.
)... sauf si ca t'interesse
2- bah pour les ombres... (classe dessin) qui projette une ombre sur un des murs, le nombre d'options diminue pas mal
le principe est assez simple:
- tu fais un rendu depuis la light, comme si c'etait une camera. imagine une spotlight: tu set l'angle d'ouverture du cone de lumiere en tant que fov de la camera, et tu rends ta scene.
- le rendu en question, c'est juste une depth-map: c'est la shadow map.
- apres, pendant la passe de lighting, quand tu vas processer cette spotlight, pour tous les pixels de ta scene qui sont dans le cone d'eclairage de la light, tu vas transformer les coordonnees du pixel avec la "shadow matrix" qui va en fait les transformer en clipspace de la light.
- a partir de la, t'utilise le x,y des coordonnees transformees en tant que coordonnees de textures dans la shadowmap.
- tu recupere la depth dans la shadowmap. - si le 'z' de la coordonnee du pixel en shadow-space est superieur au z stocke dans la shadow-map, ca veut dire que quelquepart dans la scene, le long du rayon qui va du pixel a la light, il y a un autre objet qui a ecrit un pixel plus proche dans la shadowmap, et donc qui est plus proche de la light ---> ton pixel est dans l'ombre. sinon, il est eclaire.
Oui justement, la question était de savoir s'il était intéressant de traiter les cas triviaux à part, ou bien s'il y avait "la-méthode-qui-déchire-tout" et qui permettait de tout gérer de la même façon.
Ouh... en effet sur le principe c'est simple, par contre ça doit être une vraie misère au niveau des performances, finalement je suis quand même obligé de parcourir les objets et les lights pour rendre toutes les shadowmaps nécessaires ? :/
diffuseTerm = matDiffuseColor * (ambientLight.IntensityRGB + light0.IntensityRGB * dot(normalize(light0.Pos - pixel.Pos), pixel.Normal) + light1.IntensityRGB * dot(normalize(light1.Pos - pixel.Pos), pixel.Normal) + light2.IntensityRGB * dot(normalize(light2.Pos - pixel.Pos), pixel.Normal) + ... ); pixelColor = diffuseTerm + specularTerm;
(enfin à la différence près que tu fais entrer la lightAmbientColor dans la composante qui dépend de matDiffuseColor, pour une raison qui m'est encore inconnue
emissionTerm = ambientLight.IntensityRGB; diffuseTerm = matDiffuseColor * (light0.IntensityRGB * dot(normalize(light0.Pos - pixel.Pos), pixel.Normal) + light1.IntensityRGB * dot(normalize(light1.Pos - pixel.Pos), pixel.Normal) + light2.IntensityRGB * dot(normalize(light2.Pos - pixel.Pos), pixel.Normal) + ... ); specularTerm = ...; pixelColor = emissionTerm + diffuseTerm + specularTerm;
emissionTerm = matEmissionColor; diffuseTerm = matDiffuseColor * (ambientLight.IntensityRGB + light0.IntensityRGB * dot(normalize(light0.Pos - pixel.Pos), pixel.Normal) + light1.IntensityRGB * dot(normalize(light1.Pos - pixel.Pos), pixel.Normal) + light2.IntensityRGB * dot(normalize(light2.Pos - pixel.Pos), pixel.Normal) + ... ); specularTerm = ...; pixelColor = emissionTerm + diffuseTerm + specularTerm;
)
(l'aspect "sol trempé" est voulu, le choix de texture aurait pu être moins stupide mais on fait avec ce qu'on a )
en gros tu fais du raymarching dans la heightmap, et t'as une grosse boucle dans ton shader (ya plein de variations, principalement pour reduire le nombre d'iterations avant de trouver l'intersection, et d'ameliorer la precision de l'intersection)
)
(et nettoyer mon code qui commence à être sacrément atroce...)