CS 248: Introduction to Computer Graphics
Pat Hanrahan
FAQ
Questions
Q1. Why can't I see anything when I load
navigate.sc in MOAN?
Q2. How do I reflect an object (e.g to make a right
arm from a left one) in MOAN?
Q3. When I use scale transformations, weird things
happen. Any hints?
Q4. What is the depth of a scene
tree?
Q5. If we do the interpolation the way you tell us
to, this will have the undesirable effect of making the figure stop at
each keyframe. Are you sure this is what we should do?
Q6. In part 4, you request us to make the camera at
each figure's head point in the direction of the other figure. What if
this is very unnatural, given the movement of my figure in the
animation I designed?
Q7. Do you have to suggest any software that can
help me understand material properties?
Q8. I try to animate joint rotations and I get weird
results. What am I doing wrong?
Q9. A question on part 3: What if the cyclical
motion I use does not involve any translation (such as a ballerina
performing a piroutte), in which case the head of the stationary
figure could just remain fixed?
Q10. You request that our animations employ at
least 5 separate translations. If I have a connected body, the only
translation I can see is moving the whole rigid body. Any
suggestions?
Answers
Q1. Why can't I see anything when I load
navigate.sc in MOAN?
Because navigate.sc has no primitives: its goal is not to
define a visible scene; rather, it's to teach you scene tree
navigation. See the MOAN documentation
on scene navigation for more information, including a diagram of
the scene tree for navigate.sc.
Q2. How do I reflect an object (e.g to make a right
arm from a left one) in MOAN?
You edit the scene file. You may only modify one property of a scene
from within MOAN: keyframes of joint
transformations. Nothing else.
When you cut-and-paste a body part in your scene file, make sure you
do so only after the body part is completely designed, and right
before you begin animation (during which, most probably, you will
animate differently the right and left copies). If you plan to make
further edits in the design, you would have to maintain two copies in
sync if you replicated the part first.
Q3. When I use scale transformations, weird things
happen. Any hints?
Yes. Uniform scales are (mostly) benigh. But non-uniform scales, such
as those turning spheres into ellipsoids are not: if they precede
rotations, they will give very unexpected results. See the
OpenGL Programming Guide, pages 78-9 , for details. The
moral of the story: find a way to "encapsulate" non-uniform scales so
that they only affect the shape of a primitive and nothing else in the
scene tree...
As concerns lighting, scales, whether uniform or not, may have strange
effects, as they change the length of unit normals, which are the key
elements of all lighting calculations. Enabling
GL_NORMALIZE asks OpenGL to
re-normalize the length of normals prior to making the lighting
calculations. However, if a scale transformation has managed to turn a
unit normal into a zero (or near zero, due to floating point errors)
vector, GL_NORMALIZE does not help: this happens only when
a scale is degenerate (or nearly so), i.e. fully "squashing" one
dimension, such as when it turns a cone into a disc. Avoid such
scales! Can you see now why MOAN offers a separate disc
primitive?
Q4. What is the depth of a scene tree?
It is the maximum over all leaves of the leaf's depth. A leaf's depth
is the number of nodes on the path joining the leaf to the root,
including the root, but not the leaf itself. Hence, the scene tree
Group Begin
Name: foo
Primitive
Line
Group End
has depth 1.
For more information on trees and their metrics, see Cormen, T.H.,
C.E. Leiserson, and R.L. Rivest, Introduction to
Algorithms.
Q5. If we do the interpolation the way you tell us
to, this will have the undesirable effect of making the figure stop at
each keyframe. Are you sure this is what we should do?
Yes. The figure will momentarily stop, indeed, and this is
undesirable. But it's the price we pay for using a cubic interpolation
method that
- is simple to implement, as it only takes into account the two
adjacent keyframes, and yet
- provides smooth transitions in velocity between keyframes.
Q6. In part 4, you request us to make the camera at
each figure's head point in the direction of the other figure. What if
this is very unnatural, given the movement of my figure in the
animation I designed?
I messed up in stating this requirement: I wouldn't want your figure's
neck to twist and break. So, here is what you should do,
ideally:
- (5 points) Your (almost) stationary figure
should always look at the moving one, and
- (5 points) the moving figure should look at the
stationary one for as long as it is natural for it to do so. "natural"
depends on whether your figure is a human, who can barely twist
his/her neck, or an owl or sea lion, who can easily turn their heads
180 degrees.
Given that this is a late change, full credit will be given whether
you implement item 2 as stated above, or whether your figure's neck
does twist and break, as stated in the assignment handout.
Q7. Do you have to suggest any software that can help
me understand material properties?
Yup! Silicon Graphics provides an
elementary scene composer accessible via
/usr/sbin/SceneViewer
on the raptors (and firebirds). Load the file
/usr/share/data/models/simple/tri.iv
and then press the ? button to the side of the main window
to find out how to
- view the triangle shown on the screen from some angle other than
sideways (which makes it look like a long, skinny rectangle),
- modify the material properties of the triangle,
- create light sources, and
- much more...
Thus, you may gain some intuition on OpenGL's lighting
model.
Yoy are on your own using SceneViewer. The on-line
documentation should be adequate, though. If you really need help,
come see us/call us during office hours (not via email).
Q8. I try to animate joint rotations and I get weird
results. What am I doing wrong?
Joint rotations are tricky: the safest way to use them is to keep the
axis constant and unchanging for all the frames of your animation; let
only the angle vary.
This means that if a joint has two or three degrees of freedom in its
orientation, then you need to use two or three rotations (each about a
constant, different axis, such as the coordinate axes). Thus, you are
wasting space, since in theory, an arbitrary orientation can be
represented by a single rotation. However, specifying the orientation
of a joint using the four parameters of a single joint rotation is
much harder than using the three angles of three successive
rotations; so, what you lose in efficiency you gain in
user-friendliness.
If you decide to animate the rotation axis, bear in mind that you risk
making it (0,0,0): this is illegal (see glRotate*()) and
produces totally unexpected, ill-defined warps of your scene.
Q9. A question on part 3: What if the cyclical motion
I use does not involve any translation (such as a ballerina performing
a piroutte), in which case the head of the stationary figure could
just remain fixed?
As for question 6, you'll get full points if the
head of the stationary figure remains fixed. Ideally, you may
have the stationary figure examine the movement of the other figure,
possibly looking from head to toe and back.
Q10. You request that our animations employ at least
5 separate translations. If I have a connected body, the only
translation I can see is moving the whole rigid body. Any
suggestions?
Yes! Be creative! See our
animation for ideas. Think of your character as a cartoon - it can
do much more than a truly rigid figure. Even a real figure may have a
bouncing hat, or pin on the torso, or a yoyo, or whatnot...
hanrahan@cs.stanford.edu
tolis@cs.stanford.edu
Copyright © 1996 Pat Hanrahan and Apostolos
"Toli" Lerios