CS580
Lighting and Shading Implementation and HW4
Ulrich Neumann
CS580
Computer Graphics Rendering
Review: the shading Eq
C = (Ks L [Ie (RE)s] )
+ (Kd L [Ie (NL)])
+ (Ka Ia)
E
Examine the Vectors
L is the direction to an infinitely-far point-light source
constant in whole scene and specified by the application
E is constant and set by camera view direction
Z-axis of camera is a known direction in image space (0,0,-1)
also known in world space (camera position and look-at point)
Constant E approximates far away camera with narrow FOV
A camera close to the scene requires E computed for each model vertex or pixel shading calculation (not for HW)
N is specified at triangle vertices – given in model space
R must be computed for each lighting calculation (at a point)
R = 2(NL)N – L (next slide)
L, E, N, R must be transformed to the same space for shading Eq evaluation: model, world, or image space
assume any of these spaces for now…
E
Compute Reflection Ray
R = 2(NL)N – L (L,N,R are unit-length)
R
N
L
θ
θ
2(NL)N
-L
(NL)N
Choosing a Shading Space
Cosines and dot products must be computed in an affine space – perspective warps geometry
We need to have all the (L, E, R, N) vectors in some affine (pre-perspective) space
Any affine space will do, and there are a few sensible/intuitive options:
Image space is “close” to screen space and it’s convenient to think about the light being attached to the camera
everything has to get to image space eventually, on the way to perspective and screen space – suggest you use image space for HW4
World space allows light to be specified in relation to the world
useful for modeling a room with lights or sunlight
Model space is also a reasonable choice since Normal vectors are already in that space
This is most efficient, but it requires we have inverse transformations for bringing L, E into each model’s space – must be recomputed anytime there is push/pop of model transforms
Image Space Lighting (ISL)
Shading computed with vectors in image space
Specify lights in image space (attached to camera)
E the eye-vector is known in image space (0,0,-1)
Normals are always given in model space
Norms are transformed by a stack Xn that includes all the model to world and world to image transformations Xn = Xim
Recall the geometry stack in HW3 (Xg) goes all the way from model to screen space Xg = Xsm
Two possibilities for ISL
1) Transform N to screen using Xg and then back to image space
messy since we have screen scale, d, and Zmax scaling and translations to undo
2) Transform norms to image space with separate stack
Xn used only for N
A simple & clear calculation – no inverses
No scaling or translations allowed in Xn
Make sure Xn is a unitary rotation matrix so the resulting N remains normalized
Translations of Vectors
Direction vector (Normal) is represented by head coord of vector whose tail is implicitly at the origin
Translate V by T =
Translating V alters the direction of the vector
Translation is not a proper operation on a direction vector
Do not allow translations in Xn
Remove translations from all matrices pushed on Xn
Put zeros in 3 upper elements of right column prior to any matrix push
V = x,y,z
0,0,0
V’
0,0,0
V
Unitary Rotations for Normals
To ensure Xn is a unitary rotation, pre-process each matrix before it is pushed onto Xn
Use knowledge of unitary R matrix properties
Length of any row/col vector must = 1
Compute a scale factor and apply to all elements in the matrix
use any row/col and compute scale factor
K = (a2 + b2 + c2)1/2
divide all elements of 3×3 R : R’ = R/K
R’ is normalized (unitary) rotation matrix
Push R’ onto Xn
Xn Transform Stack for ISL
Xn has the same structure as used for Xg
Do all push/pop operations on both stacks
Except: push Xsp and Xpi as identity [I] or skip them for Xn
Xn must only contain pure rotations (unitary)
no translation and no scale
Normals passed through Xn will remain unit length for dot products calculated in shading equation
Xn contains only unitary rotations so the transformed N-vectors remain normalized
recommended for HW4
Cases that come up in shading (1)
You need to deal with these in the HW
Test the illumination and the viewing direction relative to the normal of a surface
Sign of NL and NE
Both positive : compute lighting model
Both negative : flip normal and compute
lighting model on backside of surface
Each has different sign : light and eye
are on opposite sides of the surface
so the light contributes zero – skip it
Flipped N
N
L
E
N
L
E
N
L
E
Cases that come up in shading (2)
RE calculations must be clamped to zero to maintain in [0, 1] bounded range
RE may be negative for front or back surface illuminations (see below)
Check for color overflow from multiple lights
Overflow causes black holes
Occurs when converting float values >1.0 to 12-bit GzIntensity values written to the frame buffer
R
N
L
E
Shading Calculation Logistics
Application specifies lights (Ie and Ia) and material properties (Ka, Kd, Ks, s) before sending any triangles for rasterization
Renderer uses these values until they are overwritten
The geometry (L,E,R,N vectors) and material properties are all the elements needed to compute the shading equation
however – we only know R and N at the model vertices where N is specified
Vertex and Face Normals
What are the “normals” to the surface?
Each polygonal face has a normal
N = (b – a) x (c – b)
Polygon mesh only approximates the curved surfaces we are trying to model
approximate actual surface normals
sample surface normal at vertices
compute smooth variation of normal
over mesh face between vertices
a
b
c
N
*
Vertex Normals
Vertex normals are specified at each vertex – even when the vertex position is shared by adjacent triangles
Two options when adjacent-faces share the same vertex
Same normal at adjacent-face vertex for smooth shading
Unique normal at adjacent-face vertex for sharp edges
Shared normals at verts mean seamless shading transition between faces
Unique normals at verts mean sharp transition between shading on faces
Shared normals at verts means smooth face-shading transitions
Compute Color at All Pixels
All terms of shading eq are known (and fixed) for the entire triangle, except for Normals
Norms are specified per-vertex – allow them to vary within the triangle to approximate curvature of smooth surface
The shading mode flag describes how to compute the color of pixels inside the triangle based on the known vertex Normals
The flag selects interpolation of vertex color or normals
The shading mode determines where in the image or on the model we compute the lighting equation
per face – flat shading (based on one normal per triangle)
per vertex – interpolate vertex colors (Gouraud Shading)
per pixel – interpolate normals (Phong Shading)
Shading Modes
Shading Mode = Flat (Constant – per face)
Use one vertex normal (first vertex in triangle structure) to compute a flat (constant) color for whole triangle
Shading Mode = Color interpolation (Gouraud – per vertex)
Shading equation is evaluated only at verts
Color of shaded verts is interpolated to each tri surface pixel
Fast, but specular highlights are undersampled (aliased)
Shading Mode = Normal interpolation (Phong – per pixel)
Interpolate and normalize N at each pixel and compute full shading equation at each pixel
Expensive computation, but better sampling – minimizes aliasing
Highlights are more accurate and consistent under motion or view changes
Gouraud Interpolation Problems
Misses some highlights
Stretches (blurs) highlights
Shading is not a linear function…
eye
Shading of yellow surface
will be constant!
Highlight should be in the middle – but isn’t computed
a worst case…
light
The same color is computed at each vertex and interpolated as constant across entire face
N
N
Phong Interpolation
Interpolate the Normals, then compute colors
Interpolation is by x,y,z components of vector
Note: length of interpolated N vector is reduced
It needs to be normalized and this requires square-root calculation
light
eye
Highlight occurs in the center of the face where specular reflection reaches the eye
HW 4 Interpolation Modes
App sets GZ_INTERPOLATE flag
GZ_FLAT : flat shading (default – Shade using first vertex normal)
GZ_COLOR : vertex shading and color interpolation (Gouraud)
GZ_NORMALS : normal interpolation and pixel shading (Phong)
App sends triangle
Transform norms with Xn (transform all of the norms)
If GZ_FLAT :
Compute color based on 1st vertex normal
As in HW3 – use the same color for all triangle pixels
Else :
If GZ_COLOR :
compute color at verts, rasterize while interpolating RGB vertex colors
If GZ_NORMALS :
rasterize while interpolating Normals and compute color at each pixel
NOTE: MAKE SURE YOU “NORMALIZE” THE LENGTH OF THE INTERPOLATED NORMAL VECTOR AT EACH PIXEL BEFORE YOU EVALUATE THE SHADING EQUATION
Interpolation Examples
Image courtesy of Watt & Watt, Advanced Animation and Rendering Techniques
More Interpolation Examples
HW4 Details
Add a shader to your Gz rendering library to support Flat-shading, Gouraud shading, and Phong shading
The shading mode is set by selected an interpolation mode
The GZ_INTERPOLATE flag selects between flat shading (no interpolation), vertex color interpolation, and normal interpolation.
You will support two light types GZ_AMBIENT_LIGHT and a directional light specified by GZ_DIRECTIONAL_LIGHT
Both are of type GzLight (in Gz.h)
The direction vector is only valid for directional lights and it is the vector from the scene to the light in image-space
Ambient light direction has no meaning – so it is ignored
HW4 Details (2)
Only one ambient light is supported, but multiple directional lights are possible (up to 10)
Lights are specified by a call to GzPutAttribute()
GzPutAttribute() must accept the following tokens/values:
GZ_RGB_COLOR GzColor default flat-shade color
GZ_INTERPOLATE int shader interpolation mode
GZ_DIRECTIONAL_LIGHT GzLight
GZ_AMBIENT_LIGHT GzLight (ignore direction)
GZ_AMBIENT_COEFFICIENT GzColor Ka reflectance
GZ_DIFFUSE_COEFFICIENT GzColor Kd reflectance
GZ_SPECULAR_COEFFICIENT GzColor Ks coef’s
GZ_DISTRIBUTION_COEFFICIENT float spec power
HW4 Details (3)
Values for GZ_INTERPOLATE
GZ_FLAT 0 /* flat shading uses first vertex normal */
GZ_COLOR 1 /* interpolate vertex color */
GZ_NORMALS 2 /* interpolate normals */
Gz.h defines a GzLight type since the application has to set up lights
*** Note that you can use your existing LEE or DDA interpolation methods for color or normal interpolation
No need to invent a new method
HW4 Shading
Camera set
Color interpolation
Normal interpolation
Default camera
HW4 Flat
Shading
Camera set
Default camera
HW4 teapot
Modeling errors in the teapot normals
Normals have inconsistent signs
line 2593
triangle
0.000281 3.000000 0.000844
0.000000 1.000000 0.000000
0.250000 0.000000
0.000750 3.000000 0.000750
0.000000 -1.000000 0.000000
0.500000 0.000000
0.242477 2.950782 0.242477
0.423818 0.800473 0.423818
0.500000 0.250000
similar issues at lines 2625, 2629,
2721, 2753, 2849, 2881, 2977, 3009
More teapots