CS 184: COMPUTER GRAPHICS
|
PROBLEM # 1:
Draw
a reasonable scene hierarchy for the scene on the left, using all the
named entities, but using as few geometrical objects as possible.
How many hierarchical levels do you end up with?
How many groups?
How many instances in a group?
|
PREVIOUS
< - - - - > CS
184 HOME < - - - - > CURRENT
< - - - - > NEXT
Lecture #5 -- Wed 2/2/2011.
Discuss: By what logic do we decide what is a good scene hierarchy (example: Robot Arm)?
Crucial Concepts from Last Lecture:
Matrices are linear operators. Composing linear operators is still linear. Any matrix has an inverse.
The transformations used in CG can be represented efficiently by
matrices.
Compound transformations can then be constructed by matrix multiplication.
Translation, can also be turned into a linear operator by introducing homogeneous coordinates.
Homogeneous coordinates: Look at the transformation in a space that is
one dimension higher (add "w") than the space of interest;
use the subset of transformations that leaves that new dimension
unaffected, except for a shear operation (z stays the same!),
and consider only what is happening in the hyperplane w=1.
Other neat things, not discussed in lecture:
Singular Value Decomposition (SVD) of any matrix: A = Q S R' where Q and R are orthonormal and S is a diagonal matrix.
or we can do a Polar Decomposition: A = U R S R' where again U and R are orthonormal and R' is the transpose of R.
==> Thus any complex matrix can be decomposed into a product of pure scale and rotation matrices!
The eigenvectors e of a matrix M are determined by the equation Me = se, where s is a simple scale factor;
They correspond to those vectors that do not change direction when transformation M is applied, (e.g. vectors along the coordinate axes when M is a non-uniform affine scaling).
Scene Hierarchy, Groups, Instantiations, Inheritance ...
Now we want to build complex scenes with more than just one polygon!
How should we "describe" a complex world model in the computer ?
-- for instance: a battle scene in StarWars?
-- or a Boeing 747: ~ 4 000 000 identifyable parts?
==> Use hierarchically nested groups of objects (and of other groups) with relative transformations.
An object or group of objects can be instantiated multiple times -- in different places, with different orientations, and with different scale factors.
==> Benefits: Managing complexity,
abstraction, structure, re-use of
objects,
easy searching and editing, reducing the rendering work, ...
An example of instancing: "60 Butterlies on a Sphere"
Conceptual scene structure. Corresponding scene graph and fully instantiated scene tree.
The scene is built from Groups and from Instances (of groups and/or objects).
The bottom-level of groups, consisting of elementary geometry are called Objects;
The top level group, i.e., the root of the scene graph, we typically call World.
Groups are composed of Instances; and each instance comes with a
transformation that specifies how it is positioned in the group's
coordinate system.
Instances also carry such information as color, LOD-values and some other flags (e.g. whether the group is static or time-variable).
Groups are also the place to store intermediate bounding boxes (of everything below).
Groups may have many children, and they are all instances.
Instances have only a single child and this may be an object or another group (NO RECURSION!).
There is a strict alternation between groups and instances in the hierarchy.
"SCD_09": Our way to capture this information in a human-readable ascii format (and also easy to parse for future use).
Example Scene Description ( SCD_09 )
(Include fish1 "fish.obj"
) ## this calls the polygon in that file
"fish1"
(G school_A
(I inst1 fish1
(S 0.5 0.5 ) (T 5 3.4 )
(color 1 0.8
0.2 ) ) ## orange fish
(I inst2 fish1 (S 0.7
0.4 ) (T 7.2 6 ) ) ##
uncolored fish
(I inst3 fish1 (R
{t*2} ) (T 8 9 ) ) ## blank fish,
rotating 2 degrees per frame around its center
## {expressions
in curly parentheses} are time-dependent and are evaluated anew
for every frame! ##
)
(G school_B
(I inst1 fish1 (S -0.5 0.5 ) (T 2
{0.4*sin(t*6*dgr)} ) ) ## mirrored fish, doing a complete vertical
wiggle every 60 frames.
(I inst2 fish1 (S {1 +
0.5*sin(t*3*dgr)} 0.6 ) (T 4 6 ) (color 0 1 0) ) ## green fish,
changing in length with a cycle of 120 frames.
## the
constant "dgr" turns user-friendly degree-units into _radians_,
which are expected by the trig functions. ##
)
(G myScene
(I i_1 school_A
(color 0 1 1) ) ## cyan version of
school_A
(I i_2 school_A (S -1
1) (color 1 0 1) ) ## magenta, mirrored
version of school_A
(I i_3 school_B (T
{t*0.01}{t*0.01} ) (lod 3)
) ##
school_B, slowly drifting diagonally off the view window, wire-frame
only.
)
(Render myScene )
Notes:
Identifiers within a group must be unique. They will serve to form unique names for all instances in the whole scene
by concatenating all instance names from top to bottom as
follows: "TopInst_ID.MiddleInst_ID. ... BottomInst_ID"
Transformations are applied from a WORLD perspective in the order listed:
thus (I inst_ID geom (Xform A) (Xform B) (Xform
C) )
should result in: [Xform C] * [Xform B] * [Xform A] * [geom]
i.e., subsequent transformation matrices are applied "on the outside"
= "away from the vector".
The (color ...) and (lod ...) attributes obey different hierarchical inheritance rules as follows:
COLOR: During rendering, each leaf of the hierarchical scene tree will get the color that is
closest to the leaf; i.e. the lowest color in the hierarchy dominates.
For example, if the sea is blue, containing a red instance of a school
of fish, which contains a fish that has not had its color set,
then
that fish should be colored red, while other fish that have been
individually colored, keep that color.
It may be prudent to start rendering with a default
color (say medium gray (.5 .5 .5) so that everything shows up somehow.
LOD: Levels of detail (LOD) are used to control the rendering effort on wants to expend on a subtree in the scene hierarchy.
Normally that involves the fineness of geometrical detail and the level of subdivision of smooth surfaces.
In A#3 we use a simplified LOD scheme just based on shading and rendering levels to demonstrate the principle:
LOD = 0 = none, render nothing at all.
LOD = 1 = bounding box, render just the bounding box around this subtree of the instance hierarchy,
LOD = 2 = outline, render the polygons as a colored "wire-frame" outline,
LOD = 3 = flat-shaded, render all polygons filled-in, flat-shaded, e.g., colored and possibly painted in (as far as OpenGL can do it);
LOD = 4 = fancy-shaded, render all polygons "fully", e.g., possibly textured, with fancy shading with highlights (ignore for A#3).
LOD = 5 = ?? -- there could be more levels.
During rendering, each node will get rendered
according to the lowest LOD value occurring in the hierarchy above the
node of interest.
For example, if a node has LOD = none, the whole
subtree can be ignored, and no nodes beneath it in the hierarchy are
rendered.
B_BOXES: are also calculated recursively during rendering.
From the bottom leaf nodes, the bounding boxes for all objects are
calculated;
its four corners should be subjected to the instance
transformations, and the extrema of all those transformed points then
yield the bounding box for the parent group.
Each transformed bounding box can individually be
surrounded with a (virtual) bounding box that can be compared against
the current view window for culling and clipping.
DYNAMIC_FLAG: A flag may be set for each group definition, if there
is anything dynamic (time-varying) below it that may force a
re-evaluation of the bounding box.
Another hierarchical scene: 18-Wheeler -- and how ths hierarchy needs to get modified when there is a flat tire.
Solutions to Question #3 ( A and B ) on the Mini-Quiz#1
Pick up your graded Mini-Quiz#1 -- ( 6 bundles sorted by account # )
Students who did not submit Assignment #1 and participate in Mini-Quiz#1 have been dropped from the class.
Students who have done all the work so far, and want to be in this class, but who do not appear
on the class-list, or the concurrent-enrollment-queue, or the wait-list,
should see Michael-David Sasson in 379 Soda Hall a.s.a.p.
Reading Assignments:
Study: Lecture notes (my on-line notes, as well as your own personal notes).
At the end of every week, you should have fully understood and committed to your brain all material covered up to that point.
Programming Assignments 2 and 3:
Assignment #2 is due (electronically submitted) before Friday 2/4, 11:00pm. -- Must be done individually.
Assignment #3 is due (electronically submitted) before Friday 2/11, 11:00pm. <== THIS ASSIGNMENT CAN BE DONE IN PAIRS !
(A#4: Basics of ray-tracing, will be done individually again)
PREVIOUS
< - - - - > CS
184 HOME < - - - - > CURRENT
< - - - - > NEXT
Page Editor: Carlo
H. Séquin
