Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [GLSL] 2D Illumination issues.  (Read 2413 times)
0 Members and 1 Guest are viewing this topic.
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Posted 2012-12-08 22:35:19 »

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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline sproingie

JGO Kernel


Medals: 202



« 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.
Offline 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!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #3 - Posted 2012-12-08 22:57:56 »

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)
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline 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.

Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« 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 Smiley
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>

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline 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;
Offline 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)


Quote from: pitbuller
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!
Legends of Yore - The Casual Retro Roguelike
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #10 - Posted 2012-12-09 08:33:32 »

Quote from: pitbuller
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 ^^

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #11 - Posted 2012-12-09 16:18:13 »

Everything works now, as expected, thank you guys! Smiley

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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 133
Projects: 4
Exp: 3 years



« Reply #12 - Posted 2012-12-09 16:52:28 »

Huh, that's nice...the textures do seem to "stretch" to the light though...
Offline 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.

work in progress : D A E D A L U S
Offline 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.
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« 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 Smiley

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

I won't make a video though.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline davedes
« Reply #16 - Posted 2012-12-09 18:06:54 »

Hehe... told you it was subtle. Smiley

Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #17 - Posted 2012-12-09 18:20:26 »

Hehe... told you it was subtle. Smiley

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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (40 views)
2014-09-24 16:13:29

Pippogeek (31 views)
2014-09-24 16:12:22

Pippogeek (21 views)
2014-09-24 16:12:06

Grunnt (47 views)
2014-09-23 14:38:19

radar3301 (29 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (44 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06

BurntPizza (55 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!