# FTLRalph

Member

12

123 Neutral

• Rank
Member
1. ## 2D point lights, limiting their radius?

Thanks a lot L. Spiro, that helped get me on the right path. However, your attenuation formula wasn't working out, so I tweaked it a bit to the following: #version 330 in vec4 v_color; in vec2 v_texCoord; uniform sampler2D u_texture; uniform sampler2D u_normal; uniform float lightRadius;  // Radius of light (screen coords) uniform vec2 lightCoord;    // Position of point light (screen coords) uniform vec4 lightColor;    // Color of light, a is intensity uniform float lightZ;        // Z-index of light (0-1) layout(location = 0) out vec4 lightBuffer; void main() {     // RGBA of diffuse color.     vec4 diffuseRGBA = texture2D(u_texture, v_texCoord);     // RGB of normal map, invert g in normal map for accuracy.     vec3 normalRGB = texture2D(u_normal, v_texCoord).rgb;     normalRGB.g = 1.0 - normalRGB.g;          // The delta position of the light.     vec2 lightDir = vec2(lightCoord - gl_FragCoord.xy);          // Distance to light.     float distance = length(lightDir);          // Attenuation.     float attenuation = clamp(1.0 - ((distance * distance) / (lightRadius * lightRadius)), 0.0, 1.0);     // Normalize vectors.     vec3 N = normalize(normalRGB * 2.0 - 1.0);     vec3 L = vec3(normalize(lightDir), lightZ);          // Pre-multiply light color with intensity then perform "N dot L" to determine diffuse term.     vec3 diffuse = (lightColor.rgb * lightColor.a) * max(dot(N, L), 0.0);          // The calculation which brings it all together.     vec3 intensity = diffuse * attenuation;     vec3 finalColor = diffuseRGBA.rgb * intensity;          // Done.     lightBuffer = v_color * vec4(finalColor, diffuseRGBA.a); } I'm still going to keep the z-index as it gives flexibility to how the lights are displayed, but I'm just going to only use it where needed, everything seems to work well now in world coordinates. Really appreciate all of the help guys.     I still have absolutely no idea what's with that dead spot/area to the top-right of each light though. I upped the intensity of the lights to make the effect more visible.   Anyone have any ideas? I've been playing with the almost all of the variables in the shader to no avail.
2. ## 2D point lights, limiting their radius?

Really appreciate all of the help guys. Sorry for the utter display of stupidity, for some reason this is giving me a hard time.   @vlj - You know, that actually worked. The lights are now displaying properly using (1.0 - distance) for attenuation. Seeing it, it does make sense now. Appreciate it a ton.   @phil_t - I'm trying to apply your advice, I'd love to have things simplified using just screen coordinates. As a result, I've attempted to abandon UV coordinates and am trying to work in just screen coordinates, however, I think I broke everything (no lights are being displayed). Here's the shader code where I've tried to adapt it to what you suggested: #version 330 in vec4 v_color; in vec2 v_texCoord; uniform sampler2D u_texture; uniform sampler2D u_normal; uniform float lightRadius;  // Radius of light (screen coords) uniform vec3 lightCoord;    // Position of point light (screen coords, z is 0-1) uniform vec4 lightColor;    // Color of light, a is intensity layout(location = 0) out vec4 lightBuffer; void main() {     // RGBA of diffuse color.     vec4 diffuseRGBA = texture2D(u_texture, v_texCoord);     // RGB of normal map, invert the y-axis for accuracy.     vec3 normalRGB = texture2D(u_normal, v_texCoord).rgb;     normalRGB.g = 1.0 - normalRGB.g;          // The delta position of the light.     vec3 lightDir = vec3(lightCoord.xy - gl_FragCoord.xy, lightCoord.z); // lightCoord.z is 0-1, lightCoord.xy are screen coords          // Distance to be used for attenuation.     float distance = length(lightDir.xy) / lightRadius;          // Attenuation.     float attenuation = clamp(1.0 - distance, 0.0, 1.0);     attenuation *= attenuation;     // Normalize vectors.     vec3 N = normalize(normalRGB * 2.0 - 1.0);     vec3 L = normalize(lightDir);          // Pre-multiply light color with intensity then perform "N dot L" to determine diffuse term.     vec3 diffuse = (lightColor.rgb * lightColor.a) * max(dot(N, L), 0.0);          // The calculation which brings it all together.     vec3 intensity = diffuse * attenuation;     vec3 finalColor = diffuseRGBA.rgb * intensity;          // Done.     lightBuffer = v_color * vec4(finalColor, diffuseRGBA.a); } That seems pretty close to what you said, if I had to guess, I'd say the fact that my lightCoord.z being 0-1 whereas lightCoord.xy being screen coordinates is what's messing with me.   Would that be the case? Really wouldn't know how to go about not using 0-1 for z though?

4. ## 2D point lights, limiting their radius?

Thanks for the reply.   That's an interesting idea. I don't have the code in front of me at the moment, I'll check it out later.   Meanwhile, I discovered another issue last night, in case you or anyone else can help me shed some light on it. Notice the "dead area" in the top-right area of all of the point lights:     I can't seem to figure out what would be causing that.   Any ideas? Thanks!
5. ## 2D point lights, limiting their radius?

Hey guys, hopefully someone smarter than me can help me out.   I have some point lights. They have a radius. However, the light they emit doesn't seem to be constrained by this radius like I want, see this image:     (The red circles are what their radius should be. You can see how the light continues though, producing a very visible square shape.)   Here's the shader I use where I pass in each light one by one and render it to the scene: #version 330 in vec4 v_color; in vec2 v_texCoord;            // UV for the current fragment uniform sampler2D u_texture; uniform sampler2D u_normal; uniform float lightRadius;  // Radius of light (pixels) uniform vec3 lightPos;      // Position of point light (UV) uniform vec4 lightColor;    // Color of light, a is intensity uniform vec2 screenSize;    // Screen resolution (pixels) layout(location = 0) out vec4 lightBuffer; void main() {     // RGBA of diffuse color.     vec4 diffuseRGBA = texture2D(u_texture, v_texCoord);     // RGB of normal map, invert the y-axis for accuracy.     vec3 normalRGB = texture2D(u_normal, v_texCoord).rgb;     normalRGB.g = 1.0 - normalRGB.g;     // The delta position of light     vec3 lightDir = vec3(lightPos.xy - (gl_FragCoord.xy / screenSize.xy), lightPos.z);     // Correct for aspect ratio and set size of light.     float lightDiameter = lightRadius * 2;     lightDir.x /= (lightDiameter / screenSize.x);     lightDir.y /= (lightDiameter / screenSize.y);     // Determine distance (used for attenuation) before normalizing lightDir.     float distance = length(lightDir);     // Normalize vectors.     vec3 N = normalize(normalRGB * 2.0 - 1.0);     vec3 L = normalize(lightDir);          // Pre-multiply light color with intensity then perform "N dot L" to determine diffuse term.     vec3 diffuse = (lightColor.rgb * lightColor.a) * max(dot(N, L), 0.0);     // Calculate attenuation.     float attenuation = 1.0 - (distance * distance);     // The calculation which brings it all together.     vec3 intensity = diffuse * attenuation;     vec3 finalColor = diffuseRGBA.rgb * intensity;          // Done.     lightBuffer = v_color * vec4(finalColor, diffuseRGBA.a); } Can anyone shed some light on what's going on, appreciate it!
6. ## Lighting with deferred rendering

Alright guys, thanks for the input. Just hearing it put in a different way helps me to make sense of it better.
7. ## Lighting with deferred rendering

Alright, I think I'm grasping the idea a little better.   If I'm understanding correctly, I would need to first populate my lighted backbuffer with the gbuffer diffuse data completely, and then loop throught my lights and add them one by one (bounding the draw area like you said), right?   And additive blending, from what I'm reading, it seems I should be using (GL_ONE, GL_ONE), right?   The only issue I've seen from this approach is if I re-draw a piece of the screen over and over on top of itself with this blending, it seems to become bright/over-exposed and obviously doesn't look right. How can this be avoided?
8. ## Lighting with deferred rendering

Hey all, I'm working on a 2D-deferred-rendering-with-lighting implementation and I have a question. So for those of you familiar with deferred rendering, I already have my geometry FBO populated with a diffuse buffer and a normal buffer. I'm now currently at the stage where I need to add some lights to a "light accumulation buffer" and I have no idea what that means. I take it I need a new FBO to render in - okay I got that. I also have an array full of light data objects (x, y, rgb, intensity, radius) - only dealing with point lights at the moment. I'm assuming I need to for-loop through my lights, set the appropriate uniforms of a shader per light, draw the diffuseBuffer texture to the new light FBO while the shader does its lighting magic, and repeat. However, I don't understand how that would work. Wouldn't I just overwrite the previous light after I draw over it in the next light pass? And the next one, and so on? What if lights overlap? I believe looking at a standard normal-lighting GLSL shader for this type of implementation would really help. Or any advice, really. Appreciate any help!
9. ## [Free] Stick Nodes - Stickfigure animation app!

Thanks, appreciate it!  And to be fair, 20 years ago was a long time ;)

11. ## Plunder Peril - Addictive (and free) Android app

I've Google'd around and asked on Twitter but haven't had much luck, maybe someone here can offer some input. Is there a source (list of some type perhaps?) of marketing/review blogs that post about Android games/apps? I know about the "big" ones (indiegames.com, tigsource.com), but I'm looking for more achievable mid-level ones that I can get in touch with.   Appreciate it!