Hierarchical and ObjectOriented Graphics

1
Hierarchical and Object-Oriented Graphics

• Chapter 8

2

• Introduction
• In this chapter we explore multiple approaches to
  developing and working with models of geometric
  objects.
• We extend the use of transformations from Chapter
  4 to include hierarchical relationships among the
  objects.
• The techniques that we develop are appropriate
  for applications, such as robotics and figure
  animation, where the dynamic behavior of the
  objects is characterized by relationships among
  the parts of the model.

3

• The notion of hierarchy is a powerful one and is
  an integral part of object oriented
  methodologies.
• We extend our hierarchical model of objects to
  hierarchical models of whole scenes, including
  cameras, lights, and material properties.
• Such models allow us to extend our graphics APIs
  to more objet-oriented systems and gives us
  insight in how to use graphics over networks and
  distributed environments, such as the Web.

4
1. Symbols and Instances

• Our first concern is how to store a model that
  may include many sophisticated objects.
• There are two immediate issues
• How do we define a complex object
• How do we represent a collection of these
  objects.
• We can take a non hierarchical approach to
  modeling regarding these objects as symbols, and
  modeling our world as a collection of symbols

5

• Symbols are usually represented at a convenient
  size and orientation.
• For example a cylinder
• In OpenGL we have to set up the appropriate
  transformation from the frame of the symbol to
  the world coordinate frame to apply it to the
  model-view matrix before we execute the code for
  the symbol.

6

• For example the instance transformation
• M TRS
• is a concatenation of a translation, a rotation,
  and a scale
• And the OpenGL program often contains this code
• glMatrixMode(GL_MODELVIEW)
• glLaodIdentity()
• glTranslatef(...)
• glRotatef(...)
• glScalef(...)
• glutSolidCylinder(...)

7

• We can also think of such a model in the form of
  a table
• The table shows no relationship among the
  objects. However, it does contain everything we
  need to draw the objects.
• We could do a lot of things with this data
  structure, but its flatness limits us.

8
2. Hierarchical Models

• Suppose we wish to build an automobile that we
  can animate
• We can build it from the chassis, and 4 wheels

9

• Two frames of our animation could look like this
• We could calculate how far the wheel moved, and
  have code that looks like
• calculate(speed, distance)
• draw_right_front_wheel(speed, dist)
• draw_left_front_wheel(speed, dist)
• draw_right_rear_wheel(speed, dist)
• draw_left_rear_wheel(speed, dist)
• draw_chassis(speed, dist)

10

• BUT this is the kind of code we do NOT want....
• It is linear, and it shows none of the
  relationships between the 5 objects.
• There are two types of relationships we wish to
  convey
• First, we cannot separate the movement of the car
  from the movement of the wheels
• If the car moves forward, the wheels must turn.
• Second, we would like to note that all the wheels
  are identical and just located and oriented
  differently.
• We typically do this with a graph.
• Def node, edge, root, leaf, ...

11

• Tree Representation
• DAG Representation

12
3. A Robot Arm

• Robotics provides many opportunities for
  developing hierarchical models.
• Consider this arm
• It consists of 3 parts

13

• The mechanism has 3 degrees of freedom, each of
  which can be described by a joint angle between
  the components
• In our model, each joint angle determines how to
  position a component with respect to the
  component to which it is attached
• q - rotation of the base
• f - rotation of first arm
• y - rotation of second arm piece.

14

• We could write it as follows
• display()
• glRotatef(theta, 0.0, 1.0, 0.0)
• base()
• glTranslatef(0.0, h1, 0.0)
• glRotatef(phi, 0.0, 0.0, 1.0)
• lower_arm()
• glTranslatef(0.0, h2, 0.0)
• glRotatef(0.0, 0.0, 1.0)
• upper_arm()

15

• Note that we have described the positioning of
  the arm independently of the details of the
  individual parts.
• We have also put it into a tree structure
• This makes it possible to write separate programs
  to describe the components and animate the robot.
• Drawing an object stored in a tree requires
  performing a tree traversal (you must visit every
  node)

16
4. Tree Traversal

• Here we have a box-like representation of a human
  figure.
• We can represent this figure as a tree

17

• If we put the matrices with each node we can
  specify exactly how to draw the robot
• The issue is how to traverse the tree...
• Typically you do a pre-order traversal.
• This can be done in two ways
• with code and a stack
• recursively (implicit stack)

18

• 4.1 A Stack-Based Traversal
• Consider the code necessary to draw the Robot.
• This function might be called from the display
  callback
• The Model-View matrix, M, in effect when the
  function is invoked determines the position of
  the robot relative to the rest of the scene.

19

• The function must manipulate the model-view
  matrix before each part of the robot is drawn.
• In addition to the usual OpenGL functions for
  rotation, translation, and scaling, the functions
  glPushMatrix and glPopMatrix are particularly
  helpful for traversing our tree.
• The first glPushMatrix duplicates the current
  model-view matrix
• assuming that we have done a previous
  glMatrixMode(GL_MODELVIEW)
• When we have finished with changes we can do a
  glPopMatrix to get back the original one saved
• Note we must do another glPushMatrix to leave a
  copy that we can later go back to.

20

• OpenGL also has the functions glPushAttrig and
  glPopAttrib that allow us to deal with attributes
  in a similar manner
• OpenGL divides its state into groups, and allows
  a user to push any set of these groups on th
  attribute stack.
• The user needs only to set the bits in a mask
  that is the parameter for glPushAttrib
• Attribute groups include lighting, so we can push
  material properties and lights onto the stack.

21
5. Use of Tree Data Structures

• The second approach is to use a standard tree
  data structure to represent our hierarchy and
  then to render it with a traversal algorithm that
  is independent of the mode of traversal.

22

• At each node we must store the information
  necessary to draw the object
• a function that defines the object
• the homogeneous coordinate matrix that positions
  the object relative to the parent.
• Typedef struct treenode
• Glfloat m16
• void (f)()
• struct treenode sibling
• struct treenode child

23

• Traversing the tree in a preorder traversal can
  be accomplished
• void traverse (treenode root)
• if(root NULL) return
• glPushMatrix()
• glMultMatrix(root-gtm)
• root-gtf()
• if(root-gtchild! NULL) traverse(root-gtchild)
• glPopMatrix()
• if(root-gtsibling! NULL) traverse(root-gtsibling
  )

24
6. Animation

• Our robot example is articulated
• consists of rigid parts connected by joints
• We can make such models change their positions in
  time - animate them - by altering a small set of
  parameters.
• Hierarchical models allow us to reflect correctly
  the compound motions incorporating the physical
  relationships among parts of the model.

25

• Of the many approaches to animation, a few basic
  techniques are of particular importance when we
  work with articulated figures.
• Kinematics
• describing the position of the parts of the model
  based on only their joint angles.
• Inverse kinematics and inverse dynamics
• given a desired state of the model, how can we
  adjust the angles so as to achieve this position?
• key-frame animation
• position the objects at a set of times.
• Inbetweening
• then fill in (interpolate).

26
5. Use of Tree Data Structures
27
(No Transcript)
28
(No Transcript)
29
6. Animation
30
(No Transcript)
31
7. Graphical Objects
32
(No Transcript)
33

• 7.1 Methods, Attributes, and Messages

34
(No Transcript)
35

• 7.2 A Cube Object

36
(No Transcript)
37

• 7.3 Objects and Hierarchy

38
(No Transcript)
39

• 7.4 Geometric Objects

40
(No Transcript)
41
8. Scene Graphs
42
(No Transcript)
43
9. Other Tree Structures
44
(No Transcript)
45

• 9.1 CSG Trees

46
(No Transcript)
47

• 9.2 BSP Trees

48
(No Transcript)
49

• 9.3 Quadtrees and Octrees

50
(No Transcript)
51
10. Graphics and the Web
52
(No Transcript)
53

• 10.1 Networks and Protocols

54
(No Transcript)
55

• 10.2 Hypermedia and HTML

56
(No Transcript)
57

• 10.3 Databases and VRML

58
(No Transcript)
59

• 10.4 JAVA and Applets

60
(No Transcript)
61
11. Summary
62
(No Transcript)
63
12. Suggested Readings
64
(No Transcript)
65
Exercises -- Due next class