CS 184: COMPUTER GRAPHICS

QUESTION OF THE DAY:

1.) What is the largest circle that you can display on your screen (diameter in pixels) ?

2.) You have rasterized a perfect circle into a 500 by 500 pixel square viewport,
     but now you use a different display that does not have square pixels  ==> How to avoid distortions ?

3.) How do you display a 16:9 aspect ratio movie on your old 4:3 aspect ratio screen ?
PREVIOUS < - - - - > CS 184 HOME < - - - - > CURRENT < - - - - > NEXT

Lecture #4 -- Mon 1/31/2011.

Crucial Concepts from Last Lecture:

Several possible definitions of "INSIDE":
1.) "PARITY" -- "EX-OR" -- "ON-OFF":  Switch between IN and OUT every time one steps across a single contour edge.
2.) "Non-zero Winding Number":  The polygon contour  (string) loop, cannot be pulled away from a finger stuck at an INSIDE point.
3.) "Positive (non-zero) Winding Number":  INSIDE if the combined Winding Number of one ore more closed contours is larger than zero.  (This is the preferred paradigm in computer graphics and for rapid prototyping by layered manufacturing. It allows superposition of several primitives, and carving out holes using Boolean CSG operations.)
Some examples: 
Two polygon overlays with different contour directions colored in with the Strictly Positive Winding Number paradigm.
A complicated polygon clipped with Sutherland-Hodgman algorithm and colored in with the Non-zero Winding Number paradigm.
To compute the WINDING NUMBER:  Count ONE UP or ONE DOWN depending on whether the oriented contour edge that one crosses comes from the LEFT or from the RIGHT.

It is desirable to consider the orientation of a polygon contour so we can do BACKFACE ELIMINATION (and save roughly half the work in the rendering pipeline).

ALL GEOMETRY should be clipped to the viewport frame!
Clipping of lines and polygons is straight-forward and is now done by the graphics hardware;
it preserves the visible portion inside the viewport and the topological information needed for rendering.

Linear interpolation is a key operation not just for clipping, but also for morphing, for shading, and for the efficient calculation of splines and subdivision surfaces.

The Various Coordinate Systems in the Classical Rendering Pipeline...

Last week we discussed how to construct and edit a polygon, how to determine what is inside.
Today we talk about how to transform it:
-- first in the modeling phase to build up a scene (modeling transformation)
-- and then again to map that scene to a particular location on the display (viewport mapping).
World to screen transforms for the classical rendering pipeline.
And what it does to a world of triangles.
Transformations are a key element of computer graphics !  They show up everywhere !!

Transformations (first in 2D)

Conceptual demo of  MODELING TRANSFORMATIONs  with transparency overlays: Placement, grouping, compound transformations...
e.g., rotation around an arbitrary point  (foil).
note: order of transformation matters !
Now, what is going on "under the hood"?

Matrix Representation of Translations ==> Homogeneous Coordinates

Transformations are conveniently described and applied with the use of matrices.
This yields a powerful formalism for combining the effects of several transformations through matrix multiplication.
Also: If we transform a complicated object with thousands of vertices with the same (compound) transformation,
         then we need to calculate that compound matrix only once and can then use it to transform all those vertices.

We also want to do Translation with Matrices. This is not straight-forward, since translation is not a "linear operation"!
Linear transforms: {T(aX + B) = a T(X) + b }    ==>  always leaves the origin in place; T(0) = 0.
==> We use a clever hack via homogeneous coordinates:
"Homogenizing"  = introduce an extra component:  w :  (x, y) ==>  (wx, wy, w)
We can always recover the  regular cartesian coordinates by a division with w  (w<>0);
(this corresponds to a cut of the homogeneous line with the w=1 plane).
Matrix operation is still linear in d+1 dimension (origin stays in place), but we are only interested in the (hyper-)plane  w=1.
The basic translation matrix, and how it works:  (like a shear operation).

Other 2D transformation matrices for use with homogeneous column vectors.
Distinguish: Rigid-body transforms  (rotate and translate) and  Affine transforms  (scaling and shear).

Issues arising from use of homogeneous coordinates:

Efficiency ?: -- Number of arithmetic operations may increase!
Yields ease of composition: -- No need to separate out the translation part.
Also:  Now we have hardware that has been designed to handle homogeneous coordinates, thus there would be no savings doing it any other way!
Abstraction from implementation: however it is done -- hide it from user ! 
(Also: row vectors versus column vectors =>  "outside" matrix multiplication).

Viewport Mapping  (a special 2D transformation)

In assignment A#2 you are asked to make the display window scalable (e.g., by dragging one of its corners).
But you don't want your carefully designed fantasy polygon to be distorted!
==> Just scale it uniformly to the largest size that fits undistorted into the given window.
Thus, you have to determine what is the largest rectangle with the aspect ratio of your original drawing window (= square) that fits into the given window.
If we were to just scale the x- and y-directions individually, so that the content of window completely fills the viewport, we might get affine distortions, if the aspect ratios of window and viewport are different. To avoid such distortion, we choose the smaller of the two scale factors and apply it uniformly to both axes.

To gain independence and abstraction of the actual display device, we calculate the necessary transformation in steps: 
Window (projection of selected area from original sceene) ==> NDC (normalized device coordinates: 0,0 to 1,1 ) ==> Viewport (area on display, e.g. in pixel addresses).

Another Important Concept in A#2:  Picking

Find what is under the cursor!  ( Like target shooting in a CG game:  How do you know what, if anything, you hit with your blaster ? )
==> A#2: Test each polygon vertex whether it is "close enough" (+/- 2-3 pixels) to the mouse!

Abstractions, LODs, Bounding Volumes ("Areas" in 2D)

It is useful to have some simple Bounds around objects and groups in a scene, they can serve as:
-- conservative (pessimistic) size estimates (e.g. for culling) to reduce the amount of computation that needs to be done (e.g., in clipping, rendering, collision detection...)
-- crude abstractions ("place-holders", "imposters") for displaying that piece of the scene hierarchy at much lower LOD (level-of-detail).
Such bounds should be easy to construct and easy to use.  There are several possible bounding volumes:

Axis-Aligned Bounding Boxes (AABB):
A rectangle with diagonal corners (xmin,ymin), (xmax, ymax); they are easy to compute.
These AABB's have some inefficiencies: e.g., around a diagonal needle  (foil).
Also, with every (rotated) use in a hierarchy, the AABB may grow. ==> Example of nested AABBs around needle.

These are some alternatives:
Optimally oriented bounding boxes (OOBB):  they are more efficient but more difficult to determine.
Bounding circles or spheres: have rotation-independent size, but are not so easy to find either.
Convex hulls: can be constructed efficiently, but may have many vertices, ==> loss of efficiency.

==> These bounding volumes are very important in the context of a hierarchical scene. You will work with them in Assignments #2 and #3.
In a hierachical scene you will form a hierarchy of bounding boxes:
==> Just determine the bounding box around the boxes at the next lower level (foil).


+++ MINI-QUIZ +++

Reading Assignments:

Study: ( i.e., try to understand fully, so that you can answer questions on an exam): 
Shirley, (2nd or 3rd Ed): Ch 6.1, 6.3.

Programming Assignment #2:

This must be done individually.
Assignment #2 is due (electronically submitted) before Friday 2/4, 11:00pm.

Accounts for which we do not see a web page and a posted Assignment #1 will be closed.

PREVIOUS < - - - - > CS 184 HOME < - - - - > CURRENT < - - - - > NEXT
Page Editor: Carlo H. Séquin