# GLSL Attenuation values

This topic is 2678 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys,

I'm getting really frustrated with my fragment shader... every time I try to access 'gl_LightSource.constantAttenuation' or linear or quadratic they are alway zero. In the fixed pipeline, I'm sending a value of 1.0 (I've tried with each separately and all at once) with glLightf(GL_LIGHTi, GL_CONSTANT_ATTENUATION, 1.0f), I've also tried with glLightfv. I get no errors from the shader. This also seems to be happening to spotCutoff and spotExponent as well; however, all the values for light positions and colours are working fine.

If I put the numbers in manually in the shader, it works perfectly so I know it's not the shader.

Any clues as to what I'm doing wrong?

 glLightfv(GL_LIGHT0 + index + 1, GL_POSITION, pos); glLightfv(GL_LIGHT0 + index + 1, GL_AMBIENT, amb); glLightfv(GL_LIGHT0 + index + 1, GL_DIFFUSE, diff); glLightfv(GL_LIGHT0 + index + 1, GL_SPECULAR, spec); glLightf(GL_LIGHT0 + index + 1, GL_CONSTANT_ATTENUATION, l->atn_const); glLightf(GL_LIGHT0 + index + 1, GL_LINEAR_ATTENUATION, l->atn_linear); glLightf(GL_LIGHT0 + index + 1, GL_QUADRATIC_ATTENUATION, l->atn_quad); glLightf(GL_LIGHT0 + index + 1, GL_SPOT_CUTOFF, 0.0f);//disable this as a spotlight 

##### Share on other sites
I don't have an answer to your question, but can I ask why you want to use glLightf when you're using shaders? These functions are all deprecated now anyway, and you could just as easily send these values as uniform constants, and worry less about the black magic going on behind the glLight equations.

Also, why add 1 to your index? This means using index = 0 will put your light in LightSource[1], which seems a little confusing.

##### Share on other sites

I don't have an answer to your question, but can I ask why you want to use glLightf when you're using shaders? These functions are all deprecated now anyway, and you could just as easily send these values as uniform constants, and worry less about the black magic going on behind the glLight equations.

Also, why add 1 to your index? This means using index = 0 will put your light in LightSource[1], which seems a little confusing.

I was sending a uniform matrix that contained the positions and colours but my shader halted, so I switched back to getting the data from the fixed pipeline (turned out the issue was unrelated and I've just been using the code as it was since then). Also, my GL_LIGHT0 is always my 'environment' light, it's simply a directional light, that's why the other lights all start at index 1.

Anyway.. I found that opengl was throwing an error code at me and I never caught it. Turns out my glGetUniformLocation call is always returning -1 and thus killing my fixed-pipeline commands. I can't figure out why it's returning -1 though, because the program I'm passing it is valid and so is the name (AFAIK).

Lighting.cpp
int shaderNumLights = glGetUniformLocation(shaderID, "numLights"); //returns -1 every time

lighting.frag
uniform int numLights; //always 0

WTF!

##### Share on other sites
If you don't actually use numLights in the shader for some calculation that directly influences the output, it will be optimized out by the compiler, thus you can't find it with glGetUniformLocation.

##### Share on other sites

If you don't actually use numLights in the shader for some calculation that directly influences the output, it will be optimized out by the compiler, thus you can't find it with glGetUniformLocation.

Is there a way I can tell the compiler not to optimize that specific uniform? I use it as a way to break out of the loop if it tries to render too many lights. I have another shader that works the same way and I have no issues like this with it.

##### Share on other sites
If you're using it in a loop it shouldn't be optimized away, that would be a pretty serious driver bug. It would only be removed if it absolutely had no effect on the program at all.

Not sure what's wrong in your case.

##### Share on other sites

If you're using it in a loop it shouldn't be optimized away, that would be a pretty serious driver bug. It would only be removed if it absolutely had no effect on the program at all.

Not sure what's wrong in your case.

I had trouble with the loop earlier so I actually had this code

lighting.frag
 for(int i = 0 i < 10; ++i) { if(i > numLights) break; //... 

I've changed if back now.. however my other uniform, which specifies what type of light the shader should calculate for gets optimized out when I add in the attenuation factors from the fixed pipeline and it renders no lights (which is why I thought I was getting zeros). This uniform is simply an int unsed in an if statement.. I'm not sure why it thinks it can optimize it out because if it does, it renders nothing but black..

lighting.frag
 uniform int lightType[10]; //... if(lightType == 0) { //render env_light } else if(lightType == 1) { //render point light } else { //render spot light } 
Thanks for all your help, at least I know what's going on now

Update:
I got rid of the lightType varaible in my shader and simplified it to about 1/3 of what it was. I also ditched the fixed-pipeline functions and I'm using uniforms to import the lighting information. Runs faster and attenuation is working! Now I just have to figure out why my spotlight casts dark spots

• 18
• 11
• 16
• 9
• 49
• ### Forum Statistics

• Total Topics
631395
• Total Posts
2999780
×