Normal Map Shader Lights

Started by AGP, February 08, 2012, 03:18:36 AM

Previous topic - Next topic

AGP

About the lighting: since both a normal map and the wiki's light are blue, one can mistake one for the other. Choosing any other color for the light would be more appropriate.

And I mean that it doesn't curve the normals in the way that it's supposed to. I'll try messing with invRadius and report back, thanks.

EgonOlsen


AGP

Distort them, then. It doesn't do what it's supposed to.

Funny thing, now, is that when I used the little framework from the wiki with the new shader you gave me I'm back to the original issue of seeing the appropriate distortion but having the light one work at certain angles. Is there anything we could add to the framework to address this?

EgonOlsen

#18
It has nothing to do with using GLSLShader or the code from the wiki. They are very similar except that GLSLShader does better error handling (EDIT: And that it doesn't support injection of tangent vectors, which the shader code that i had posted needs). I rather guess that this is a case of false expectations of what it is supposed to do. The whole magic is in the shader. It has nothing to do with how you apply it as long as it gets applied (which obviously happens). It does what it's supposed to do...you have the code, you can change it to anything you like. What you get from the wiki is a basic normal mapping shader. If that's not what you want or the results are not what you expect them to be, you always have the option to tweak the shader in any way you like.

Maybe you can illustrate your issue with a screen shot...?

AGP

Fine, but I'm telling you: it's working now (with the wiki's little framework and the new shader you gave me), but with the same lighting angle issue as originally. Odd, sure, but untrue it isn't. PrintScreen doesn't work with fullscreen OpenGL, but I guess I can still grab a screenshot from the FrameBuffer, right? If so, I'll post one.

EgonOlsen

As i've edited in my post above: That shader framework can't work correctly with that shader code because it doesn't know what to do with the shaders tangent-uniform...all tangent vectors will be (0,0,0) in that case. Scrap that wiki-framework and use GLSLShader instead. Just don't bother with it...it was meant as an example of how to do it on your own if you absolutely have too...but actually, you don't.

AGP

OK, you do realize that your edit contradicts the rest of your post, right? Might as well edit more.

But here's a follow-up: how am I using GLSLShader wrong if the other one is working (even if only at exact angles)?

EgonOlsen

It contradicts nothing. It says that they are similar except for error logging and tangent vectors. It doesn't say that they are equal. And no, the wiki-code combined with the posted shader code DOESN'T work. It can't, because it doesn't inject the tangent vectors. You might see something, but that's all bogus...not what the shader is supposed to do. Please use the GLSLShader-class instead! If it "doesn't work" (which is still too vague to be of any value), then it's better to find out what the problem is instead of using some code that will definitely never create correct results.
As said, it's all in the shader. The shader does what it's told to do. And this particular shader is actually pretty simple. Just make sure that invRadius is small if your light source is farer away than it was in the examples and make sure that the tangents have been calculated (do it yourself by calling the method to be sure).

AGP

I suggested the wiki framework was incomplete and asked about what to add to it for the lights. You countered with "it's a case of false expectations." Anyway, I see no way to change invRadius with GLSLShader (I had simply divided the result of locRadius by some integer on the wiki framework but I don't get to do this with GLSLShader.

EgonOlsen

Just do


shader.setStaticUniform("invRadius", 0.00000001f); // or whatever value...for light sources far away, it should be small.

AGP

Thanks a lot, I'll report back.