# CS代考计算机代写 CS580

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