Flickering issue with lighting based on direction I'm facing

@KonradZuse said: I understand, but how is it calculated in the texture? There is also a "normal texture" but when I removed the normal it still showed the correct areas as shaded, just "not as shaded" if that makes sense. As in the radius of the shade was less, but not by much it seemed.

Should all diffusemap textures also come with a normal map texture?

I’m not that familiar with lightning and all these maps, so excuse my level of understanding of them.

It seems like each map it there to help the main texture accomplish something… We basically creates these additional maps around the main one? i.e., bump map we would create the bumps of the texture based on the texture itself in most cases? Shininess, etc? I’m assuming you could use additonal “bumpy” or “shiny” surfaces, they just might not look that good with your texture?

Thanks again everyone!

Vertex normals and normal maps are not the same thing.

For lighting to work, it has to know the direction of every point that is rendered. This can be done by interpolating normals between vertexes or by looking up normals from a normal map (which still requires an interpolated vertex normal for proper direction).

When I was first starting out in 3D graphics, we did not have the wonderful resource that is google. Some of these articles look decent and the images are illustrative:
https://www.google.com/search?q=vertex+normal
https://www.google.com/search?q=surface+normal

Normals and normal maps are different things. Normals maps uses normals but not the other way around.
Your mesh needs a normal vector for each vertex if you want lighting to work properly. A normal vector tells the lighting shader how light should reflect at a given vertex.

A normal map is a trick to tell the lighting material how light should reflect at each pixel. Making it easy to fake some bumpiness in a plane surface for example. In order for the normal map to work properly your also need the normal vector of each vertex. i won’t go that much into the detail on how they work though.

You don’t need a normal map for lighting to work properly, its just to add some details to your mesh. however you need vertices’ normals.

I hope that makes sense.

@nehon said: Normals and normal maps are different things. Normals maps uses normals but not the other way around. Your mesh needs a normal vector for each vertex if you want lighting to work properly. A normal vector tells the lighting shader how light should reflect at a given vertex.

A normal map is a trick to tell the lighting material how light should reflect at each pixel. Making it easy to fake some bumpiness in a plane surface for example. In order for the normal map to work properly your also need the normal vector of each vertex. i won’t go that much into the detail on how they work though.

You don’t need a normal map for lighting to work properly, its just to add some details to your mesh. however you need vertices’ normals.

I hope that makes sense.

Thanks, yeah I was just asking some additonal questions to gain more knowledge, sorry to ask them in here if that was confusing.

Good to know about the relation between the 2 “normals.”

I will check out google and some other things, I also have a book here that I am going to look at called “The OpenGL Super Bible” and I found a few pages on normals. sometimes it gives me some good help, but it’s 10 years old or so, so I would assume there is a ton more out there/somethings might have changed.

Hopefully it isn’t that difficult what I want to do…

@KonradZuse said: ...but it's 10 years old or so, so I would assume there is a ton more out there/somethings might have changed.

Some topics (such as normals) are nearly as old as computer graphics itself…

@pspeed said: Some topics (such as normals) are nearly as old as computer graphics itself...

:slight_smile:

There is is a lot of things that wont change, but in those 10 years there’s probably been a lot of improvements, but Open GL as a whole seems to be pretty set as a library.

@KonradZuse said: :)

There is is a lot of things that wont change, but in those 10 years there’s probably been a lot of improvements, but Open GL as a whole seems to be pretty set as a library.

If your graphics pipeline is based on rasterizing triangles then there are certain constants to the universe. Vertex normals are one of those.

An interesting fact, (maybe) the only thing my marching cubes terrain demo has in its mesh are vertex position and vertex normal. Everything else could be trivially calculated in the shader except those two things.

Gotcha pspeed, I don’t think I need to use a shader myself.


EDIT: Okay so I fixed it kinda… I figured out how to get a normal vector and I noticed that vector1.cross(vector2) is not the same as vector2.cross(vector1).

So there is a portion of my wall that is protruding outwards and I’m assuming it’s a neg vector? I’m going to try and do an abs value and see how it goes :).

Thanks again for all the help!

@KonradZuse said: Gotcha pspeed, I don't think I need to use a shader myself.

EDIT: Okay so I fixed it kinda… I figured out how to get a normal vector and I noticed that vector1.cross(vector2) is not the same as vector2.cross(vector1).

So there is a portion of my wall that is protruding outwards and I’m assuming it’s a neg vector? I’m going to try and do an abs value and see how it goes :).

Thanks again for all the help!

rightHand.cross(leftHand) = head direction
leftHand.cross(rightHand) = body direction
…at least I think so (I sometimes get them backwards).

At any rate, they will of course produce different results because if you swap them then the surface is pointing the other way.

Edit: yep, just double checked it. And in a triangle, v0, v1, v2… v0 is your body, v1 is your right hand, and v2 is your left hand… since OGL is default counter clockwise winding.

@pspeed said: rightHand.cross(leftHand) = head direction leftHand.cross(rightHand) = body direction ...at least I think so (I sometimes get them backwards).

At any rate, they will of course produce different results because if you swap them then the surface is pointing the other way.

Edit: yep, just double checked it. And in a triangle, v0, v1, v2… v0 is your body, v1 is your right hand, and v2 is your left hand… since OGL is default counter clockwise winding.

Not sure what the left hand, right hand, head, body is :P.

I’m not sure if that was an answer to my Q, but since 2 of my faces are touching the surface that is facing outward, as well as both touching another side that’s inward, how do I get the outward side to get a shadow as well, without negating the shadows produced inward?

EDIT: I also notice that with SSAO enabled my FPS drops from 60 to 20-30. If I add AA it drops to about 11… I don’t thin I need AA atm(I don’t notice it) but with the 2 samples it was okay, but 4 was awful.

Is there anything I can do to make the SSAO not rape my fps as much? It makes everything look SOOOO MUCH better, but I can see how much computational power it needs…

I’m scared that for a bigger scene it’s going to get really bad…

@KonradZuse said: Not sure what the left hand, right hand, head, body is :P.

It’s a way of remember which way a cross product will go. a.cross(b) is different than b.cross(a).

@KonradZuse said: I'm not sure if that was an answer to my Q, but since 2 of my faces are touching the surface that is facing outward, as well as both touching another side that's inward, how do I get the outward side to get a shadow as well, without negating the shadows produced inward?

EDIT: I also notice that with SSAO enabled my FPS drops from 60 to 20-30. If I add AA it drops to about 11… I don’t thin I need AA atm(I don’t notice it) but with the 2 samples it was okay, but 4 was awful.

Is there anything I can do to make the SSAO not rape my fps as much? It makes everything look SOOOO MUCH better, but I can see how much computational power it needs…

I’m scared that for a bigger scene it’s going to get really bad…

SSAO is expensive. It’s better if you can simulate it with light maps or something.

@KonradZuse said: I'm not sure if that was an answer to my Q, but since 2 of my faces are touching the surface that is facing outward, as well as both touching another side that's inward, how do I get the outward side to get a shadow as well, without negating the shadows produced inward?

As to this, I don’t know that I understand the question.

@pspeed said: It's a way of remember which way a cross product will go. a.cross(b) is different than b.cross(a).

SSAO is expensive. It’s better if you can simulate it with light maps or something.

Yeah… it makes everything look great though :D. I was originally going to use light and shadow on everything, but not too sure how much of that I would have to use and how much computational power that takes.

Most of my scene is static anyways, so the scene doesn’t look that bad even at 10-12 fps.

I could always have an option, like all games, to turn it on or off, right…?

The only thing I really use the SSAO for is the cornes and edges of my walls and such. Some of my objects in my scene look nice with it as well, but I figure if I have just the walls that would suffice mostly…

Maybe even a simple shader(Haven’t really looked at shaders yet, so not sure on there complete ability but it seems it could do what I need).

As for my question I guess I need to take another Webcam video for you :D.

@KonradZuse said: Yeah... it makes everything look great though :D. I was originally going to use light and shadow on everything, but not too sure how much of that I would have to use and how much computational power that takes.

Most of my scene is static anyways, so the scene doesn’t look that bad even at 10-12 fps.

I could always have an option, like all games, to turn it on or off, right…?

The only thing I really use the SSAO for is the cornes and edges of my walls and such. Some of my objects in my scene look nice with it as well, but I figure if I have just the walls that would suffice mostly…

Maybe even a simple shader(Haven’t really looked at shaders yet, so not sure on there complete ability but it seems it could do what I need).

As for my question I guess I need to take another Webcam video for you :D.

If you look at the game I made called Monkey Trap… it has SSAO like effects without actual SSAO. It is possible to simulate the effect but you have to be clever in your geometry and maybe your shader.

@pspeed said: If you look at the game I made called Monkey Trap... it has SSAO like effects without actual SSAO. It is possible to simulate the effect but you have to be clever in your geometry and maybe your shader.

It might be something to look forward to in a next release, I think for now this is good enough, and if it’s too slow, I’ll just let people turn it off.

Only certain objects need it (Like my wall) so something similar with light/shadow might work too, but Shaders seem to be where people go for things like this so that is something I will have to look into :).

Thanks again for the help, I will show off what I was talking about before and hopefully it can be fixed…

Oh and… Achievement Unlocked :P.

@KonradZuse said: It might be something to look forward to in a next release, I think for now this is good enough, and if it's too slow, I'll just let people turn it off.

Only certain objects need it (Like my wall) so something similar with light/shadow might work too, but Shaders seem to be where people go for things like this so that is something I will have to look into :).

Thanks again for the help, I will show off what I was talking about before and hopefully it can be fixed…

Oh and… Achievement Unlocked :P.

Heheh.

In my case, I was able to just render my geometry twice with two different textures. So the AO effect was essentially free. It doesn’t always work out so nicely, though.