OpenGL 3/4 & uniforms

Hello, i have a vertex and a fragment that are linked together, that i feed an uniform of type integer that i use in a loop locally in each shader (does num lights)

Problem i am having is that is it only appears that the fragment shader (in my case) get the correct uniform integer value called in C++.
While uniforms with distinct names(between the two) works fine.

Is it correct that i have to use separate names, even though the two shaders are linked into a single shader program?
I could use “out int ActiveLights = uniform int varSetFromC++” and “in int ActiveLights” if thats the route i have to take.

Weird. Since programs get uniform values, not shaders, I suspect one of two possibilities: 1) That’s not what’s going on – further investigation may reveal that it’s something else (e.g. not populating the uniform properly, actually using different names or types, etc.), or 2) That “is” what’s going on and it’s a driver bug. What GPU, driver, and driver version are you using? Can you post a short GLUT test prog that illustrates the problem?

Try passing the vtx shader’s uniform value into the frag shader, compare the values, and write “white” out if the same and “black” if different.

OK i appreciated the clarification on uniforms, doing the test you mentioned also confirms that the input into the two shaders are correct. I think i need to do some more tests as there are an issue with the way GLSL handles the uniform. Could be a driver bug as i can easily re-produce the graphical glitch by make the two for loops go higher +1 higher than what i define correctly in the uniform variable. If i hardcode the uniform value in the “for (int i = 0; i < UNIFORM…” it runs without any glitches!

I use AMD 7970 drivers which makes me a bit suspicious it could be an issue there.

Just in case i have done something horrible wrong, just a quick post of the vertex shader (fragment shader is almost identical as far as ActiveShadowMaps goes)
If the shader bellow look ok(ish), i should be able to test other drivers and some other gpu’s from Nvidia

#version 420

// Input vertex data, different for all executions of this shader.
layout(location = 0) in vec3 vertexPosition_modelspace;
layout(location = 1) in vec3 vertexNormal_modelspace;
layout(location = 2) in vec2 vertexUV;
layout(location = 3) in vec3 vertexTangent_modelspace;
layout(location = 4) in vec3 vertexBitangent_modelspace;

// Output data ; will be interpolated for each fragment.
out vec2 UV;
out vec3 Position_worldspace;
out vec3 EyeDirection_cameraspace;
out vec3 EyeDirection_tangentspace;

out vec3 VertexNormalCameraspace;
out vec3 VertexPositionCameraspace;

// Values that stay constant for the whole mesh.
uniform mat4 P;
uniform mat4 V;
uniform mat4 M;

struct LightInfo {
    vec4 Position;
	vec4 View;
	vec3 Color;
	float Intensity;
	float Bias;	
};
uniform LightInfo Light[1]; 
out vec3 LightDirection_tangentspace[1];

uniform int ActiveShadowMaps;	
uniform mat4 shadowmat[1]; // combination of projection * view matrices of the light source
out vec4 sc[1]; // output "shadow coords" used for sampling the depth-map texture

//convert clip coords to texture coords
const mat4 bias = mat4(0.5, 0.0, 0.0, 0.0,
                       0.0, 0.5, 0.0, 0.0,
                       0.0, 0.0, 0.5, 0.0,
                       0.5, 0.5, 0.5, 1.0);
					   
uniform float MaterialTextureTileFactor;

void main(){
		
	// Position of the vertex, in worldspace : M * position
	Position_worldspace = (M * vec4(vertexPosition_modelspace,1)).xyz;
	
	// Vector that goes from the vertex to the camera, in camera space.
	// In camera space, the camera is at the origin (0,0,0).
	VertexPositionCameraspace = ( V * M * vec4(vertexPosition_modelspace,1)).xyz;
	EyeDirection_cameraspace = vec3(0,0,0) - VertexPositionCameraspace;
	
	// UV of the vertex. No special space for this one.
	UV = vertexUV * MaterialTextureTileFactor;
	
	vec3 vertexTangent_cameraspace; 
	vec3 vertexBitangent_cameraspace;	
	
	// model to camera = ModelView
	mat3 MV3x3 = V * M;
	vertexTangent_cameraspace = MV3x3 * vertexTangent_modelspace;
	vertexBitangent_cameraspace = MV3x3 * vertexBitangent_modelspace;
	VertexNormalCameraspace = MV3x3 * vertexNormal_modelspace;

	mat3 TBN = transpose(mat3(
		vertexTangent_cameraspace,
		vertexBitangent_cameraspace,
		VertexNormalCameraspace	
	)); // You can use dot products instead of building this matrix and transposing it. See References for details.

	// Fail! for (int i = 0; i < ActiveShadowMaps; i++) {
	// Works!
        for (int i = 0; i < 1; i++) {
		// Vector that goes from the vertex to the light, in camera space. M is ommited because it's identity.
		vec3 LightPosition_cameraspace = (V * vec4(Light[i].Position)).xyz;
		
		sc[i] = bias * shadowmat[i] * vec4(Position_worldspace, 1);
		
		LightDirection_tangentspace[i] = TBN * (LightPosition_cameraspace + EyeDirection_cameraspace);
	}
	EyeDirection_tangentspace =  TBN * EyeDirection_cameraspace;
	
	// Output position of the vertex, in clip space : MVP * position
	gl_Position =  (P * V * M) * vec4(vertexPosition_modelspace,1);
}

[QUOTE=fredvam;1248178]…i can easily re-produce the graphical glitch by make the two for loops go higher +1 higher than what i define correctly in the uniform variable. If i hardcode the uniform value in the “for (int i = 0; i < UNIFORM…” it runs without any glitches!..


#version 420
...
uniform int ActiveShadowMaps;    
...
  // Fail! for (int i = 0; i < ActiveShadowMaps; i++) {
  // Works!
  for (int i = 0; i < 1; i++) {
        // Vector that goes from the vertex to the light, in camera space. M is ommited because it's identity.
        vec3 LightPosition_cameraspace = (V * vec4(Light[i].Position)).xyz;
        
        sc[i] = bias * shadowmat[i] * vec4(Position_worldspace, 1);
        
        LightDirection_tangentspace[i] = TBN * (LightPosition_cameraspace + EyeDirection_cameraspace);
    }
...
}

[/QUOTE]

Hmmm. You’re populating ActiveShadowMaps with glUniform1i or glUniform1iv? And you’re sure you’re providing the correct value on the C++ side?

The one thing that sticks out is that this is used in the loop condition. GLSL compilers sometimes like to unroll loops, and you can get into some strange stuff there. But I’d think in this case there’s no way any unrolling should be coming into play.

If the shader bellow look ok(ish), i should be able to test other drivers and some other gpu’s from Nvidia

I just threw it at NVidia (via cgc -oglsl) and it didn’t compile. I get:


t.glsl(65) : error C7011: implicit cast from "mat4" to "mat3"

on “mat3 MV3x3 = V * M;”. Though if I add a mat3 cast on it, it does compile. Haven’t executed it though of course.

You are right about the missing mat3 cast, AMD did not catch this when i queried for errors (after compiling the shader) so they did an implicit cast for me…

Did some quick tests on a Nvidia based system, as far as i can tell there is no glitch. So most likely an AMD driver glitch then. Appreciate your clarifications on uniforms and the comments on the shader, saved time from changing something that worked.

For setting uniform integers I use glUniform1i, I tried glUniform1iv too but as far as AMD goes, made no difference.