CS代考计算机代写 CS580

CS580

Lighting and Shading Implementation and HW4
Ulrich Neumann
CS580
Computer Graphics Rendering

Review: the shading Eq
C = (Ks L [Ie (RE)s] )
+ (Kd L [Ie (NL)])
+ (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(NL)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(NL)N – L (L,N,R are unit-length)
R
N
L
θ
θ
2(NL)N
-L
(NL)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 NL and NE
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)
RE calculations must be clamped to zero to maintain in [0, 1] bounded range
RE 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