How do I use [icode]gl_FragCoord[/icode] in glsl? I’ve read that you need to divide it by the viewport’s dimensions, which is what I did, but the whole quad still renders yellow, which means both X and Y are > 1…
???
I have no clue… Intresting is, that if I only output the [icode]gl_FragCoord.xy[/icode] without dividing it by [icode]uResloution[/icode], which is a vec2(800, 600) here, then it renders completely yellow too… Is this related to the deprecation of gl_FragCoord? (Other apps work… for example davedes’ 2D Illumination demo)
I’m totally confused… probably it’s due to the time being close to midnight here :X
EDIT: Even more cracy is the GLSL doc (or probably I’m cracy…): http://www.opengl.org/sdk/docs/manglsl/xhtml/gl_FragCoord.xml
It says gl_ClipDistance in the “version support” and gl_FragCoord in the “see also” is linking to the exact same site…
Try hardwiring uResolution and see if it works. If it does, then the uResolution uniform isn’t set to what you think it is. Also make sure glColor is some color other than yellow, otherwise your shader could just be failing outright and you’d be seeing fixed function output.
Ugh!.. Right… uResolutions wasn’t set to what I wanted it to be set to. I used glUniform2i instead of glUniform2f :cranky:
Anyways… A previous problem is back. I want to recreate davedes’ 2D illumination stuff with my engine…
The Fragment shader looks like this:
#version 120
uniform sampler2D uTexture; // <- Texture is valid.
uniform vec2 uResolution; // <- gl_FragColor = vec4(uResolution, 0.0, 1.0); gives the right result now.
// This is set to vec4(mousex, mousey, 5, 1);
uniform vec4 uLightPos; // <- Yes. Works. Changes upon Mouse movement and outputting gives right results.
varying vec2 vTexCoords; // <- Yes works. (outputting this via gl_FragColor = textureLookup)
varying vec2 vNormCoords; // <- Works too. (outputting this via gl_FragColor = normalLookup)
void main(void) {
vec4 textureLookup = texture2D(uTexture, vTexCoords);
vec4 normalLookup = texture2D(uTexture, vNormCoords);
vec2 fragPosition = gl_FragCoord.xy / uResolution;
vec3 normal = normalize(normalLookup.xyz * 2.0 - 1.0);
// It looks like this is the part, which doesn't work:
vec3 lightToFragment = vec3(uLightPos.xy - fragPosition, uLightPos.z); // <- Evil Code
float intensity = clamp(dot(normal, normalize(lightToFragment)), 0.0, 1.0);
gl_FragColor = vec4(textureLookup.rgb * intensity, textureLookup.a);
}
And the vertex shader looks like this:
#version 120
uniform mat4 uViewProjMatrix; // <- works, vertices get transformed properly
attribute vec2 aVertex; // <- yeees. vertices are at the right positions.
attribute vec2 aTexCoords; // <- Yup.. Textures work too.
attribute vec2 aNormCoords; // <- as well as these are the right ones.
varying vec2 vTexCoords; // <- Yup.
varying vec2 vNormCoords; // <- Yup.
void main(void) {
vTexCoords = aTexCoords;
vNormCoords = aNormCoords;
gl_Position = uViewProjMatrix * vec4(aVertex, 0.0, 1.0); // <- As you already know, this works.
}
Also note the differences between your brick normals and mine. The green on yours (Y axis) appears below each brick. Unless you invert the green channel, the normal lighting will look flipped. You should pre-process your normals, or account for the different normals in your shader.
Further, what are you using for lightPos.z? Try various values between 0.0 and 10.0.
But yeah, dividing lightPos by the resolution and setting uLightPos.z to 0.5f did the trick!
And I'm not sure if the normal map will give me the inverted y channel problems you had... In the screenshot all shader-drawn stuff was flipped and the shader-origin is in the bottom left corner of the window, instead of the top left, due to wrong setup of the projection matrix. Now this is fixed, the shader-drawn stuff is flipped and everything looks okey.
It’s supposed to look like that. If you look at the brick wall you’ll see that the seams seem to move away from the light. That’s because that part of the seams are facing the light, so it’s illuminated. It’s 100% natural when you think about it.
Notice how the top edge of the bricks is brighter.
EDIT: Disregard that, it’s definitely the same problem. The y-coordinate needs to be flipped.
