[GLSL] 2D Illumination issues.

[matheus23]

How do I use

gl_FragCoord

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

gl_FragCoord.xy

without dividing it by

uResloution

, 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

This is the fragment shader's source:

1   2   3   4   5   6   7   8

#version 120 uniform vec2 uResolution; void main(void) {    vec2 fragPosition = gl_FragCoord.xy / uResolution;    gl_FragColor = vec4(fragPosition, 0.0, 1.0); }

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...

[sproingie]

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.

[theagentd]

gl_FragCoord is the coordinates of the pixel in pixels from the top left corner.

Games published by our own members! Check 'em out!

[sproingie]

Default for gl_FragCoord is lower-left, sayeth http://www.opengl.org/sdk/docs/manglsl/xhtml/gl_FragCoord.xml

(which does something funny in my browser so i can't copy-paste)

[matheus23]

Try hardwiring uResolution and see if it works.  If it does, then uResolution 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 
Anyways... A previous problem is back. I want to recreate davedes' 2D illumination stuff with my engine...

The Fragment shader looks like this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22

#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:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

#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. }

EDIT: Screenshot is in work...

[matheus23]

Okey, Here is a screenshot:


The top left image is the texture, the second image is the normal map and the third one is the shader rendering...

[davedes]

Is lightPos in screen space or did you divide it by resolution?

1	vec3 lightDir = vec3( (lightPos.xy - gl_FragCoord.xy) / resolution.xy, lightZ);

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.

[matheus23]

Is lightPos in screen space or did you divide it by resolution?
Further, what are you using for lightPos.z? Try various values between 0.0 and 10.0.

Both answers are in the comments

1	// This is set to vec4(mousex, mousey, 5, 1);

But yeah, dividing lightPos by the resolution and setting uLightPos.z to 0.5f did the trick!

<offtopic>
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.
</offtopic>

[pitbuller]

Just add new varying vec2 and use that. Lot simpler and tt should be faster also.

At vertex shader:
varying vec2 screenCoord;

screenCoord = gl_Position.xy * 0.5 +0.5;

[davedes]

<offtopic>
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.
</offtopic>

Yup, it ultimately has to do with left-handed vs. right-handed coordinate system, so maybe it won't be a problem for your engine.

The difference is subtle, so double check to make sure it's correct.

Correct: (light at bottom right corner)


Incorrect: (again, light at bottom right)

Just add new varying vec2 and use that. Lot simpler and tt should be faster also.

How does this help or make any sense?

Games published by our own members! Check 'em out!

[matheus23]

Just add new varying vec2 and use that. Lot simpler and tt should be faster also.

How does this help or make any sense?

I guess he explained how to get screen-pixel position from the vertices, but yeah... that does not help me. Probably he didn't read the whole topic ^^

[matheus23]

Everything works now, as expected, thank you guys!

(Btw, it's not in the video, but I'm having up to 8006 FPS. GTX 550Ti, Intel Xenon quadcore, hyperthreading)

<a href="http://www.youtube.com/v/8EdLWfaAA8o?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/8EdLWfaAA8o?version=3&amp;hl=en_US&amp;start=</a>

[Jimmt]

Huh, that's nice...the textures do seem to "stretch" to the light though...

[deathpat]

I think you have the issue described by davedes, the lighting seems to be inverted, that's why the textures seem to move when moving the light.

[theagentd]

Huh, that's nice...the textures do seem to "stretch" to the light though...

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.

[matheus23]

EDIT: Disregard that, it's definitely the same problem. The y-coordinate needs to be flipped.

Yes. I just re-generated the normal map and compared the result from another normal map with the new one...

Yep... It had to be flipped

I'm now generating the normal map with this settings:
0.5 intensity 5x5 Prewitt, Wrappable and Y-Inverted

I won't make a video though.

[davedes]

Hehe... told you it was subtle.

[matheus23]

Hehe... told you it was subtle.

Yeah... It was less subtle than I thought... In your example the effect wasn't that subtle... But yeah... you're right