Hello,

I'm currently implementing a shader for doing some Directional Lights. I'm following the tutorial at Lighthouse 3d (http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/directional-lights-per-pixel/)

The issue I'm having is in the following few lines:

vec3 h  = normalize(l_dir + e); 
float intSpec  = max(dot(h, n), 0.0);
float specularPower = pow(intSpec, shininess);

If I leave the "float specularPower" line in - then the shader no longer 'works'.... I say 'works' in quotations, because I get no output or errors from the Shader Log, however, now the uniform locations for my all return -1 and I can't set my texture locations, etc.

If I remove it, the rest of the shader works as expected (but producing incorrect results as a result of missing the Specular Power).

What's even more curious, is that if I have the nVidia Nsight Debugger attached, then I get output on screen and it appears to 'work', but if I just use VS2012 in Debug mode I get nothing displayed on screen, and the following error message:

First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

You only mentioned the shader log. Did you also check the linker output (glGetProgramInfoLog) and glGetError?

If no errors occurred, glGetUniformLocation returning -1 is usually because your shader let the variable be optimized out of existence. This is often caused by a simple typo or forgetting to actually output the results or some similar error, so it's hard to guess without seeing code.

If you're using uniform blocks like the tutorial you linked, you might try using non-block uniforms while debugging this so each component is fully independent and generating its own errors from its own code.

I haven't checked glGetProgramInfoLog() - I'll do that this evening. glGetError() returns no errors.

With regards to the -1, I know that typically means the value has been optimised out, but since I'm not even using the value return from pow() in my test code, I don't see how it could be affecting any of the other uniforms which work normally with that line commented out.

I'm not using uniform blocks, just standard glUniform*() functions.

I don't have access to the shader code at the moment, I'll try and get a copy onto Pastebin this evening and post the link.

What's even more curious, is that if I have the nVidia Nsight Debugger attached, then I get output on screen and it appears to 'work', but if I just use VS2012 in Debug mode I get nothing displayed on screen, and the following error message:

First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
First-chance exception at 0x000000005EB066E6 (nvoglv64.dll) in application.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

Hi Tanzanite,

I'll try and strip the shader down to the bare minimum reproducable code and paste it this evening.

With regards to the stack trace, I can't access it. The output above is pumped into the console log in VS, and the actual exception seems to be swallowed by the nvoglv64.dll so I can't actually see where it's being triggered.

I'll go through and check that all memory is correctly initialised as well and see if I can get some more information about the exception.

Many thanks

OT: the persistently broken embarrassment known as gamedev forum software - crapped its pants again ... i'll be brief.

With regards to the stack trace, I can't access it. The output above is pumped into the console log in VS, and the actual exception seems to be swallowed by the nvoglv64.dll so I can't actually see where it's being triggered.

The fact that anything shows up in the console log means that the crash happened in user-land in your context where you have authority (it is your stack after all) - if you did not get a debug break then that means you have told your debugger not to do that (you are expected to enable it on your own if and when you need it - which is sensible and preferred behavior in case anyone wonders). If debugger is not told to intercept then the default handler at the bottom of SEH will handle it - part of which is to emit the message into the log (pretty sure only the debug lib of it does that). Anyway, this should help:

http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

... make sure that at least "Access violation" gets caught - or better yet, everything.