90

Disclaimer: je n'ai pas commencé à tenter le light pre-pass rendering, j'ai un bug foireux à corriger avant ^^

En deferred shading classique donc, pour la passe où j'applique les lumières une à une, j'étais initialement parti pour utiliser des sphères de même rayon que celui des lumières à appliquer. Sauf que pour permettre à un pixel d'être affecté par plusieurs lumières, il faut désactiver le depth test pour que les sphères se superposent, mais ça provoque un effet indésirable : quand on est à l'extérieur de la sphère l'affichage de la face avant et de la face arrière fait que chaque pixel est dessiné deux fois, donc la lumière est appliquée deux fois également, donc ça foire, donc c'est nul.

Du coup, j'utilise à la place un disque que j'oriente toujours face à la caméra, comme ça je suis sûr que les pixels sont dessinés une seule fois par lumière. Sauf que du coup, si je* dépasse la lumière (i.e. si je me place de façon à être entre l'objet éclairé et la lumière), alors ce disque est dessiné derrière moi, donc n'apparaît pas du tout à l'écran, donc la lumière n'est pas appliquée, donc c'est tout noir, donc c'est nul aussi.

Il y a plusieurs façons de résoudre le problème, mais aucune ne me semble "bonne" :

- Je pourrais redessiner tout l'écran pour chaque lampe, comme ça au moins il n'y a aucun problème quelles que soient leurs positions tritop
- Je pourrais, quand une lampe est derrière moi* mais que ma distance à elle est quand même inférieure à son rayon, redessiner tout l'écran
- Je pourrais, quand une lampe est derrière moi* mais que ma distance à elle est quand même inférieure à son rayon, ou ramener mon disque juste devant moi* (même si ça risque de ne m'économiser qu'une poignée de pixels par rapport à la méthode précédente)
- Je pourrais réactiver le depth test et remettre le depth buffer à zéro avant l'affichage de chaque lumière
- Je pourrais utiliser le stencil buffer pour y coller l'index de la lumière en cours d'affichage, et éviter de dessiner deux fois un même pixel pour une même lampe

Mais bof quand même, il n'y a pas une solution plus... mieux ? grin

*je/moi = la caméra
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

91

ha, ouai tiens.. je savais bien qu'il fallait que je reponde a un truc trioui
jte reponds ce soir grin
avatar
HURRRR !

92

Ca se voit cheekygrin

93

C'était o-bli-gé trigic
avatar

94

d'un autre coté, momotte n'étant pas sur le même créneau horaire que nous...
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

95

rha fuck.. embarrassed
avatar
HURRRR !

96

Rah merde, je viens de tenter de passer en light pre-pass, et ça fait apparaître un nouveau problème. En deferred shading, les zones saturées de lumières finissaient par devenir très claires, voire blanches, ce qui me semble plutôt normal. On voit par exemple ici le sol devenir blanc (alors que sa couleur diffuse est beige) parcequ'il est éclairé par une 50aine de lampes :

Ypgq

Pour la même scène en light prepass, le light buffer qui est supposé contenir la somme de toutes les lampes se retrouve à perdre beaucoup d'information, à cause du clamp automatique de toutes les valeurs entre 0 et 1. Du coup, même si 50 lampes éclairent une même zone, l'intensité lumineuse enregistrée vaut au maximum 1, c'est à dire que ça correspond exactement à cette représentation RGB :

v17L

Le résultat c'est que dans le rendu final, la couleur diffuse du matériau est au maximum multipliée par 1, jamais plus. Du coup le centre de ma scène, au lieu d'être tout blanc comme avant, fait juste apparaître la couleur diffuse des objets :

6jW0

On voit bien les bordures colorées qui correspondent à des zones éclairées par peu de lampes, et qui n'atteignent donc pas 1, mais dès qu'on s'approche trop du centre ça devient uniformément éclairé par une lumière (1, 1, 1). Je pourrais tricher pour stocker des intensités supérieures à 1 dans le light buffer, avec un coefficient arbitraire ou une échelle logarithmique, mais bof... :/

Ou alors plus simplement, j'ai juste merdé qqpart ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

97

bon, ce soir, je te reponds grin
(on vient de changer de bureaux, j'ai a peine re-lenet depuis 3/4 jours trioui#branches#)
avatar
HURRRR !

98

ouai, c'est normal, c'est parceque t'as un light-buffer en BGRA8, pas en floating-point.
bon entre chaque post ici jme souviens plus de quels formats t'as de dispo, mais si t'as que du 8-bits, c'est effectivement un probleme grin

en option il y a:

1- considerer le RGBA comme du RGBE (R, G, B, exposant), tu choisis un exposant qui se remappe entre deux valeurs arbitraires (genre tu fais real_scale = 1 + light_buffer.a * 100)
en gros:
quand t'ecris dans le light-buffer:

soit:
const float kScaleCoeff = 100.0f;
float scale = min(1.0f, length(irradiance.xyz));
outColor = float4(irradiance.xyz / scale, (scale - 1.0f) / kScaleCoeff);


soit:
const float kScaleCoeff = 100.0f;
float scale = min(1.0f, max(irradiance.x, max(irradiance.y, irradiance.z)));
outColor = float4(irradiance.xyz / scale, (scale - 1.0f) / kScaleCoeff);

(cette 2eme option utilisera mieux les bits dispos mais sera surement moins efficace, elle force un cassage de la vectorisation avec le max horizontal sur les 3 scalaires x, y, z, alors que le lenght() d'au dessus est cable en hardware et devrait etre plus rapide, meme si il necessite le calcul d'un dot product + racine carree)

quand tu lis le light-buffer:
float4 irradianceRGBE = light_buffer.sample(pixel_uv);
float3 irradiance = irradianceRGBE.xyz * (irradianceRGBE.w * 100.0f + 1.0f);


probleme: tu perds la possibilite de stocker ton spec dans l'alpha de ton light-buffer.

2- changer d'encodage. ne pas utiliser le RGB, mais le YUV.
ca a l'avantage de preserver la couleur. ca saturera l'intensite (Y) a 1, mais vu que U et V sont entre 0 et 1 par definition dans ce color-space, la chromaticite sera conservee.
par contre c'est ptet plus relou a blender. j'ai jamais teste ca, et j'ai pas trop d'image mentale de comment le YUV peut se blend, donc plutot que de te dire une connerie, va plutot faire 2/3 recherches google sur light-prepass et YUV grin j'ai vu passer quelques posts de gars qui experimentaient cette methode, ya ptet des trucs interessants a en tirer..

tiens, une idee qui me vient comme ca un peu a l'arrache en ecrivant:
si tu veux faire deux passes pour stocker les vraies couleurs de ton spec, tu peux faire une des passes en demi-resolution pour gagner en fill rate.
en gros, utiliser un principe comme le jpeg.
t'as deux rendertargets:

1- full-resol : irradiance.Y(0), irradiance.Y(1), specular.Y(0), specular.Y(1)
2- half-resol : irradiance.U, irradiance.V, specular.U, specular.V

dans la 1, tu peux utiliser 16 bits pour stocker les deux Y de l'irradiance et du spec, et avoir un range de valeurs plus important

bon apres vu que ca te fait quand meme deux passes, meme avec 4* moins de pixels sur la 2eme passe, jsais pas si ca vaut le coup par rapport au deffered classique.
mais ca peut etre un truc interessant a tester smile
avatar
HURRRR !

99

bearbecue (./98) :
j'ai pas trop d'image mentale de comment le YUV peut se blend
Le passage du RGB au YUV (et vice-versa) est une opération linéaire, plus exactement un simple produit matriciel, donc si je dis pas de conneries* tu dois pouvoir faire le blending de la même façon qu'en RGB.

* ce qui n'est pas sûr vu l'heure hehe
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

100

ah ben cool, donc blend additif ca passe? #trihum#

ca m'etonne un peu.. si c'etait le cas le U et le V pourraient largement sortir du range [0,1] trifus
avatar
HURRRR !

101

Zeph (./90) :
Disclaimer: je n'ai pas commencé à tenter le light pre-pass rendering, j'ai un bug foireux à corriger avant ^^

En deferred shading classique donc, pour la passe où j'applique les lumières une à une, j'étais initialement parti pour utiliser des sphères de même rayon que celui des lumières à appliquer. Sauf que pour permettre à un pixel d'être affecté par plusieurs lumières, il faut désactiver le depth test pour que les sphères se superposent, mais ça provoque un effet indésirable : quand on est à l'extérieur de la sphère l'affichage de la face avant et de la face arrière fait que chaque pixel est dessiné deux fois, donc la lumière est appliquée deux fois également, donc ça foire, donc c'est nul.

Du coup, j'utilise à la place un disque que j'oriente toujours face à la caméra, comme ça je suis sûr que les pixels sont dessinés une seule fois par lumière. Sauf que du coup, si je* dépasse la lumière (i.e. si je me place de façon à être entre l'objet éclairé et la lumière), alors ce disque est dessiné derrière moi, donc n'apparaît pas du tout à l'écran, donc la lumière n'est pas appliquée, donc c'est tout noir, donc c'est nul aussi.

Il y a plusieurs façons de résoudre le problème, mais aucune ne me semble "bonne" :

- Je pourrais redessiner tout l'écran pour chaque lampe, comme ça au moins il n'y a aucun problème quelles que soient leurs positions tritop
- Je pourrais, quand une lampe est derrière moi* mais que ma distance à elle est quand même inférieure à son rayon, redessiner tout l'écran
- Je pourrais, quand une lampe est derrière moi* mais que ma distance à elle est quand même inférieure à son rayon, ou ramener mon disque juste devant moi* (même si ça risque de ne m'économiser qu'une poignée de pixels par rapport à la méthode précédente)
- Je pourrais réactiver le depth test et remettre le depth buffer à zéro avant l'affichage de chaque lumière
- Je pourrais utiliser le stencil buffer pour y coller l'index de la lumière en cours d'affichage, et éviter de dessiner deux fois un même pixel pour une même lampe

Mais bof quand même, il n'y a pas une solution plus... mieux ? grin

*je/moi = la caméra


bon, reponse rapide: tu peux utiliser le stencil-buffer.

- pour chaque lumiere
{
1- clear du stencil (valeur = 0) (degeulasse point de vue perfs, mais c'est l'implementation naive)
avec le depth-test ACTIF:
{
2- tu affiche les faces avant du volume de la lumiere, avec le stencil set en SET (valeur = 1)
3- tu affiche les faces arrieres du volume de la lumiere (t'inverse le culling quoi), avec le stencil set en DECREMENT (-1), ou en SET (valeur = 0)
}
avec le depth-test DESACTIVE, et le test de stencil a EQUAL (valeur = 1)
{
4- tu affiche un fullscreen quad (implementation naive aussi, mais probablement quand meme plus performante que la version qui affiche tout le volume) et tu calcule le lighting dedans.
}
}

en gros, le resultat, c'est que seul les pixels qui intersectent le _volume_ de ta light passeront dans ton shader de lighting et seront calcules. (les autres sont aussi "calcules" mais se font rejeter dans une etape precedente du pipeline, et le plus couteux la, c'est le pixel shader et les stages suivants (notamment le blending))

1- le stencil buffer contient la valeur 0 pour chaque pixel
2- pour toute la surface avant du volume de la light qui n'est pas derriere de la geometrie, le stencil passe a 1
3- c'est la que c'est tricky. ce sont les faces arrieres. 3 cas de figure:
3.1- si il y a de la geometrie entre la face avant et la face arriere, le depth-test va faire que le pixel ne sera pas processe. le stencil va rester a 1.
3.2- si il n'y a pas de geometrie, et que la face arriere est visible, ca veut dire que la light n'eclaire rien le long de ce pixel. si il y a de la geometrie, elle est derriere le volume de la light, et pas affectee. le pixel est processe, le stencil est decremente, et repasse a 0 (ou est set direct a 0 si t'as choisi le mode SET au lieu de DECREMENT, peu importe)
3.3- si le depth test des faces avant avait fail (une geometrie est entre le volume de la light et la camera), le stencil est deja a 0, et le depth test va fail de nouveau, le pixel ne sera pas process, et restera a 0.

a ce moment la, quand l'etape 3 est finie, dans ton stencil buffer, tous les pixels dont la valeur de stencil == 1 sont a l'interieur du volume de ta light smile

4- avec le mode de stencil test a EQUAL et la valeur a 1, le stencil buffer va etre utilise comme un masque binaire. tous les pixels dont le stencil != 1 seront rejetes avant l'execution du pixel shader. vu que t'affiche un fullscreen quad, t'as pas d'overdraw. vu que t'utilise le stencil, tu paye seulement le prix des pixels vraiment lightes. (ca peut aussi etre un rectangle en screenspace qui englobe le volume de la light, evidemment)


un truc chiant c'est le clear complet de stencil avant de process chaque light. c'est tres mauvais. surtout quand tu clear pas la depth avec, vu que le stencil et la depth sont packes dans les memes 32 bits.

mais t'as un moyen simple de remedier a ca:

le stencil buffer, c'est une valeur aribitraire 8 bits.
-> tu peux le clear toutes les 254 lights \o/

a la premiere light, tu set les valeurs de set/test a '1'. pour la 2eme, tu les set a '2', la 3eme, a '3', et quand t'arrive a 255, tu clear le stencil oui

ceci dit t'as 3 draw-calls par light au lieu d'un seul. (4 draw calls si tu combine ca avec le double rendu YUV du post d'avant)
mais c'est pas forcement tres genant, normalement ca reste quand meme avantageux par rapport a tout afficher comme un bourrin... les gains dependent de ton shader de lighting.. bref.. a tester ^^ (si t'as le temps cheeky)

sinon, plus simple:

- tu flip le mode de culling, et t'affiche les faces arrieres de la sphere de ta light, sans depth-test. trigni (merci d'avoir lu tout le pave d'au dessus grin (ou pas cheeky))

avatar
HURRRR !

102

0^2/bob> ah ben vala : http://softpixel.com/~cwright/programming/colorspace/yuv/

l'alpha blending ya pas de pbl, mais l'additive blending (comme c'est le cas ici) est effectivement beaucoup plus relou grin

Adding colors in YUV is a bit more tricky. The Y and UV components need to be treated differently, since they represent different things.

Adding the Y channels is easy; You just add them.
Y3 = Y1 + Y2.

It's probably a good idea to saturate the Y value to 255 or 1.0.

Adding the U or V channels is more involved. You have to average the two input values.
U3 = (U1 + U2)/2, V3 = (V1 + V2)/2.
U and V should saturate as well. Otherwise, several additions can cause unusual color distortions when combined with high Y values.


donc les UV doivent etre alpha-blendes avec un alpha a 0.5, et les Y doivent etre blendes en additif.
ceci dit, avec l'idee des deux rendertargets qui stockent les UV et les Y separement, c'est surement faisable oui
avatar
HURRRR !

103

bearbecue (./100) :
ah ben cool, donc blend additif ca passe? trihum.img

ca m'etonne un peu.. si c'etait le cas le U et le V pourraient largement sortir du range [0,1] trifus.gif
Ben en fait la condition sur U et V n'est vraie que tant que tes 3 valeurs RGB sont elles aussi comprises entre 0 et 1... sinon U et V peuvent dépasser cette plage effectivement.

En fait le YUV est un espace de couleur qui sépare la luminosité de la teinte/saturation, mais la saturation est représentée par le module du vecteur (U,V) et la teinte par son angle*, donc si tu satures les composantes telles quelles tu vas avoir les mêmes mauvaises surprises qu'en RGB.

Le truc auquel tu dois penser, c'est le HSL, où effectivement les composante H et S sont bornées à [0,1] quoi qu'il arrive, même si L est est très élevée. Mais le souci c'est que c'est pas linéaire, et faut des calculs à la con pour convertir de et vers le RGB : http://en.wikipedia.org/wiki/HSL_and_HSV.

(* toujours si je dis pas de conneries)

edit : cross, je regarde ton lien
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

104

Ouais ben je verrai ça demain, là dodo tongue
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

105

bn grin
avatar
HURRRR !

106

(Je suis curieux de savoir ce que Zeph va pouvoir sortir de tout ça grin)

107

bear -> pour info, t'as fait des études dans le domaien précis de la 3D, t'as appris sur le tas, t'as appris par passion ? Ca a l'air quand même super complexe quand on regarde sans rien y connaitre ^^

108

bearbecue > bon je me disais bien qu'il y avait un truc louche tongue :

Imaginons que tu fasse un blend additif d'un truc qui n'émet pas de lumière, donc Y=0, U=0 et V=0. Normalement ça ne doit avoir aucun effet. Mais avec la méthode du gars, Y ne change pas, mais U et V sont divisés par deux, donc la couleur cible est désaturée de 50% à chaque fois triso

r_cible += r_source; g_cible += g_source; b_cible += b_source; m = max(r_cible, g_cible, b_cible); if (m > 1) { r_cible /= m; g_cible /= m; b_cible /= m; }En fait, la méthode "propre" que j'imagine pour faire du blend additif avec saturation en RGB, c'est (toutes les composantes sont en flottant dans l'intervalle [0,1]) : comme ça tu préserves la proportionnalité des composantes RGB (donc la teinte et la saturation) sans sortir du cube [0,1]3. Et pareil pour le YUV.
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

109

ah ouai effectivement pour le blend avec le noir grin

sinon pour ton pseudocode, en fait c'est equivalent a ce que j'ai marque au dessus pour la conversion en RGBE oui

(Folco> nan sur le tas. ho bah oui c'est un peu complexe, surtout si tu vas fouiller en details ^^)
avatar
HURRRR !

110

bearbecue (./98) :
ouai, c'est normal, c'est parceque t'as un light-buffer en BGRA8, pas en floating-point.
bon entre chaque post ici jme souviens plus de quels formats t'as de dispo, mais si t'as que du 8-bits, c'est effectivement un probleme grin

Oui, le problème est bien que le seul format disponible en webgl est RGBA8 sorry

Par contre pour la solution "considérer le RGBA comme du RGBE", je pense avoir mal compris un truc. En gardant ta formule, "scale - 1.0" est toujours inférieur à zéro, donc égal à zéro à cause du clamp, ça ne donnera rien. Même si je remplace par "scale", je ne comprends pas comment se passe le blend additif ? Je ne peux pas additionner en même temps les valeurs scalées et l'exposant, le résultat n'aura pas de sens (color1 * scale1 + color2 * scale2 != (color1 + color2) * (scale1 + scale2)), ou alors il y a un mode de blending qui correspond à l'opération à effectuer ? En attendant j'étais parti sur un exposant fixe, mais c'est tout pourri (précision moisie même quand il n'y a qu'une lampe donc pas besoin de scaler, et je suis obligé de fixer à l'avance le max de lampes qui peuvent se recouper sans que la couleur finale déconne)

[edit] bon, en attendant je vais essayer ça : au lieu de stocker "lightColor" dans le light buffer, je vais stocker X = 2 ^ -lightColor, et lire -log2(X) au moment du rendu. L'avantage est que ça se combine facilement, à condition de pouvoir faire un blending multiplicatif au lieu du blending additif. Je n'ai pas essayé, mais avec un glBlendFunc (GL_ZERO, GL_SRC_COLOR) ça devrait fonctionner ? Résultat demain si j'ai le temps de tester smile
bearbecue (./101) :
bon, reponse rapide: tu peux utiliser le stencil-buffer.
[...]sinon, plus simple: tu flip le mode de culling, et t'affiche les faces arrieres de la sphere de ta light, sans depth-test.

(oui j'ai lu les deux grin)

Si j'ai bien compris, avec la première solution je ne déroule les étapes du pipeline jusqu'au bout que pour les pixels réellement éclairés, par contre ça coute 3 drawcalls dont un fullquad qui se fait presque totalement éliminer au stencil test, alors qu'avec la seconde je calcule l'éclairage pour quelques pixels de trop, mais en un seul drawcall ? Si c'est bien ça, la première arrive vraiment à être intéressante ? (je n'ai pas d'outil précis pour bencher, mais je regarderai les FPS pour les deux, ça fera toujours une première approximation)

J'étais parti pour une solution avec le stencil buffer dans ce genre, mais finalement ça aurait donné le même résultat que ta seconde méthode tout en étant probablement beaucoup plus lent :

depth mask false
depth test activé

pour chaque lumière i (avec 0 <= i < N)
{
    v = i % 255

    si v == 0
        clear du stencil à 0

    stencil test = NOTEQUAL (v + 1)
    stencil op = SET (v + 1)

    rendu de la sphère de la lumière
}


Dès que j'arrive à comprendre comment faire en sorte que le stencil buffer s'initialise correctement (pour l'instant les écritures dessus n'ont aucun effet), je compare tout ça.

[edit] bon j'ai trouvé pourquoi mon stencil buffer ne fonctionnait pas, du coup j'ai pu tester la première méthode de ton post ./101 mais en fait elle a le même problème que celui que j'expliquais en ./90 : si on est à l'intérieur de la sphère, la front face ne s'affiche jamais, donc le stencil reste à zéro et la lumière n'a pas d'effet alors qu'elle devrait. Attention illustration de la mort : dans cette vue de dessus, le stencil va rester à zéro et "geometry" ne sera pas éclairé, alors qu'il est bien en partie dans la sphère. Il doit me manquer encore un truc doom (en attendant la méthode où on affiche que les backface fonctionne parfaitement grin)

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

111

Zerosquare (./108) :
Imaginons que tu fasse un blend additif d'un truc qui n'émet pas de lumière, donc Y=0, U=0 et V=0. Normalement ça ne doit avoir aucun effet. Mais avec la méthode du gars, Y ne change pas, mais U et V sont divisés par deux, donc la couleur cible est désaturée de 50% à chaque fois triso
On doit plutôt faire comme ceci :
[C'est faux]
avatar

112

Pourquoi ? Comme je le disais, la transformation RGB -> YUV est linéaire et sa réciproque aussi, donc pour les modes linéaires de blending ça ne change rien par rapport au RGB (c'est une propriété de la linéarité).

En fait je crois que j'ai compris ce qui vous pose problème à toi et bear : le YUV ne fonctionne pas comme le HSL, les composantes U et V ne dépendent pas seulement de la saturation et de la teinte, mais aussi de la luminosité. Autrement dit, si on veut par exemple une couleur identique mais deux fois moins lumineuse, il faut diviser Y par 2, mais aussi U et V (contrairement au HSL) ; si on ne change que Y, la couleur obtenue n'est plus la même, et peut même être en dehors du cube RGB.
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

113

En effet, tu as raison. J'avais oublié que c'est en TSL que j'ai travaillé cheeky
avatar

114

Bon, en attendant de comprendre la solution de bear (./98), celle que je décrivais dans le 1er edit du ./110 a l'air de marcher impec \o/

J'ai donc un lightbuffer inversé par rapport à avant, qui tend vers le noir dans les zones éclairées par beaucoup de lumières :

30J5

Et dans le rendu final, je peux à nouveau récupérer une intensité lumineuse > 1 (sachant que la précision va diminuer à mesure que les lampes vont se combiner, ça tombe bien, c'est justement dans ce cas de figure que les erreurs sont moins gênantes, puisque de toutes façons ça sature) :

NCPW

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

115

116

J'ai pas beaucoup de mérite, comme d'hab 95% du code est simplement une transcription de ce que bear a expliqué dans ce topic grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

117

Chapeau quand même pour avoir compris ce que disait bear cheeky (même s'il est très pédagogue quand il aborde ce domaine, il y a des choses qui restent un poiiiiil compliquées à appréhender quand on n'a pas certaines compétences initiales, en particulier en maths et en physique cheeky)
avatar

118

119

c'est clair que tout le monde n'y serait pas parvenu...
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

120

superbe bob ! smile
tu vois j'aurais meme pas essaye cette methode avec le blend multiplicatif et exp(-irradiance) / -log(irradiance) en partant d'un a-priori que la precision de lighting serait a chier, mais apparemment ca a l'air de passer vraiment bien...
chapeau smile

pour les lights/stencil> heu ouai t'es oblige d'afficher un fullscreen quad quand t'es a l'interieur de la sphere en fait triso
mais ca devrait pas etre genant... ta sphere est discretisee avec un mesh dont les vertex sont a priori a la surface de la sphere, donc t'aura jamais de faux negatif "je ne suis pas a l'interieur de la sphere" alors qu'en fait si, ce qui aurait pour consequence de foirer le lighting dans ces cas specifiques. donc ca passe sans glitch smile
avatar
HURRRR !