Weird If statement

[ypiadyk]

Hello Benny.
As in video #31 of Java Game Engine Development Tutorial I add line in the fragment shader inside the for loop over the point lights:
if(pointLights[i].base.intensity > 0)
But instead of FPS growth I get no point light drawn in the scene. After the whole day of experiments I've noticed:

• if I compare with some negative constant instead of 0 then all lights are back but if statement seems to be ignored
• if I assign all three attenuation coefficient to non-zero values lights are back as in previous case. If statement is still not working
• out of range check in calcPointLight function works just fine (if(distanceToPoint > pointLight.range) return vec4(0,0,0,0);), so I tried to do the same but with pointLight.base.intensity - no success. If I set some intensity threshold that only one of the lights can pass I still get no lights or all lights drawn.

I can't believe that if statement is not working and not to have this kind of optimization is also not a case. The same is observed in c++ version (Initial Commit). Any ideas?
And some more questions: don't we need to specify in/out/inout parameters for input parameters of the functions as in http://www.opengl.org/wiki/GLSL_:_common_mistakes
And second one: is there any better than:
if (textureColor != vec4(0, 0, 0, 0))
way to check inside the shader if some texture was bound? Because current one can cause artefacts if texture contains black pixels with alpha value equal zero.
Thanks.

[BennyQBD]

Does the current version of the repository work for you?

To answer your other questions:
-I believe that was true at one point, however, as far as I'm aware it isn't true in older GLSL versions, and it also isn't true in newer GLSL versions. As OpenGL wiki says in https://www.opengl.org/wiki/Core_Language_%28GLSL%29 , "The default if no qualifier is specific is in." That, combined with the fact that it works with every GLSL compiler I've ever seen, seems to indicate that this is perfectly legal code.

-In a way that stays compatible with GLSL 120, no. However, if you don't care about that, GLSL offers a textureSize function ( https://www.opengl.org/sdk/docs/man/html/textureSize.xhtml ). You can use that to find what the texture's size is, and based on that, you can determine if a texture is bound or not.

[ypiadyk]

Hello, Benny.
Sorry for the late reply. I was following your tutorials further and we get rid of this "weird if statement" later in series when implementing forward rendering system. But it wasn't problem in if statement. Using gDEBugger I have discovered another weird thing that really happens:

• On engine side all uniforms are updated with correct values (doublechecked with debugger, uniform locations are all different). But on shader side pointLight.base.intensity and pointlight.atten.constant uniforms behave like it's one uniform. More precisely pointLight.base.intensity is always equal to pointlight.atten.constant for some mysterious reason. Hence I can't set pointLight.base.intensity to desired value.

This may be connected to another problem I posted: BennyQBD/3DEngineCpp#22
This time pointLight.base.intensity and several more uniforms are optimized away.
And another fact: R_directionalLight.base.intensity works fine.
Did you see such issue earlier? And thanks for answers for other questions!

[BennyQBD]

One quirk of GLSL is if the GLSL compiler doesn't think a uniform affects the code, then it silently removes it. It's possible that one of those two uniforms, according to the GLSL compiler "doesn't affect the code," and that the removal has given them the same value in the final output. I suspect that this could be a driver bug, and if the code works on other computers, then it probably is.

That's one of the reasons why I want to know if the current repository works for you. If it doesn't, then it almost certainly is a driver issue (or I've somehow royally screwed something up somewhere). If it does work for you, then it's more likely that you've either made a mistake in your GLSL code, or you've written your GLSL code in a way that's confusing the compiler like that.