3D Lighting 102

Background

Local Models versus Global Models

Light is emitted from sources in an environment, and that light bounces all around the environment, generally illuminating all surfaces to some extent. In addition, some objects in an environment have surface and/or material properties that allow us to see reflections of other objects and/or see refracted images of objects behind them.

The effects mentioned above – multiple light reflections, reflected images of objects on the surfaces of others, and the ability to see through translucent objects – are generally called global lighting effects. In pipelined graphics engine architectures such as that present in OpenGL, such global effects are at best difficult to model in a general way. Various global approaches (e.g., ray tracing and radiosity) are typically used to simulate these effects. We will restrict ourselves to the study of local lighting models which explicitly do not attempt to simulate shadows (which are a side effect of how light scatters in an environment), reflections, and refraction.

Empirical Models versus Physically-Based Models

Local models simulate the physics of light-surface interaction. A large number of local lighting models have been developed over the years, all based on geometric considerations along with various loose approximations to the underlying physics. The classical model used in pipelined graphics architectures (and in many ray tracers) is based on the Phong local lighting model. Other models that attempt to simulate more precisely the actual physics have been developed. While capable of producing extremely realistic results (see the figure on the right), they are considerably more computationally intensive and require a not insignificant amount of "tuning". Increasing GPU performance in recent years coupled with the fact that the shader stages are fully programmable makes it more reasonable to implement such advanced reflection models. Nevertheless, we will study only the classical Phong model since it is sufficiently complex for our purposes, easier to utilize, and produces perfectly good results for our purposes.

Electromagnetic Radiation and Color

We can understand one aspect of the difference between empirical and physically-based models by reviewing something of the physics of electromagnetic radiation and color. Physical models attempt to sample a large number of reflected wavelengths; empirical models such as the Phong model we are about to study sample at just three wavelengths, corresponding roughly to blue, green, and red, respectively.

Extensions From Lighting Model 101

There will be an arbitrary number of light sources. (However because of constraints in GLSL and our use of uniform arrays, we will need to enforce at compile time a maximum number of sources.)
In 101: 1 source
For each light source, we will store and send to the fragment shader via uniform variables:
- 4D position/direction, L_{i, xyzw} = (x_i, y_i, z_i, w_i):
  - If w_i=0, it will be a directional source (e.g., sun, moon). The direction towards the source will be the vector (x_i, y_i, z_i) for all points in the scene. No light source attenuation is applied.
  - if w_i=1, it will be a positional source placed in the scene at location (x_i, y_i, z_i). The direction towards the light source must be computed for each point in the scene at which we wish to evaluate the lighting model. Light source attenuation must also be computed for each point in the scene.
  In 101: w_i=0
- RGB strength, L_{i, rgb} = (r_i, g_i, b_i)
  In 101: (1, 1, 1)
- Whether the source is currently enabled (i.e., "turned on"). This can be changed at any time – even during a display callback. (We will talk about why we might want to enable/disable light sources as we discuss various lighting techniques as well as limitations of this model.)
  In 101: always enabled
For each light source, we will store, but not send to the fragment shader:
- Whether the position/direction is defined in MC or EC. (See discussion below.)
  In 101: EC
The lighting model in the fragment shader will assume the lights are defined in EC just like in the 101 model. The difference is that we will apply the current mc_ec matrix to any light source geometry defined in MC before sending it to the uniform in the fragment shader.
The effective light source strength at a given point in a scene of a positional light source (i.e., one that is placed in the scene at some (x, y, z, w) where w=1) falls off with the square of the distance from the source to the point. We will take this attenuation into account.
In 101: attenuation was ignored

Hints for Modeling Your Lighting Environment

Creating a good lighting environment is required in order to get satisfying rendered results. It is also harder than you might think.

Ambient lighting
- Only need to specify (r, g, b) strength –– 0 ≤ c ≤ 1, c ∈ {r, g, b}
  The value for c should generally be small, probably something like 0.1 ≤ c ≤ 0.2. It is also usually the same for all three channels; i.e., r = g = b = c.

Actual light sources

Need to specify (r, g, b) strength –– 0 ≤ c ≤ 1, c ∈ {r, g, b}
The values used for c here indicate light source strength per color channel. They will be different for each of the (r, g, b) channels if you want to simulate colored light sources. Care must be taken with multiple light sources to try to avoid overflow of a color channel. An important part of good scene design is iterative adjustment of light source strengths to avoid this.
The geometric specification must define (i) the position of local light sources such as lamps, or (ii) the direction vector to any assumed far-off sources such as the sun or the moon.
We need to specify how the effects of local positional light sources (not directional) are attenuated with distance. The effective strength of "real" sources falls off with the square of the distance from the source to the visible surface point, and realism in many scenes is greatly improved when this effect is simulated in some way in your scenes. Due to the empirical nature of the Phong model, a strict inverse square law often leads to overly dark scenes. One common approach is to use an attenuation term of the following general form: 1.0/(c₀ + c₁*d + c₂*d²), where d is the distance between the positional light source and the visible surface point. Typically only one of c₁ or c₂ is non-zero. This allows you to either simulate an inverse distance or inverse distance squared attenuation, depending on what works best in your scene. You may even find that different settings of c_i are ideal for different light sources in your scene.
Specifying c₀>0 protects you from cases where d is zero or close to it. Using c₀=1, for example, is very common since that means in the limit as d→0, the attenuation approaches 1 (i.e., no attenuation).

We compute d in eye coordinates during the course of evaluating the lighting model. Why is this an issue? Suppose I compute dInEC=2. If the overall scene dimensions are, say, 20x20x20, I wouldn't want the light source to be attenuated nearly as much as I would if the scene dimensions were, say, 2x2x2. To as great an extent as possible, we would like to make our lighting model independent of the dimensions of any given scene. LDS coordinates provide such a system. If you review the projection matrices we derived, it should be clear that we can get a distance measure in LDS (and hence one that works regardless of overall scene dimensions) by computing and using dInLDS = ec_lds[0][0]*dInEC. However, most distances will be less than one, which would potentially impact the effectiveness of our attentuation. We could address that by essentially scaling so that distance becomes a percentage: dForAttenuation = ec_lds[0][0]*dInEC*100.0. Regardless of which d measure you use, tuning of the c_i parameters will be needed.

Summarizing the geometric portion of light source specifications:

	Directional (e.g., sun, moon)	Positional (e.g.,lamps, ceiling lights)	Example Use
Defined in Eye Coordinates?	(x, y, z, 0)	(x, y, z, 1) & attenuation specification	Viewer holding a flashlight
Defined in Model Coordinates?	(x, y, z, 0)	(x, y, z, 1) & attenuation specification	Almost everything else: sun, moon, lamp in a room, street light, …

When modeling scenes from our everyday experience, we usually define light sources in the same coordinate system as the rest of our scene: model coordinates. The position of a lamp in a room is placed with respect to a table in the room. Even directions to sources like the sun and the moon should be specified in MC to avoid unrealistic effects during dynamic rotations.

Reflection Geometry

The basic geometry of reflection assumed by the Phong Empirical Local Lighting Model

Determining the and Unit Vectors

Get EC Representations of the Light Source Positions/Directions

If the i^th light source is defined in MC, the first step is to transform it to EC using the current mc_ec matrix. This can be done on the CPU before sending the data down, or on the GPU in the fragment shader.

Vector towards the i^th light source,

There are two common ways to determine the unit vector towards the light source:

"Directional" light source (e.g., the sun or the moon): The light source is sufficiently far from the geometry of the scene that all points on the surface can use the same unit light source vector with negligible approximation error:
"Local" light source (e.g., lamp, spotlight, etc.): The light source is sufficiently close to objects in the scene that the distances between the source and various objects differ considerably: