Lighting computation viewing direction

Question

This is something that's really cooking my noodle. When I'm computing the light response for a material in my fragment shader, I'm using the standard 3 normalized vectors, in eye space: fragment normal, light direction, eye direction.

However, because the 3 vectors are in eye space, I've seen the eye direction represented as the following, because the camera is looking down -z:

vec3(0, 0, 1)

While the light direction is:

normalized(light_eyespace_position - fragment_eyespace_position)

This makes sense at first glance, but the more I think about it, I'm trying to figure out why the eye direction isn't computed similarly to the lighting direction:

normalized(-fragment_eyespace_position)

In other words, why does the vector from the light to the surface dependent on fragment position, but the vector from the camera to the surface is independent on the fragment?

The only thing I can work out is that using vec3(0, 0, 1) is correct only for ortho cameras, while normalized(-fragment_eyespace_position) is correct for perspective cameras. Is this correct? Can anyone shed some light on this?

Answer 1

why does the vector from the light to the surface dependent on fragment position, but the vector from the camera to the surface is independent on the fragment?

The point is, because of the lighting equation. What you need is the vector from the light to the vertex, in other words the light direction relative to the vertex position. This is needed in order to take the dot product between the normal vector and the L vector. This is called the diffuse term and is calculated

float diffuseTerm = (N.L); Where N is the normal vector. L is the light direction. In case of directional light (infinitly far) L will be constant for all the vertices. If the light is not L will be calculated relative to each vertex.

Regarding the camera vector you are in the eye space, which means the camera position is (0,0,0) you can actually think of this

normalized(-fragment_eyespace_position)

As this

normalized( (0,0,0)-fragment_eyespace_position)

Because in eye space the camera is actually (0,0,0)