Hey everyone I'm working with lighting in a 2D Tile Based game and have run into a problem with my lighting calculations, in my game I take greyscale images then color them using shaders whatever color I like whether that be green(rgb=(0,1,0)) or red(rgb=(1,0,0)) or any color. So then I apply my lighting calculations to that textured and colored pixel. The lighting works fine when the light is white(rgb=(1,1,1)) but when it is say red or green it wont show the way I want it to. I know why this is happening of course because realistic a pure red light in a pure green room would reflect no red light so the room would remain dark. What I really want is to see a red light appear over a green surface. So my question is how can I show a red light clearly on a green surface?(or really any other color on any surface)
This is the code for my fragment shader, where attenuation is simply the attenuation for the light, lightColor is obviously the lights rgb value, distance is the distance from the given vector to that light(calculated in the vertex shader) and finally color is the rgb value that is applied to the texture.
Thanks in advance for your help!
vec3 totalDiffuse = vec3(0.0);
for(int i = 0; i < 4; i++)
{
float attFactor = attenuation[i].x + (attenuation[i].y * distance[i]) + (attenuation[i].z * distance[i] * distance[i]);
totalDiffuse = totalDiffuse + (lightColor[i])/attFactor;
}
totalDiffuse = max(totalDiffuse,0.2);
out_Color = texture(textureSampler, pass_textureCoords)*vec4(color,alpha)*vec4(totalDiffuse,1);
And here is an image of what a pure red light looks like on a surface currently, it should be inside the white circle and you may be able to see it is affecting the water a little bit because I give the water a small red component-
Light Demo Image
One possibility would be to change the light calculation.
Calculate a gray scales of the light color and the surface color. Multiply the surface color by the gray scale of the light color and the multiply the light color by the gray scale of the surface color, finally sum them up:
vec4 texCol = texture(textureSampler, pass_textureCoords);
float grayTex = dot(texCol.rgb, vec3(0.2126, 0.7152, 0.0722));
float grayCol = dot(colGray.rgb, vec3(0.2126, 0.7152, 0.0722));
vec3 mixCol = texCol.rgb * grayCol + color.rgb * grayTex;
out_Color = vec4(mixCol * totalDiffuse, texCol.a * alpha);
Note, this algorithm emphasizes the color of the light at the expense of the color of the surface. But that was what you wanted by dipping a green area in red light. Of course, that contradicts the desire to illuminate an area in its own color. If the light is white, then the surface will also shine white.
If you want some light sources with the effect described above, other sources but with the original effect of the question, then I recommend to introduce a parameter that mixes the two effects:
uniform float u_lightTint;
void main()
{
.....
vec3 mixCol = texCol.rgb * grayCol + color.rgb * grayTex;
mixCol = mix(texCol.rgb * color.rgb, mixCol.rgb, u_lightTint);
out_Color = vec4(mixCol * totalDiffuse, texCol.a * alpha);
}
If u_lightTint is set 1.0, then the "new" light calculation is uses, it it is set 0.0, then the original light calculation is use. Both algorithms can be interpolated linearly by u_lightTint.
Alternatively the u_lightTint parameter can be encoded in the alpha channel of the light color:
mixCol = mix(texCol.rgb * color.rgb, mixCol.rgb, color.a);
Related
I am using this code to generate sphere vertices and textures but as you can see in the image , when I rotate it I can see a dark band.
for (int i = 0; i <= stacks; ++i)
{
float s = (float)i / (float) stacks;
float theta = s * 2 * glm::pi<float>();
for (int j = 0; j <= slices; ++j)
{
float sl = (float)j / (float) slices;
float phi = sl * (glm::pi<float>());
const float x = cos(theta) * sin(phi);
const float y = sin(theta) * sin(phi);
const float z = cos(phi);
sphere_vertices.push_back(radius * glm::vec3(x, y, z));
sphere_texcoords.push_back((glm::vec2((x + 1.0) / 2.0, (y + 1.0) / 2.0)));
}
}
// get the indices
for (int i = 0; i < stacks * slices + slices; ++i)
{
sphere_indices.push_back(i);
sphere_indices.push_back(i + slices + 1);
sphere_indices.push_back(i + slices);
sphere_indices.push_back(i + slices + 1);
sphere_indices.push_back(i);
sphere_indices.push_back(i + 1);
}
I can't figure a way to make it right whatever texture coordinates I used.
Hmm.. If I use another image, then the mapping is different (and worst!)
vertex shader:
#version 330 core
layout (location = 0) in vec3 aPos;
layout (location = 1) in vec3 aTexCoord;
out vec4 vertexColor;
out vec2 TexCoord;
uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;
void main()
{
gl_Position = projection * view * model * vec4(aPos.x, aPos.y, aPos.z, 1.0);
vertexColor = vec4(0.5, 0.2, 0.5, 1.0);
TexCoord = vec2(aTexCoord.x, aTexCoord.y);
}
fragment shader:
#version 330 core
out vec4 FragColor;
in vec4 vertexColor;
in vec2 TexCoord;
uniform sampler2D sphere_texture;
void main()
{
FragColor = texture(sphere_texture, TexCoord);
}
I am not using any lighting conditions.
If I use FragColor = vec4(TexCoord.x, TexCoord.y, 0.0f, 1.0f); in fragment shader (for debugging purposes) , I am receiving a nice sphere.
I am using this as texture:
That image of the tennis ball that you linked reveals the problem. I'm glad you ultimately provided it.
Your image is a four-channel PNG with transparency (Alpha channel). There are transparent pixels all around the outside of the yellow part of the ball that have (R,G,B,A) = (0, 0, 0, 0), so if you're ignoring the A channel then (R, G, B), will be (0, 0, 0) = black.
Here are just the Red, Green, and Blue (RGB) channels:
And here is just the Alpha (A) channel.
The important thing to notice is that the circle of the ball does not fill the square. There is a significant margin of 53 pixels of black from the extent of the ball to the edge of the texture. We can calculate the radius of the ball from this. Half the width is 1000 pixels, of which 53 pixels are not used. The ball's radius is 1000-53, which is 947 pixels. Or about 94.7% of the distance from the center to the edge of the texture. The remaining 5.3% of the distance is black.
Side note: I also notice that your ball doesn't quite reach 100% opacity. The yellow part of the ball has an alpha channel value of 254 (of 255) Meaning 99.6% opaque. The white lines and the shiny hot spot do actually reach 100% opacity, giving it sort of a Death Star look. ;)
To fix your problem, there's the intuitive approach (which may not work) and then there are two things that you need to do that will work. Here are a few things you can do:
Intuitive Solution:
This won't quite get you 100% there.
1) Resize the ball to fill the texture. Use image editing software to enlarge the ball to fill the texture, or to trim off the black pixels. This will just make more efficient use of pixels, for one, but it will ensure that there are useful pixels being sampled at the boundary. You'll probably want to expand the image to be slightly larger than 100%. I'll explain why below.
2) Remap your texture coordinates to only extend to 94.7% of the radius of the ball. (Similar to approach 1, but doesn't require image editing). This just uses coordinates that actually correspond to the image you provided. Your x and y coordinates need to be scaled about the center of the image and reduced to about 94.7%.
x2 = 0.5 + (x - 0.5) * 0.947;
y2 = 0.5 + (y - 0.5) * 0.947;
Suggested Solution:
This will ensure no more black.
3) Fill the "black" portion of your ball texture with a less objectionable colour - probably the colour that is at the circumference of the tennis ball. This ensures that any texels that are sampled at exactly the edge of the ball won't be linearly combined with black to produce an unsightly dark-but-not-quite-black band, which is almost the problem you have right now anyway. You can do this in two ways. A) Image editing software. Remove the transparency from your image and matte it against a dark yellow colour. B) Use the shader to detect pixels that are outside the image and replace them with a border colour (this is clever, but probably more trouble than it's worth.)
Different Texture Coordinates
The last thing you can do is avoid this degenerate texture mapping coordinate problem altogether. At the equator, you're not really sure which pixels to sample. The black (transparent) pixels or the coloured pixels of the ball. The discrete nature of square pixels, is fighting against the polar nature of your texture map. You'll never find the exact colour you need near the edge to produce a continuous, seamless map. Instead, you can use a different coordinate system. I hope you're not attached to how that ball looks, because let me introduce you to the equirectangular projection. It's the same projection that you can naively use to map the globe of the Earth to a typical rectangular map of the world you're likely familiar with where the north and south poles get all the distortion but the equatorial regions look pretty good.
Here's your image mapped to equirectangular coordinates:
Notice that black bar at the bottom...we're onto something! That black bar is actually exactly what appears around the equator of your ball with your current texture mapping coordinate system. But with this coordinate system, you can see easily that if we just remapped the ball to fill the square we'd completely eliminate any transparent pixels at all.
It may be inconvenient to work in this coordinate system, but you can transform your image in Photoshop using Filter > Distort > Polar Coordinates... > Polar to Rectangular.
Sigismondo's answer already suggests how to adjust your texture mapping coordinates do this.
And finally, here's a texture that is both enlarged to fill the texture space, and remapped to equirectangular coordinates. No black bars, minimal distortion. But you'll have to use Sigismondo's texture mapping coordinates. Again, this may not be for you, especially if you're attached to the idea of the direct projection for your texture (i.e.: if you don't want to manipulate your tennis ball image and you want to use that projection.) But if you're willing to remap your data, you can rest easy that all the black pixels will be gone!
Good luck! Feel free to ask for clarifications.
I cannot test it, being the code incomplete, but from a rough look I have spotted this problem:
sphere_texcoords.push_back((glm::vec2((x + 1.0) / 2.0, (y + 1.0) / 2.0)));
The texture coordinates should not be evaluated from x and y, being:
const float x = cos(theta) * sin(phi);
const float y = sin(theta) * sin(phi);
but from the angles thta-phi, or stacks-slices. this could work better - untested:
sphere_texcoords.push_back(glm::vec2(s,sl));
being already defined:
float s = (float)i / (float) stacks;
float sl = (float)j / (float) slices;
Furthermore in your code you are using the first and the last "slices" of the sphere as the rest... Shouldn't they be treated differently? This seems quite odd to me - but I don't know whether your implementation is just a simpler one, working fine.
Compare with this explanation, for example: http://www.songho.ca/opengl/gl_sphere.html
I am trying to render reflections of objects in my scene onto another model in the same scene. Here is the bit of code in my fragment function that handles specular lighting. (I am doing this in Metal, but just a general explanation of how it's done would be helpful, I can apply it to my application from there).
//Specular Color
float3 reflection = reflect(light.direction, unitNormal);
float specularFactor = pow(saturate(-dot(reflection, unitEye)), vIn.shininess);
float3 specularColor = float3(1.0, 0, 0) * vIn.specularIntensity * specularFactor;
color = color * float4(ambientColor + diffuseColor + specularColor,1);
unitEye is just the unit vector of the eye position (cam position). The line at the bottom is just adding together my 3 colors (ambient, diffuse, and specular). From what I understand, my current specular lighting would be converted into my reflection lighting. For example float3(1,0, 0, 0) would just be whatever color is being reflected onto my object. Here is an image of what i'm trying to accomplish for clarification.
I'm trying to implement specular reflection using values sampled from a grayscale, 1D texture as the multiplicative term.
I've implemented a toggle so I can see the difference between the two, but for some reason when the sampled color is enabled, the areas of the scene with no light display as a light gray, where without the sampling those same areas display as black.
Why is this? Here's the area where I'm setting the fragment color.
if(u_specularRamp == 1)
{
specularAmount = clamp(specularAmount, 0.0, 1.0);
vec2 texCoords = vec2(specularAmount, 0.5);
vec4 sampledColor = texture(u_ramp_tex, texCoords);
specularReflection = vec3(0.3 * sampledColor.x);
}
else
{
specularReflection = vec3(0.3 * specularAmount);
}
FragColor = vec4(specularReflection, 1.0);
u_specularRamp is an integer uniform I'm passing in to toggle the sampled color on and off.
I've fixed the issue, in case anyone runs into this problem, this behaviour was caused by the texture parameter being set to GL_REPEAT. If you want black where there isn't any light, set that parameter to GL_CLAMP_TO_EDGE
I have recently implemented SSAO in my engine(deferred shading), but I am very insecure of how I should combine SSAO with global light and local lights(point light).
Should I do this:
//Global light pass.
vec3 sceneColor = DiffuseBRDF + SpecularBRDF;
float luminance = dot(sceneColor, vec3(0.2126, 0.7152, 0.0722));
sceneColor *= mix(texture(ssaoTexture, texCoord).r, 1.0, luminance);
//Local light pass.
//Use additive blending in this pass, i.e. glBlendFunc(GL_ONE, GL_ONE).
//The final result would be:
vec3 finalColor = sceneColor + pointLight0 + pointLight1 + ... + pointLightN;
or this:
//Global light pass.
vec3 sceneColor = DiffuseBRDF + SpecularBRDF;
//Local light pass.
//Use additive blending in this pass, i.e. glBlendFunc(GL_ONE, GL_ONE).
vec3 finalColor = sceneColor + pointLight0 + pointLight1 + ... + pointLightN;
//Composite pass.
float luminance = dot(finalColor, vec3(0.2126, 0.7152, 0.0722));
finalColor *= mix(texture(ssaoTexture, texCoord).r, 1.0, luminance);
Ambient occlusion is a value that describes how much ambient light can hit a point on the surface. Ambient light is a light that comes from all directions, rather than from a single light source, and usually contains sky lighting, image based lighting, global illumination or a simple flat color. The correct way to apply AO is to multiply it with ambient lighting. Simply put, ambient occlusion is to ambient lighting as shadows are to direct lighting.
So, if your point lights are "atmospheric" lights and are supposed to represent soft ambient lighting without specular highlights, then you should apply the AO to these point lights only, without any luminance scaling. If the point lights are lights with a well defined source and you don't have any significant ambient lighting, then you should be consistent and apply the AO to all lights equally, with luminance scaling to simulate the look produced by correct AO application.
I'm trying to draw a 2 dimensional line the has a smooth gradient between two colors. My application allows me to click and drag, the first point of the line segment is the first click point, the second point of the line follows the mouse cursor position.
I have the line drawing using glDrawArrays(GL_LINES, 0, points.size());, points is a 2 index array of points.
The line draws fine, clicking and dragging to move the line around works, but I'm having explainable behavior with my fragment shader:
uniform vec4 color1; //Color at p1
uniform vec4 color2; //Color at p2
out vec4 fragColor;
void main()
{
//Average the fragment positions
float weight = (gl_PointCoord.s + gl_PointCoord.t) * 0.5f;
//Weight the first and second color
fragColor = (color1 * weight) + (color2 * (1.0f - weight));
}
color1 is red, color2 is green.
As I drag my line around it bounces between entirely red, entirely green, the gradient I desire, or some solid mixture of red and green on every screen redraw.
I suspect I'm using gl_PointCoord incorrectly, but I can't inspect the values as they're in the shader.I tried the following in my shader:
fragColor = (color1 + color2) * 0.5f;
And it gives a stable yellow color, so I have some confidence that the colors are stable between redraws.
Any tips?
gl_PointCoord is only defined for point primitves. Using it with GL_LINES is just undefined behavior and never going to work.
If you want a smooth gradient, you should add a weight attribute to your line vertices and set it to 0 or 1 for start and end points, respectively.