[http://sourceforge.net/p/ufoai/bugs/2946 Item 2946] imported from sourceforge.net tracker on 2013-01-28 19:54:51

Models seem to use some advanced lighting already, but the problem is that it is permanent & does not fade out after the light is gone (for example light from the weapon-fx)...
See attached screenshot.
===== Comments Ported from Sourceforge =====

====== mcr2010 (2011-07-06 16:31:38) ======

Model lighting permanent, light gone, lighting does not fade out
====== tlh2000 (2011-07-06 16:34:03) ======

this is not le_t lighting_t but localModel_t's
====== tlh2000 (2011-07-06 16:43:47) ======

might be related to R_AddSustainedLights
====== tlh2000 (2011-07-08 20:12:29) ======

it does not yet fix the issue - but this should fix some state leaks, too - must still be checked
====== tlh2000 (2011-07-08 20:13:03) ======

i'm away for one week - so if you want/could have a look at this issue.... please do
====== tlh2000 (2011-07-19 20:02:44) ======

maybe the problem is that in r_light.c:R_EnableLights and r_state.c::R_EnableDynamicLights not every light attenuation value is set back to zero.

the cook-torrance shader (function LightContribution) will only ignore the light, if the attenuation value is zero - and this can only be ensured by setting all of the attenuation values back to zero if we disable the light.
====== tlh2000 (2011-07-19 20:04:19) ======

i also wonder we are are calling glEnable(GL_LIGHTING); and glDisable(GL_LIGHTING); in R_EnableDynamicLights

this should not be needed, because we are only using the ffp lighting values in the shader - or am i wrong? is the GL_LIGHTING needed to get lighting in our shaders via gl_LightSourceParameters?
====== tlh2000 (2011-07-19 20:07:02) ======

this is not helping? is there maybe anything else missing?

diff --git a/src/client/renderer/r_state.c b/src/client/renderer/r_state.c
index 3b6941f..94e490b 100644
--- a/src/client/renderer/r_state.c
+++ b/src/client/renderer/r_state.c
@@ -360,6 +360,8 @@ void R_EnableDynamicLights (const entity_t *ent, qboolean en
glDisable(GL_LIGHTING);
for (i = 0; i < maxLights; i++) {
glLightf(GL_LIGHT0 + i, GL_CONSTANT_ATTENUATION, 0.0);
+ glLightf(GL_LIGHT0 + i, GL_LINEAR_ATTENUATION, 0.0);
+ glLightf(GL_LIGHT0 + i, GL_QUADRATIC_ATTENUATION, 0.0);
glDisable(GL_LIGHT0 + i);
}

@@ -396,10 +398,10 @@ void R_EnableDynamicLights (const entity_t *ent, qboolean

/* if there aren&#039;t enough active lights, turn off the rest */
while (i < maxLights) {
- glDisable(GL_LIGHT0 + i);
glLightf(GL_LIGHT0 + i, GL_CONSTANT_ATTENUATION, 0.0);
glLightf(GL_LIGHT0 + i, GL_LINEAR_ATTENUATION, 0.0);
glLightf(GL_LIGHT0 + i, GL_QUADRATIC_ATTENUATION, 0.0);
+ glDisable(GL_LIGHT0 + i);
i++;
}
}

====== tlh2000 (2011-09-18 14:34:15) ======

what&#039;s the state of this bug? Is this maybe already fixed due to the latest lighting system changes/fixes?
====== alextishin (2011-09-18 21:02:53) ======

Not fixed yet, but WIP. Probably will roll out a hacked version of shaders to work around that bug this week (if that idea of hack will work). Then will do a proper fix as the the part of lighting system cleanup.

PS: Somehow missed your comments from July, so answering them now: first, shuffilng calls and being more tedious with setting up GL lights doesn&#039;t help, at least on my WinXP/ATI configuration; on the other hand we might need to use GL lights for FFP renderer, so configuring them properly should be good. Second: formally, GL spec says that enabling/disabling GL_LIGHTING should have no effect when shaders are enabled, but drivers could be quirky, so I think it&#039;s best to enable lighting, just to stay on the safe side.
====== mcr2010 (2011-10-02 07:41:50) ======

Thanx 4 fixing this nasty one ;)

TOP JOB, Sandro !
====== mcr2010 (2011-10-19 10:19:59) ======

Models are still rendered much too bright, attached a screenshot (Linux) here:
https://sourceforge.net/tracker/?func=detail&aid=3310534&group_id=157793&atid=805242
====== alextishin (2011-10-26 23:53:20) ======

Overbright models should be fixed by 5b42ecf2044011c53f67352201b160e1091eff9e