CS 184: COMPUTER GRAPHICS
Lecture #12 -- We: 3/3, 1999.
PREVIOUS
< - - - - > CS
184 HOME < - - - - > CURRENT
< - - - - > NEXT
Preparation:
Remember : Next Monday: Quiz #2
Read: Ch 6.1 - 6.5.2 "Viewing in 3D"
Lecture Topics
The
main transformation steps.
Role of the VRCS
In the case of a general camera position, we need to know what can be seen
from that camera position.
To make things simple, we make a coordinate system anchored at the
camera as a reference frame,
the View Reference Coordinate System (VRCS),
and transform the parts of the world to be rendered into this new reference
frame.
Preview of Perspective Projection
Scene Hierarchy --> Rendering Hierarchy
For rendering and associated back-face culling and projections,
we need to know, how does a scene object lie in the camera's reference
system ?
Easiest if we do all in a coordinate system nicely aligned with the
camera
(x-axis coming straight in through the lens == looking down the z-axis)
This is the default that we are assuming in Asg#5 !
Form a suitable compound transformation.
Use inverse transformations whenever you need to move upwards in the
scene tree.
Putting it all together
We also need to think about the exact order in which we want to do all
the necessary operations: culling, clipping ...
General principle: Do least expensive, most work-saving steps first
!
Rendering Statements
window
viewport
camera
render
Provide a convenient "user-centric" way to twiddle an object around for
inspection.
The basic approach keeps the various actions fairly separate and has
the following functionality:
RIGHT MOUSE: z-rotation
MIDDLE MOUSE: "zoom" = uniform scaling of object
LEFT MOUSE: Crystal ball interface = "simultaneous rotations around
x & y axes.
Enhanced Interfaces
Mix in some amount of z-rotation into the dragging operation with
the LEFT MOUSE button:
The further way the stroke passes the center of the screen, the more
the crystal ball responds with a pure z-rotation.
There are several different ways as to how exactly this can be achieved
(see
notes).
Event Loop in Interactive Graphics Interfaces
Don't queue all mouse move events ! If program can't keep up, you pile
up a huge legacy and you then can't get the control back to the user until
queue has been woorked off !
Instead use simple overall loop:
init_mouse_diff=0 >> get_mouse_pos
>> draw frame
>> get_mouse_pos >> calc_diff
>> comp_inc_rot >> calc/save_view_matrix
>> draw frame
>> repeat ...
More on User Interfaces, Human Factors
(This will be an important consumer of additional "free" CPU cycles becoming
available in the next decade)
Make it easy for the user rather than for the computer !
Keep it reactive; move cursor immediately ! Do other stuff later.
Give good visual (acoustic, other) feedback of what is going on, what
has been selected,
whether cursor has snapped to a particular shape or alignment line
{e.g. hilite} ...
Speed AND Precision
Grids, gravity, auxiliary lines, ...
Combine all these ideas in Snap-dragging.
Application-dependent Conveniences.
Automate the most frequently occurring operations.
Provide proper defaults.
Reasonable ways to disambiguate the mouse movements.
Current Homework Assignment:
ASG#5:
"Crystal Ball Interface"
DUE: Saturday 3/6/99, 11:59pm.
TO BE DONE with a NEW PARTNER !
{From assignment #6 onward, your choice of partners will be unconstrained,
you may switch or not at will}
Quiz #2 will be handed out Monday 3/8/99 -- DUE Wednesday 3/10/99.
--> Next
Lecture
<-- Up to CS
184 HomePage
Page Editor: Carlo H. Séquin