CS 184: COMPUTER GRAPHICS
PREVIOUS
< - - - - > CS
184 HOME < - - - - > CURRENT
< - - - - > NEXT
NOTE: Tonight: discussion sections 7-9pm in 320 Soda hall
Lecture #12 -- Th: 10/7, 2004.
Putting together a Simple 3D Rendering Pipeline
The
main transformation steps
Scene Hierarchy --> Rendering Hierarchy
Put the Camera node "above" the World node.
Use inverse transformations whenever you need to move "upwards" in
the scene tree.
Finding the proper sequence ...
We need to think about the exact order in which we want to do all the
necessary operations:
-- culling, backface elimination, clipping, shading, rasterizing ...
General principles:
-- Do least expensive, most work-saving steps first.
-- Don't throw away information you may need later.
-
Read in the scene description (build appropriate internal data structures).
-
Process the master geometry at the leaf nodes (calculate face and/or
vertex normals).
-
Define a camera type (for now using a parallel projection).
-
Place this camera in the World (probably using the "look_at" transformation).
-
Find how the World lies in the VRCS coordinate system (use inverse
camera transformation).
-
Fit the view volume into the canonical half-cube (non-uniform scaling).
-
Do hierarchical bounding-box culling in 3D (using 6-bit outcodes
on the 8 Bbox corners).
-
Eliminate the backwards facing polygons (check z-components of transformed
face normal).
-
Clip the polygons at the leaves of the scene hierarchy that straddle
the canonical half-cube (against 6 planes).
-
Later:
-
Compute the color/shading on the remaining polygon fragments (assume
diffuse ambient lighting only).
-
Raster-fill the polygons (turn on the pixels that represent the
visible area of the polygon).
-
Resolve overlapping polygons (use z-buffer to render front-most
pixel).
First, make some simple 3D scene (consisting of convex objects).
You may use some imported
SLIDE objects from a library of polyhedra.
For instance the "triacontrahedron"
which is the "dual
of the icosidodecahedron".
Make large visible time/mouse dependent chages,
so that we can see that your algorithms can handle dynamic scenes.
Then get the basic rendering process to work.
First just use a default parallel projection down the z-axis as you
have been using in the past assignments.
Once you can see something on the screen, debugging becomes much easier
(and more fun).
Then add the other modules:
Bounding box culling, back-face elimination, polygon clipping.
Just modify suitably your 2D code for these modules.
You can use the flat-shaded rendering mode, and let the z-buffer take
care of eliminating features hidden by occlusion
(you will implement that module in a later assignment).
Finally, add a "Crystal Ball" interface to manipulate the 3D object/scene.
This provides a convenient way to twiddle an object around for interactive
inspection.
The conceptual idea is that your screen is some large crystal ball
that contains the scene that you are seeing.
With appropriate mouse motions on its surface, you can rotate that
ball and its content.
Interactive Viewing Control: "Crystal Ball" Interface
In 2D there are only a few parameters needed to specify what subset
of the total image you want to see:
the size, position, and orientation of the window. (How many DOFs is
that ?)
In 3D it is more complicated to specify what it is you want to
see of the world, and from what angle, and from what distance.
Many different user interfaces are possible !
From video games you may be familiar with walk-through or fly-through
interfaces,
where you control the direction and speed of the camera's movement
through space.
To interactively inspect a single object or a compact group of objects,
a different UI is more appropriate:
the Crystal Ball Interface, in which you consider the viewer
(camera) to be stationary,
but the object is rotated and moved in front of the camera.
This UI is typically used with CAD tools for mechanical and automotive
engineers.
The crystal ball interface makes use of general 3D rotations -- around an arbitrary axis, not just one of the 3 coordinate axes.
The key is to pick the right coordinate system and the proper axis
to rotate around !
Background:
Old, inconvenient UI turned an object around in its master
coordinate system, first by sliders, later by mouse:
If you turn object left to right 180 degrees ==> confusion!
(Story of siggraph vendor booth demos).
We will do better: We will turn the object in the screen coordinate
system,
so that it always responds properly to the mouse cursor movements as initiated by the viewer.
Discuss 3 mouse functions.
LEFT: Crystal ball interface = "simultaneous rotations around x &
y axes.
MIDDLE: "zoom" = uniform scaling of object
RIGHT: z-rotation
Implementation:
see Lab notes.
3D Rotations around an arbitrary axis
Useful for building kinematic scenes, e.g., with wheels spinning around
skewed axes.
3 conceptual approaches:
1.) Classical approach: build a compound transformation in the following
way:
move rotating object so that rotation axis goes through origin;
turn rotation axis into the z-axis (in a 2-step rotation around z-axis and y-axis);
apply the desired rotation around the current z-axis;
rotate the axis back to its former orientation (inverse of the two steps above);
move object back to its original position (inverse of original translation).
2.) Another way to achieve the above effect is to use the "change
of basis" matrix
.
Define a local coordinate system with its z-axis aligned with the rotation axis.
Do a coordinate transform that expresses the world coordinates in this new coordinate system,
in which the desired rotation can be done easily (around the z-axis).
Then do a change of basis back to the old coordinate system.
3.) A third way is to use vector algebra to decompose the vector from the
origin to the point to be transformed
into two components: one parallel
to the rotation axis, and the other perpendicular to it.
Only that second component needs to be rotated, and this can be done
in a plane perpendicular to the rotation axis.
The overall transformation matrix then results from a composition of
these vector components (see
lab notes).
The general SLIDE rotation statement does all this work for you
!
Where should this extra transformation go ?
The Crystal Ball interface seems to affect "everything" ...
So, should the corresponding transformation be put at the root of the
scene hierarchy ?
No -- because this would rotate the camera as well as all the objects
in the scene,
-- and then the view of the scene would not change !
Thus the transformation should go at a subtree of the world that does
not
contain the viewing camera.
Should that subtree include the lights ?
Discuss the pros and cons ...
... and the SLIDE solution.
Camera Parameters for Parallel Projection
The key parameters of a camera are its position (3 DOF) and orientation
(3 DOF);
( These are the 6 DOF of a rigid body in 3D ).
For parallel projection one of them is redundant, i.e., the distance from the scene.
Additional camera parameters include:
"Focal length" --> determines the opening angle of viewing pyramid;
positioning and size of the imaging plane and the window of interest
("film").
For a parallel projection, "focal length" is not a parameter
-- it is always infinite.
However, we need a way to specify what it is we want to see in our
image plane,
i.e., the bounds of the bundle of projection rays that we are
casting,
and, implicitly, the angle at which they intersect our imaging
plane.
This is all done by defining an appropriate rectangle in the plane
z = -1.
Furthermore, we introduce front- and back-clipping planes, to
reduce clutter and interference.
Rendering Statements:
window
viewport
camera
render
Study their on-line descriptions, their options and defaults.
NOTE: Between 10/12 and 10/14 you will have to do: Take-Home
Quiz #2
Topics: Lecture Material, assigned Textbook Studies,
Programming Assignments.
Bring your level of understanding up-to-date
and reserve about a 2-hr time slot.
Reading Assignment:
Study: 2ndEd: Ch 4.7, Ch 5.1-5.7,
Study: 3rdEd: Ch 4.7, Ch, 5.1-5.8,
Current Homework Assignment:
ASG#5:
"3D Parallel Projections and the Crystal Ball Interface"
TO BE DONE with a NEW PARTNER !
PREVIOUS
< - - - - > CS
184 HOME < - - - - > CURRENT
< - - - - > NEXT
Page Editor: Carlo H. Séquin