30

ok top
you're welcome smile
avatar
HURRRR !

31

Bon, un autre batch parceque j'ai voulu m'y mettre et que ça n'a pas donné grand-chose grin

Pour commencer j'ai voulu reprendre des bouts de code que j'avais déjà écrits en WebGL, donc OpenGL ES 2.0, et d'après ce que j'ai compris il n'y a pas moyen de faire de multi render target. Je suis un peu confus sur les relations entre "framebuffer", "renderbuffer" et "texture", mais si je n'ai pas compris de travers un framebuffer est une target de rendu, et on peut y binder des renderbuffers (ou des textures) pour stocker la couleur, la profondeur, etc. En WebGL, c'est un seul framebuffer avec un seul renderbuffer maximum. C'est chiant, mais a priori pas incontournable, c'est juste qu'il va falloir que je rende plusieurs fois la même scène en changeant de renderbuffer pour récupérer toutes mes infos, au lieu de pouvoir faire tout en une seule passe.

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 hum) 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 ?

Bon et puis il va falloir que je lise la spec OpenGL ES, parceque je ne sais pas si c'est mon renderbuffer qui est mal bindé, ou si je lis mal dedans, ou si ça n'est tout simplement pas un renderbuffer qu'il fallait utiliser, mais en tout cas pour l'instant ça donne surtout des écrans noirs grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

32

Mais c'est vraiment splendide de réussir à dessiner la face cachée de la lune ! Bravo !!!

33

jsuis unpt it peu bourre, jte repond quans jme reveille @trioui#
avatar
HURRRR !

34

grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

35

zzzjour zzz

pour les FBO:

un framebuffer object peut avoir un certain nombre d'"attachments", qui correspondent aux rendertargets. ca peut etre des attachments de type color ou depth ou stencil...
ce que tu binde en attachment, c'est une zone memoire contenant un array de pixels, dans lesquels le rendu se fera.
les attachment, ca peut etre des textures normales, ou bien un renderbuffer, qui est juste un conteneur de pixels tout bidon...
(ptet que dans les post au dessus je parlais de renderbuffers, mais ca devait probablement plutot etre des attachments dont je parlais)

apres un coup de google jsuis tombe la dessus: http://www.songho.ca/opengl/gl_fbo.html a premiere vue ca a pas l'air de trop mal expliquer le merdier, et t'as les fonctions utiles avec oui
par contre, heu.. OpenGL ES? grin hmm okay pourquoi pas, tu vas ptet te faire un peu chier pour implementer tout ca de maniere efficace ouai grin
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 hum) 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 ?


ouai c'est les normales en viewspace. c'est juste plus pratique pour certains trucs.
ca pourrait etre les normales en worldspace, mais:
- normales en worldspace = plus chiant a compresser efficacement en minimisant les deformations / pertes de donnees, t'as pas beaucoup d'autre choix que de stocker une paire XYZ, alors qu'en viewspace, cf les posts d'avant, t'as pas mal de trucs faisables pour reduire ca a 2 composants... (et meme si c'est deux composants packes dans deux U8, la perte de qualite reste encore acceptable)
- lors de la creation du light buffer, quand tu reconstruis les positions des pixels, ils sont en viewspace. tu pourrais les reconstruire en worldspace sans forcement te taper une multiplication de matrice dans le shader, mais bon, globalement, le shader genere est plus simple si c'est en viewspace, c'est toujours bon a prendre ^^

aucun probleme pour le normal mapping.
juste pour rappel:

Tangent space -> Model space -> World space -> View space -> Clip space -> Screen space

tu vas typiquement construire ta matrice tangent-space avec les tangentes et normales de tes vertex en object space, et calculer la binormale/bitangente avec un cross-product des vecteurs tangent/normal, multiplie par un coeff de signe pour la bitangente que t'aura stocke quelquepart, typiquement dans le 'w' de la tangente par vertex.
a priori, dans le vertex shader, tu vas:

- transformer les tangentes d'object en view space en les multipliant par la modelview matrix passee au vertex shader
- transformer les normales idem
- passer les deux vecteurs transformes au pixel shader.

dans le pixel shader:
- renormaliser les normales/tangentes viewspace recuperees du vertex shader (l'interpolation des attributs de vertex vont denormaliser legerement les vecteurs le long du triangle, donc vaut mieux renormaliser)
- cross-product pour chopper la binormale, eventuellement renormalisation voire meme reorthogonalisation de tout le bordel.
- 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);

avatar
HURRRR !

36

bearbecue (./35) :
par contre, heu.. OpenGL ES? grin hmm okay pourquoi pas, tu vas ptet te faire un peu chier pour implementer tout ca de maniere efficace ouai grin

Je me suis rendu compte un peu trop tard que oui, apparemment grin (mais bon tant pis, ça m'amuse d'avoir un résultat qui tourne dans un browser)

Merci pour le lien smile
- 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);

Heu... OK, je vais sortir mon bloc-note et mon crayon 3D pour réécrire celle-là, parceque j'étais parti pour faire quelque chose de vachement plus tordu ; merci grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

37

ok ^^
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 smile
'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 oui

donc ca te fait la matrice:

|  tangent.x    tangent.y   tangent.z |
|   normal.x     normal.y    normal.z |
| bitangent.x bitangent.y bitangent.z |

(la notation, c'est le layout memoire GL et DX, pas la notation mathematique utilisee par GL pour representer les matrices (par contre il me semble que DX les note comme ca (ouai, GL c'est vachement logique, ils utilisent une notation donnee, mais en memoire c'est stocke dans l'autre sens tritop (bref))))

multipliee par le vecteur qui represente la normale en tangent-space, pour obtenir la tangente en viewspace oui
avatar
HURRRR !

38

Zeph (./36) :
je vais sortir mon bloc-note et mon crayon 3D
Wow ça doit être carrément pratique ça, tu l'as acheté où ? grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

39

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 smile
'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 oui

#révélation# : ok, je me prenais la tête à chercher comment faire cette transformation de repère, alors que non seulement j'avais déjà les trois vecteurs de base disponibles, mais aussi que c'est une opération encore plus naturelle que celle inverse que je faisais juste avant grin

je suis une quiche, merci encore hehe

(bon j'ai toujours pas eu le temps de retoucher à l'implémentation, mais dès qu'on me laisse un peu glandouiller au boulot... ^^)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

40

Mieux vaut tard que jamais : au bout d'un mois j'ai enfin pu profiter d'une petite accalmie au boulot pour m'y remettre. Il reste encore pas mal de trucs à faire, mais j'ai suivi tes explications, et ça marche, et c'est bien cool grin

Je sais pas si j'aurai le temps de commencer un petit jeu à partir de ça, mais je suis déjà content d'avoir (très grossièrement hehe) 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 ^^

Il y a juste un truc qui m'étonne, c'est que depuis que suis obligé de rendre dans des targets intermédiaires, j'ai l'impression d'avoir perdu un anti-aliasing ou je ne sais quoi d'autre qui était appliqué automatiquement à mon rendu.

Voilà mon rendu final :
ZuiU

Si je rends directement à l'écran sans framebuffer, par exemple l'albedo de ma scène, ça donne ça :
ldon

J'ai l'impression que le second a subit un traitement qui ne vient pas de moi, ça se voit pas mal sur le nez et la dérive du vaisseau (bon, faut zoomer, mes screens sont minuscules je sais embarrassed). 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).

[edit] bon en fait je viens de trouver, y'a bien un antialiasing automatique appliqué si je n'utilise aucun framebuffer... va falloir que j'apprenne à le réimplémenter moi-même si je veux le même rendu qu'avant.

Je sais pas si j'irai jusqu'aux ombres, ça a l'air d'être un sacré morceau et la tentation de faire un mini-jeu devient grande, mais en tout cas merci encore bear, ce topic est ma mine d'or depuis la fin de la semaine dernière grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

41

\o/
top
avatar
HURRRR !

42

C'est bô happy
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

43

oui
(content d'avoir pu aider ^^)

pis les ombres ca va c'est pas si complique... (par contre si tu veux une ombre pour chaque pointlight ca risque de bien galerer grin)
avatar
HURRRR !

44

a la limite si tu veux faire des essais avec des ombres, les spotlights c'est surement le plus simple oui

pis ca peut etre bien iteratif. tu peux commencer par une spotlight avec shadowmap de base, et rajouter des trucs jacky apres pour ameliorer la definition des ombres en gardant une resolution suffisamment basse pour etre acceptable oui
avatar
HURRRR !

45

Pour l'instant "shadowmap" c'est du chinois pour moi, mais j'irai voir ce que Google peut me raconter là-dessus, si c'est abordable smile

Oh tant que j'y suis, j'ai encore deux questions, l'une sur les lumières et l'autre sur les ombres (mais te fais pas chier à répondre un pavé, si c'est trop long j'essaierai de chercher tout seul ^^) :

- Pour calculer la couleur finale d'un pixel selon le modèle de Phong (du moins il me semble que c'est ça), on trouve tout plein de formules sur le net, avec certains coefficients présents ou non, mais en gros ça se résume toujours à :

pixelColor = lightAmbientColor + matDiffuseColor * lightDiffuseColor * diffusePower + matSpecColor * lightSpecColor * specPower

Il arrive d'ailleurs souvent que "matSpecColor" soit en fait résumé à un scalaire pour la raison que tu m'as déjà expliquée dans ce topic. En revanche, je n'ai jamais vu d'implémentation qui fasse dépendre la composante ambiante d'un paramètre du matériaux. Pourtant on pourrait imaginer avoir un "materialAmbientColor" qui influe sur la manière qu'a le matériau de recevoir la lumière ambiante. Est-ce que c'est parce que c'est comme ça que ça reflète le mieux la réalité (voire "ça serait une grosse connerie de modifier la lumière ambiante en fonction du matériau"), ou bien est-ce que c'est parce qu'en pratique ça ne sert à rien, ou bien il y a une autre raison ?

- Je n'ai absolument aucune foutue idée de comment on implémente des ombres, ni de ce qu'une shadowmap peut être, donc ma question n'a peut-être absolument aucun sens, mais j'ai cru comprendre que ce qui était évoqué dans ce topic servait à calculer les ombres des objets d'une scène. Si je veux faire une salle en forme de L, et qu'une seule branche de ce L possède une lampe de façon à ce que le coin intérieur de la jonction provoque une ombre dans la branche non éclairée (dessin tripo), 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 ?

Merci grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

46

1- bah, c'est un peu space la formule la grin
la lumiere ambiante, c'est comme une autre lumiere, sauf qu'elle s'applique partout. mais ca reste une lumiere.
un objet noir pur, meme avec un ambient de dingue, restera quand meme totalement noir (exception faite du speculaire)
la lumiere ambiante, comme n'importe quelle autre lumiere qui eclaire la surface, est reflechie par le materiau jusqu'a la camera, donc il faut prendre en compte la diffuse color du materiau.

ca donne:

pixelColor = matDiffuseColor * (lightDiffuseColor + lightAmbientColor) + matSpecColor * lightSpecColor;

typiquement l'ambient light n'a pas de composante speculaire a proprement parler, vu que la composante speculaire classique depend de la direction d'ou vient la lumiere. et la lumiere ambiante vient de "partout".
souvent ce qui se fait c'est d'utiliser de toutes petites cubemaps et de les indexer avec la normale de la surface, pour avoir un ambient pas uniforme (genre plutot bleute vers le haut, et plus sombre vers le bas, pour imiter la lumiere ambiante qui vient du ciel, ou verdatre en bas si ta scene se passe sur un terrain de golf.. enfin.. tu vois l'idee grin 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 cheeky)
et du coup tu peux aussi utiliser une cubemap pour le speculaire, qui stocke les spots de lumiere de la scene oui

dans quel cas tu peux integrer ca dans le calcul du spec, de la meme facon que la lumiere incidente:

matSpecColor * (ambientSpecColor + lightSpecColor)


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.

certains modeles d'eclairage utilisent autre chose qu'une specPower (qui s'utilise en tant qu'exposant dans le calcul du spec: x^specPower, _pas_ en le multipliant).
le truc chiant avec la specPower, c'est qu'un materiau parfaitement reflechissant est sense avoir une specPower infinie.
nous par exemple, au taff, dans notre renderer, on utilise un parametre "roughness", qui varie entre 0 et 1.
0 c'est un miroir, 1 c'est une surface parfaitement diffuse sans spec.

bon jvais ptet pas rentrer dans des details genre BRDF (le modele de phong est une approximation basique d'un BRDF), normalisation des approximations de BRDF pour garder un rendu coherent, etc...
... sauf si ca t'interesse grin

2- bah pour les ombres... (classe dessin #triclasse#) pour un exemple aussi simple (grin) 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 (cheeky) qui projette une ombre sur un des murs, le nombre d'options diminue pas mal grin
a un moment la grande mode c'etait les shadow volumes.. c'est ce qui est utilise dans doom3. perso j'ai jamais ete fan... ya trop de cas particuliers, c'est relou a implementer, ca donne des ombres super nettes (et donc moches cheeky), et... bref.. ca pue un peu du zgeg embarrassed
maintenant quasiment tout le monde utilise des shadowmaps (ou des variations).
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.

\o/

apres, pour les pointlights, vu qu'il te faudrait un fov de 360 degres, et que c'est un peu dur, t'as plusieurs options...
les plus populaires, c'est:
- ta shadowmap est une cubemap, tu fais 6 rendus avec un fov de 90 degres, un pour chaque face de la cubemap (tu comprends pourquoi je disais que ca risquait de ramer grin)
- dual-paraboloid maps: tu utilise deux shadowmaps classiques, mais tu change la projection. donc deux rendus au lieu de 6. probleme: les aretes des triangles deviennent courbes, et ca devient dependant de la precision du maillage de ta scene. si t'as de tres gros/longs triangles, ca marche tres tres mal. (il faut en plus faire gaffe aux jonctions entre les deux hemispheres, pour pas avoir de trous, justement a cause des triangles clippes qui ne suivent pas le cercle parfait de la jonction.. mais bon, ya quelques tricks pour contourner ca.. je te laisse googler si ca t'interesse grin)

la ca te donne des ombres de base, tu verra de l'aliasing du a la resolution de la shadowmap (des gros "pixels d'ombre" quoi grin)
apres, t'as genre 3 milliards d'algos pour eliminer ces effets d'escalier et adoucir les ombres, simuler des soft shadows (ombres plus nettes lorsque l'objet qui projette l'ombre est proche de la surface qui recoit l'ombre, et plus "floues" lorsqu'il est eloigne)
avatar
HURRRR !

47

je l'implémenterai pas, mais ma culture 3D sur les ombres vient de faire un bond grin

48

Ah ben bear il est spécialiste du côté obscur cheeky
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

49

bearbecue (./46) :
1- bah, c'est un peu space la formule la grin

Hum bon, c'est limite encore moins clair après les explications en fait, j'ai du mal à comprendre ce qui permet de combiner la composante diffuse et ambiante, mais de gérer la spéculaire à part dans ta formule (dans le sens où je vois pas trop à quoi ça correspond "en vrai"). Mais peut-être qu'une recherche sur "BRDF" m'éclairera (ohoh tripo).
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.

Hmm nan mes paramètres "power" c'est ceux calculés en fonction de la direction de la lumière et de la normale (et de l'angle de vue dans le cas de la lumière spéculaire), je connais pas leur nom habituel. Plus explicite :

pixelColor = lightAmbientColor + matDiffuseColor * lightDiffuseColor * dot (lightVec, normal) + matSpecColor * lightSpecColor * dot (reflect (lightVec, normal), eyeVec) // ou approximation à base de halfVec

(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 cheeky)
... sauf si ca t'interesse grin

Oui mais il me manque les prérequis, donc je vais faire un tour de wikipedia avant grin
2- bah pour les ombres... (classe dessin #triclasse#) pour un exemple aussi simple (grin) 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 (cheeky) qui projette une ombre sur un des murs, le nombre d'options diminue pas mal grin

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.
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.

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 ? :/

Bon ok, je regarderai le fonctionnement mais je sens que pour l'implémentation ça va attendre encore un peu grin

Merci encore oui
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

50

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.


nan c'est amha totalement inutile de te faire chier a faire des cas particuliers pour ca. ca va compliquer inutilement ton rendu...
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 ? :/


bah typiquement ce qui se fait c'est que t'as que quelques "grosses" lights qui castent des shadows, genre le soleil, quelques gros spots, et basta. si t'as une chiee de petites lights qui viennent en plus par dessus, tu vas les pouvoir les afficher sans ombres, ca changera pas grand chose...
mais, ouai, pour rendre la shadowmap, tu dois quand meme afficher tous les objets visibles dans la zone d'influence de la light, forcement...
apres, rendre juste une depthmap avec les color-writes desactives, c'est quand meme _vachement_ plus rapide qu'un rendu normal...

ah, ok pour ton parametre diffusePower. c'est ton ndotl

bon, donc (et en changeant un peu les noms, ca sera ptet plus clair:

	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 cheeky)


bah, parceque c'est une lumiere comme les autres trifus
vois la texture diffuse de ton materiau comme un coefficient d'absorbtion/diffusion de la lumiere incidente.
dans les zones de la texture qui sont noires, toute la lumiere qui arrive est absorbee.
dans les zones qui sont blanches, toute la lumiere qui arrive est re-diffusee.
c'est pareil pour la lumiere ambiante.

la dans ta formule, ta lumiere ambiante c'est plutot une valeur d'emission de la surface (genre une surface fluorescente qui emet de la lumiere, de la lave incandescente, etc...)
si tu met ta lumiere ambiante a 1, meme des objets tout noirs apparaitront blancs, comme si c'etait eux memes qui emettaient de la lumiere, alors que la lumiere ambiante, c'est pas du tout ca...

la avec ta formule de lumiere ambiante, tu fais en gros:
	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;

au lieu de:

	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;

avatar
HURRRR !

51

hmm ok, y'a un je ne sais quoi que j'arrive pas à intégrer dans cette asymétrie entre "ambiante + diffuse" d'un côté avec un coefficient commun, et "specular" de l'autre avec son coefficient spécifique, mais je vais finir par m'y résoudre grin

(bon par contre avec ce qui me tombe sur la gueule au boulot, je vais encore pas pouvoir y toucher avant un moment sad)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

52

nan mais ya aucune assymetrie hein grin

matEmissionColor +
matDiffuseColor * (ambientLight + Light0DiffuseTerm + Light1DiffuseTerm + ...) +
matSpecColor * (ambientSpec + Light0SpecularTerm + Light1SpecularTerm + ...);

c'est juste que ton "ambientSpec" est a 0, a moins que t'utilise une cubemap, ou que tu donne une composante directionnelle a ta lumiere ambiante.
mais vu que les lumieres ambiantes sont dans la plupart des implementations totalement diffuse, le terme speculaire est a 0, donc tu l'ignore, c'est tout...

mais dans tous les cas, t'as:
matDiffuseColor * sommeDesTermesDiffusDeToutesLesLights +
matSpecColor * sommeDesTermesSpeculairesDeToutesLesLights;

la lumiere ambiante est une light comme les autres, donc tu la somme au meme endroit, c'est juste que t'as pas de NdotL, vu qu'elle vient de "partout"...

bon, bref grin
avatar
HURRRR !

53

Hmm bon, ok, en fait mes noms de variable étaient à peu près tous mauvais et la formule biaisée tentait de leur retrouver une signification. Je viens de tout remettre à sa place et curieusement ça rend mieux trigic (l'aspect "sol trempé" est voulu, le choix de texture aurait pu être moins stupide mais on fait avec ce qu'on a embarrassed)

À un détail près, je ne sais pas quelle est l'unité choisie pour l'exposant qui s'appelle chez moi "gloss" dans la partie "pow(ReflectedLightVector dot EyeVector, gloss)" utilisée pour le terme spéculaire. J'utilise des modèles 3DS, j'y trouve des valeurs de ~10 et si je les laisse telles quelles ça me donne un truc bien trop sensible à la lumière spéculaire (i.e. complètement blanc dès qu'il y a une dizaine de lumières à proximité), il faut que je multiple par une grosse constante pour avoir un rendu qui semble correct, mais c'est du bon pifomètre grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

54

ha ouai sympa ^^
classe ton sol grin
t'as implemente du parallax mapping? ca a pas l'air d'etre de simples normalmaps
avatar
HURRRR !

55

yep, d'ailleurs j'ai vu qu'il y avait d'autres techniques qui donnaient de meilleurs effets avec des caméras rasantes, mais j'ai pas encore trop creusé ça non plus, j'en suis encore à l'émerveillement de l'effet du parallax mapping par rapport aux 3 lignes de code que ça demande grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

56

quand je regarde, j'ai l'impression que la dérive n'a pas le bon angle... ça vient de moi ?
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

57

vince> deformation du a la projection + normales du mesh qui doivent etre fusionnees -> eclairage "wrappe" autour de la derive, alors qu'il devrait y avoir des angles nets, jpense que c'est juste une illusion d'optique smile

Zeph> ouai, mais les techniques meilleures sont pour le coup vachement plus bourrines grin 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)
avatar
HURRRR !

58

bouh sad

bon ok, ça aussi ça sera pour plus tard (après les ombres probablement, pke les ombres ça me tente quand même bien d'essayer grin)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

59

tiens d'ailleurs si t'implemente les ombres y aura qques siouxeries a faire pour bien les faire fonctionner avec les shader de fake-displacement (que ce soit parallax mapping ou les autres de meilleure qualite)
sinon tu verra une ombre non deformee projetee sur la vraie surface plate, ca donne un effet bizarre grin

enfin ouai, implementer des ombres -> top
avatar
HURRRR !

60

Rah c'est vraiment terrible cette technique, je viens d'ajouter des particules à l'arrache pour voir ce que ça donne, et même en faisant de chaque particule une source de lumière ça passe love

Ahci

Par contre comme les particules sont transparentes, et pour éviter qu'elles pourrissent le gbuffer alors qu'elles ne sont pas affectées par les lumières, je les rends dans un buffer à part (en utilisant juste la même depth map) que je blend à la fin du rendu, c'est peut-être un peu lourd mais c'est la solution la plus simple qui me soit venue.

Bon, vu tes dernières vidéos, j'imagine qu'en ce qui concerne les particules il y a "quelques" astuces applicables mais ça risque d'être complètement hors de portée pour moi, donc je vais probablement en rester là pour le moment grin (et nettoyer mon code qui commence à être sacrément atroce...)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)