matheus23
|
 |
«
Posted
2012-12-08 22:35:19 » |
|
How do I use 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 without dividing it by , 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.xmlIt says gl_ClipDistance in the "version support" and gl_FragCoord in the "see also" is linking to the exact same site...
|
|
|
|
sproingie
|
 |
«
Reply #1 - Posted
2012-12-08 22:47:21 » |
|
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
|
 |
«
Reply #2 - Posted
2012-12-08 22:57:06 » |
|
gl_FragCoord is the coordinates of the pixel in pixels from the top left corner.
|
Myomyomyo.
|
|
|
Games published by our own members! Check 'em out!
|
|
|
matheus23
|
 |
«
Reply #4 - Posted
2012-12-08 23:01:38 » |
|
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; uniform vec2 uResolution;
uniform vec4 uLightPos;
varying vec2 vTexCoords; varying vec2 vNormCoords;
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); vec3 lightToFragment = vec3(uLightPos.xy - fragPosition, uLightPos.z); 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;
attribute vec2 aVertex; attribute vec2 aTexCoords; attribute vec2 aNormCoords;
varying vec2 vTexCoords; varying vec2 vNormCoords;
void main(void) { vTexCoords = aTexCoords; vNormCoords = aNormCoords; gl_Position = uViewProjMatrix * vec4(aVertex, 0.0, 1.0); } |
EDIT: Screenshot is in work...
|
|
|
|
matheus23
|
 |
«
Reply #5 - Posted
2012-12-08 23:10:02 » |
|
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
|
 |
«
Reply #6 - Posted
2012-12-08 23:17:36 » |
|
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
|
 |
«
Reply #7 - Posted
2012-12-08 23:27:00 » |
|
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  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
|
 |
«
Reply #8 - Posted
2012-12-08 23:28:18 » |
|
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
|
 |
«
Reply #9 - Posted
2012-12-09 00:26:30 » |
|
<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
|
 |
«
Reply #10 - Posted
2012-12-09 08:33:32 » |
|
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 ^^
|
|
|
|
|
Jimmt
|
 |
«
Reply #12 - Posted
2012-12-09 16:52:28 » |
|
Huh, that's nice...the textures do seem to "stretch" to the light though...
|
|
|
|
deathpat
|
 |
«
Reply #13 - Posted
2012-12-09 17:07:06 » |
|
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
|
 |
«
Reply #14 - Posted
2012-12-09 17:26:49 » |
|
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.
|
Myomyomyo.
|
|
|
matheus23
|
 |
«
Reply #15 - Posted
2012-12-09 17:47:09 » |
|
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
|
 |
«
Reply #16 - Posted
2012-12-09 18:06:54 » |
|
Hehe... told you it was subtle. 
|
|
|
|
matheus23
|
 |
«
Reply #17 - Posted
2012-12-09 18:20:26 » |
|
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 
|
|
|
|
|