Jump to content
  • Advertisement

FTLRalph

Member
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

123 Neutral

About FTLRalph

  • Rank
    Member
  1. 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. 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?
  3. If it wasn't painfully obvious, this is my first real experience with shader programming. Much of this code is a slightly modified version from this tutorial:   https://github.com/mattdesl/lwjgl-basics/wiki/ShaderLesson6#FragmentShader   I basically just removed ambient lights and attempted to shove in lights with sizes.   Anyway, I've been reading what you guys have said but still can't quite make any progress.   @snake5 - I think you might be right about the radius, I got rid of the diameter. Also, it's all 2D, the z component is already in the range of 0-1 so it doesn't need to be scaled. Also, I'm not sure how I'd go about dividing the diameter/radius out from the distance later, I've tried it a few ways to no avail and can't seem to wrap my head around it. (The lack of being able to print out/debug variables is really messing with me.)   @Eklipse - What you say makes sense. Like I mentioned, much of this code is from the tutorial above. I went and implemented it your way (1/ distance).   Here's the updated fragment shader with the minor tweaks: #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 lightPos;      // Position of point light (UV coords) uniform vec4 lightColor;    // Color of light, a is intensity uniform vec2 screenSize;    // Screen resolution (screen coords) 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.     lightDir.x /= (lightRadius / screenSize.x);     lightDir.y /= (lightRadius / 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;     if (distance != 0)         attenuation = max(1.0 / distance, 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); } And its output:   The radius is still obviously messed up. But these tweaks appears to make it clearer that the top-right corner of the lights being dark is not an error, but seems to be correct. It's the rest of the "corners" of the light that appear to incorrectly bright, if that makes sense?
  4. 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. 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. FTLRalph

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

    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. 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. Thanks, appreciate it!  And to be fair, 20 years ago was a long time ;)
  10. Stick Nodes - A simple-yet-robust stickfigure animation program created with mobile devices in mind! Hey guys, just got around to releasing my latest Android app.  To be perfectly honest, this probably isn't so much a "game" as much as it's just a fun way to spend some time - close enough, right? Links Google Play: [Free] [Pro] SlideMe: [Free] [Pro] Amazon: [Free] [Pro] More info: [Website] [Facebook] [Google+] The pro version has no startup ad and doesn't place a small watermark on exported animated .gifs, otherwise the two versions are identical. About You can get a lot more information / screenshots from the official website or the Google Play listing pages, but here's some quick info. Stick Nodes is a simple-yet-robust animation program that allows you to create and animate stickfigures frame by frame (with optional built-in tweening) to produce an animated .gif you can share with others. Some of the features include: Automatic frame-tweening turned on/off with the click of a button. Great variety in segment shape types allows for greater creativity. Color/scale on a per-segment basis - easily color your stickfigures. Ability to create, save, import, and share stickfigures you create. Compatibility with Pivot-created .stk files (version 2.2.7 and earlier). Pinch-to-zoom to make animating more convenient and simple. Forward and backward onion-skinning for precise animating. Clean, simple interface created with mobile devices in mind. More stuff I'm forgetting... Example Here's a quick animation created by another user. Screenshots Some screenshots to give you an idea of what the app looks like. It's a load of fun especially for those with a creative imagination, would love to see some examples of what you guys come up with!  
  11. 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!
  12.   Plunder Peril - Can you jump, dodge, and loot your way to the top of the leaderboard?   Hey fellow gamedev peeps, excited to announce that after years of making web-based Flash games, I've finally broken into a new market with my first Android game, Plunder Peril!   Links Free on Google Play: [Link] Trailer: [Youtube] Website: [ForTheLoss.org] About If you require a simple yet challenging time-passer, Plunder Peril is the answer.  The premise is simple - from a top-down perspective your only goal is to guide your character around and collect any and all coins you see – oh, and to survive for as long as possible. Jump, dodge, and loot your way to the best possible score you can achieve.  Submit to the leaderboard to see how well you rank against others in the world! If you enjoy a good challenge accompanied by fast-paced gameplay, give Plunder Peril a go!   Screenshots Press Material: I also compiled some screenshots, information, etc into a convinient zip file for anyone wanting to post about the game.  I appreciate any and all publicity and thank you! [Press Material] Thanks for any feedback / ratings / publicity / just playing the game!  Really appreciate it!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!