http://gfycat.com/LimpLastingAustraliankelpie
I'm trying to use diffuse directional lighting. One side of my mesh lights up, then the other. Also, if the directional light's direction.z component is 0, there will be no light at all.
Here's the shader code: https://github.com/epicfacecreeper/Demigod/blob/master/src/main/resources/resources/shader/lights.glsl (https://github.com/epicfacecreeper/Demigod/blob/master/src/main/resources/resources/shader/lights.glsl)
Here's my calcNormals method: https://github.com/epicfacecreeper/Demigod/blob/master/src/main/java/net/cyberninjapiggy/demigod/graphics/render/Render.java#L405 (https://github.com/epicfacecreeper/Demigod/blob/master/src/main/java/net/cyberninjapiggy/demigod/graphics/render/Render.java#L405)
Thanks for any help you can give.
I don't see anything immediately wrong. On thing, (you've probably already tried this but) a plane can have two normals - forward facing or backward facing. v1 X v2 gives one, v2 X v1 gives the other. As long as your vertex winding is consistent then you will consistently get the same normal. Just try swapping the first for the second in your normal generation code and see if it starts working.
Just a couple of things in your shader: you negate the lights direction when you pass it to the calcLight() function but then in that function you just negate it again. Probably wouldn't bother in the first place. Also if statements will cause a major hit in shader performance (since graphics cards batch many vertices together and do them all at once, it has to evaluate both sides of the if statement anyway). Generally using one of the built in functions will be better so try using max(diffuseFactor, 0) instead and I'm pretty sure you'll see a noticeable performance boost.
Thanks for the help. I did the optimizations in the shaders, which did give me a small performance boost. Reversing the cross didn't do anything.
Even though it looks a little weird, I'll just assume it works for now. Do you have any idea about the problem with the direction vector's z?
I'm afraid not. I've had a fairly thorough look through all of the code I felt was relevant and I can't see anything that could cause a problem like that. Sorry. I have got a couple more pointers though.
1) In calcNormals(), you work out the face's normal, but instead of just setting the vertex's normal to that, you add it to the preexisting normal. Which should be fine because they get initialized to 0, 0, 0 but if it was me, something like this would worry me that it was wither causing problems I haven't noticed or will cause problems in the future when I forget about it. I don't know if you have a reason for it but I couldn't think of any.
2) Again in calcNormals(), at the end you go through and normalize every single vertices' normal, but they should already be normalized (you normalize them when you work them out). If there is a reason for the above, then this might make sense but otherwise it's just senseless calculations.
3) In your Vertex class, you store the normals as an array, length 4. But normals, to my knowledge, should never be 4 dimensional. You seem to agree with this as the only (non commented) reference to the 4th index is in getNormals() which I didn't see any reference to. As with (1) I would just get rid of it in case something goes wrong with it in the future.