Question

I’ve made a GLSL shader for doing per-pixel blinn phong lighting on a scene, and I’ve had some issues w/ the light cast on the scene. Each light seems to have a very hard boundary on its effect ( in attached screenshot, you can see the boundary of the light on the bottom plane – the light (whose world position is equivalent to the hanging black spheres in the scene) is hanging over the plane and ferrari model, but for some reason only casts light appropriately back /towards/ the camera, not forward, away from the camera.

I feel like I’m making some mistake / lack some understanding in how the eye direction affects the blinn phong lighting model. Have I messed up my calculations, or do I simply not understand how this particular lighting model is supposed to work?

My shader code is here: https://gist.github.com/1040417

Screenshot of effect:

Answer 1

Your computation of the half vector seems to be wrong. The half vector is the vector between light direction and view direction (direction to camera), which is also the part where the eye direction affects the lighting. But since you are computing your lighting in world space and not in view space, you cannot just use the view space position as eye direction, instead you need the position of the viewer/camera in world space as input to the shader. Oh, and don’t forget to normalize the light vector before computing the half vector (and also interpolate the normalized light vector). So substituting

halfVectors[i] = normalize(lights.allLights[i].position + lightDirections[i]);

with

uniform vec3 viewerPos;
...
vec3 eyeDirection = normalize(viewerPos - worldPosition.xyz);
...
lightDirections[i] /= dist;
halfVectors[i] = normalize(eyeDirection + lightDirections[i]);

Should do the trick. The eye direction doesn’t need to be a varying anymore, as its not needed in the fragment shader (its implicitly saved in the half vector).

I’m not sure if interpolating the half vector gives exactly the same results as interpolating the eye direction and computing the half vector in the fragment shader (this way you would also spare the many varyings). But at least it should work now.

EDIT: Same with the attenuation factor. As it’s nonlinear in the distance to the light, you might not get exactly the same results as when computing it per fragment. But it might be tolerable, depnding on the tessellation quality.