Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

151 Neutral

About Djemon

  • Rank
  1. You're right since the direction should be from the fragment to the light source and people often specify it as the direction from the light source to the fragment (which I did as well), but for that reason I negated the sunDir variable in the C++ code when I pass the lightDir to the shaders so the negation is then not necessery (note that I also tried to negate all my variables in lots of different combinations for debugging without good results )     Yeah, the normal matirx only preserves rotations so still applying it wouldn't destroy the equations, but you're indeed right and since I don't use any rotations it's probably a lot more efficient to not use it at all (I know I won't be using rotations in the future as well).   Yeah, shader is currently just for testing purposes and as soon as everything works I'll be optimizing it all
  2. I do all the lighting calculations in world space, so all tangent vectors and light vectors are in world space. (light vectors are already in world space and tangent vectors are converted to world space by multiplying with the model matrix). Since the water is a static plane, I hardcoded the tangent, bitangent and normal values.   So multiplying it all with a modelview matrix would only switch them to view space, instead of world space; I don't believe that's the issue.   The transpose of the inverse of the upperleft 3x3 matrix of the model matrix gives a so called Normal Matrix that is a version of the model matrix that correctly scales normal vectors (and thus tangent vectors as well) if the model matrix contains non-uniform scales or translations; those now have no effect on the tangent vectors. Correct me if I'm wrong.   They're both in world space so I should be fine then I guess, but then again the results aren't. There's probably something else I'm missing or am simply incorrect in assuming.
  3. I have a flat water surface with a dudv and a normal map attached to it. The dudv map works correct and the normal map is attached correct as well (visualizing the normal map looks like it should). The specular highlights are always showing at the wrong place though as if the light direction is incorrect. The lighting works correct without normal mapping, so I don't believe it is the light direction, but probably something with the tangent space. Since I calculate the tangent space from a static set of vectors I'm confused where it could go wrong. Here in the vertex shader I create the TBN matrix and calculate the corresponding tangent space vectors that I pass to the fragment shader: const vec3 TANGENT = vec3(1.0, 0.0, 0.0); const vec3 NORMAL = vec3(0.0, 1.0, 0.0); const vec3 BITANGENT = vec3(0.0, 0.0, -1.0); out vec3 FragPos; out vec3 TangentFragPos; out vec3 TangentLightDir; out vec3 TangentPlayerPos; void main() { FragPos = vec3(model * vec4(vertex, 1.0)); mat3 mod = mat3(model); mat3 normalMat = transpose(inverse(mat3(model))); [...] vec3 n = normalize(normalMat * NORMAL); vec3 t = normalize(normalMat * TANGENT); vec3 b = normalize(normalMat * BITANGENT); mat3 TBN = transpose(mat3(t, b, n)); TangentFragPos = TBN * FragPos; TangentLightDir = TBN * sun.Position.xyz; TangentPlayerPos = TBN * playerPos; } n the fragment shader I then sample a normal vector from the normal map and do the specular lighting based on the normal map's normal vector: in vec3 FragPos; in vec3 TangentFragPos; in vec3 TangentLightDir; in vec3 TangentPlayerPos; uniform sampler2D normalMap; void main() { [...] vec3 normal = texture(normalMap, vec2(TexCoords * TextureScale) + vec2(Time)).xyz; normal = normalize(normal * 2.0 - 1.0); // Specular lighting vec3 lightDir = normalize(TangentLightDir); viewDir = normalize(TangentPlayerPos - TangentFragPos); vec3 reflectDir = normalize(reflect(lightDir, normal)); float spec = pow(max(dot(viewDir, reflectDir), 0.0), 64); vec3 lighting = sun.Specular * spec * fresnel; color.xyz *= lighting; } Note that I do the lighting in world-space. The lighting works fine without normal mapping, but as soon as I introduce the TBN matrix into the equations the specular highlights are not in the right direction on the water as you can see in the image below: I have no idea what is wrong with the normal mapping implementation and have been debugging for days without finding a solution. The specular light are there, but simply not at the right direction. Because all other lighting works fine with the same light direction I'm quite sure that isn't the problem. I'll post it here for completeness' sake though: sunDir.x = -0.75; sunDir.y = sin(dayTime); sunDir.z = cos(dayTime); sunDir = glm::normalize(sunDir); // = (-0.6, 0.76, 0.25) //sunPosition = sunDir * sunDistance; // sunDistance = 250.0f Sun.Position = glm::normalize(glm::vec4(-sunDir, 0.0)); // = (0.6, -0.76, -0.25) I'm completely stuck and any help is much appreciated
  4. Hmm that's a nice idea indeed, I think I'm going to try that.   I also looked up some extra resources last night and found another possible solution from here: http://codeincomplete.com/posts/2011/6/12/collision_detection_in_breakout/   Basically, I now do circle-AABB collision which I've coded out as follows: GLboolean CheckCollision(Object &one, Object &two) // Circle - AABB collision { glm::vec2 center(one.Position + one.Radius); glm::vec2 aabb_half_extents(two.Size.x / 2, two.Size.y / 2); glm::vec2 aabb_center(two.Position.x + aabb_half_extents.x, two.Position.y + aabb_half_extents.y); glm::vec2 difference = center - aabb_center; glm::vec2 clamped = glm::clamp(difference, -aabb_half_extents, aabb_half_extents); glm::vec2 closest = aabb_center + clamped; difference = center - closest; return glm::length(difference) <= one.Radius; } Which seems to work (although collisions tend to happen a bit before actually touching the AABBs). Would it then be valid to take this difference vector and determine if it's a right/left pointing vector or a north/south pointing vector (by taking the dot product of the vector with n/s/e/w normal vectors and taking the vector with largest result)? This would give me a solid indication of what side it hit, wouldn't it?
  5. I'm working on a breakout clone and I can't get my head around the collision resolution part. I basically check for AABB-AABB collision between the ball and each object (collision detection works as it should), but when a collision is found, I need to respond.   My approach is to move the ball to its original position (subtract velocity) and then invert one of the velocity axes based on where the intersection occured. In normal breakout, if the ball hits either the top or the bottom edge, the velocity.y is reversed. If it hits the left or right edge, the velocity.x is reversed. However, I have no idea how to figure out if the ball hit a top/bottom edge or a right/left edge so I don't know which part of the velocity vector to reverse.   This is the function I use to check for collision between two objects (using AABB-AABB collision detection): GLboolean CheckCollision(Object &one, Object &two) // AABB - AABB collision { return one.Position.x + one.Size.x >= two.Position.x && two.Position.x + two.Size.x >= one.Position.x && one.Position.y + one.Size.y >= two.Position.y && two.Position.y + two.Size.y >= one.Position.y; } Within the game logic I then check for collision as follows: for (Object &box : boxes) { if (!box.Destroyed) { if (CheckCollision(*ball, box)) { // ... How to properly respond? if (!box.IsSolid) box.Destroyed = true; } } } I believe that as soon as I could properly figure out which axes to reverse the velocity on, the collision detection should be sufficient. The ball will never go so fast it skips over boxes and I'd rather keep things simple if possible. Is there a simple approach I'm just missing or do I really have to go all-out with techniques like SAT?
  • 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!