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

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

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

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 )

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 (en attendant la méthode où on affiche que les backface fonctionne parfaitement )

Encore merci