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.

One possible practical 3D Rendering Pipeline


ASG#5:  "3D Parallel Projections and the Crystal Ball Interface"

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 in SLIDE

    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