Modeling and Hierarchy

1
Modeling and Hierarchy

• Chapter 10

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

• Graph
• Set of nodes and edges (links)
• Edge connects a pair of nodes
• Directed or undirected
• Cycle directed path that is a loop

loop
12

• Tree
• Graph in which each node (except the root) has
  exactly one parent node
• May have multiple children
• Leaf or terminal node no children

root node
leaf node
13

• Tree Model of a car

14

• DAG Model
• If we use the fact that all the wheels are
  identical, we get a directed acyclic graph
• Not much different than dealing with a tree

15

• Modeling with trees
• Must decide what information to place in nodes
  and what to put in edges
• Nodes
• What to draw
• Pointers to children
• Edges
• May have information on incremental changes to
  transformation matrices (can also store in nodes)

16
3. A Robot Arm

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

17

• 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

18

• Articulated Models
• Robot arm is an example of an articulated model
• Parts connected at joints
• Can specify state of model by giving all joint
  angles

19

• Relationships in Robot Arm
• Base rotates independently
• Single angle determines position
• Lower arm attached to base
• Its position depends on rotation of base
• Must also translate relative to base and rotate
  about connecting joint
• Upper arm attached to lower arm
• Its position depends on both base and lower arm
• Must translate relative to lower arm and rotate
  about joint connecting to lower arm

20

• Required Matrices
• Rotation of base Rb
• Apply M Rb to base
• Translate lower arm relative to base Tlu
• Rotate lower arm around joint Rlu
• Apply M Rb Tlu Rlu to lower arm
• Translate upper arm relative to upper arm Tuu
• Rotate upper arm around joint Ruu
• Apply M Rb Tlu Rlu Tuu Ruu to upper arm

21

• OpenGL Code for Robot
• robot_arm()
• glRotate(theta, 0.0, 1.0, 0.0)
• base()
• glTranslate(0.0, h1, 0.0)
• glRotate(phi, 0.0, 1.0, 0.0)
• lower_arm()
• glTranslate(0.0, h2, 0.0)
• glRotate(psi, 0.0, 1.0, 0.0)
• upper_arm()

22

• Tree Model of Robot
• Note code shows relationships between parts of
  model
• Can change look of parts easily without
  altering relationships
• Simple example of tree model
• Want a general node structure for nodes

23

• Possible Node Structure

Code for drawing part or pointer to drawing
function
linked list of pointers to children
matrix relating node to parent
24

• Generalizations
• Need to deal with multiple children
• How do we represent a more general tree?
• How do we traverse such a data structure?
• Animation
• How to use dynamically?
• Can we create and delete nodes during execution?

25
4. Trees and Traversals

• Here we have a box-like representation of a human
  figure and a tree representation.

26

• Building the Model
• Can build a simple implementation using quadrics
  ellipsoids and cylinders
• Access parts through functions
• torso()
• left_upper_arm()
• Matrices describe position of node with respect
  to its parent
• Mlla positions left lower arm with respect to
  left upper arm

27

• Tree with Matrices

28

• Display and Traversal
• The position of the figure is determined by 11
  joint angles (two for the head and one for each
  other part)
• Display of the tree requires a graph traversal
• Visit each node once
• Display function at each node that describes the
  part associated with the node, applying the
  correct transformation matrix for position and
  orientation

29

• Transformation Matrices
• There are 10 relevant matrices
• M positions and orients entire figure through the
  torso which is the root node
• Mh positions head with respect to torso
• Mlua, Mrua, Mlul, Mrul position arms and legs
  with respect to torso
• Mlla, Mrla, Mlll, Mrll position lower parts of
  limbs with respect to corresponding upper limbs

30
4.1 A Stack-Based Traversal

• Set model-view matrix to M and draw torso
• Set model-view matrix to MMh and draw head
• For left-upper arm need MMlua and so on
• Rather than recomputing MMlua from scratch or
  using an inverse matrix, we can use the matrix
  stack to store M and other matrices as we
  traverse the tree

31

• Traversal Code
• figure()
• glPushMatrix() // save present model-view
  matrix
• torso()
• glRotate3f() // update model-view matrix
  for head
• head()
• glPopMatrix() // recover original
  model-view matrix
• glPushMatrix() // save it again
• glTranslate3f() // update model-view matrix
  
• glRotate3f() // for left upper
  arm
• left_upper_arm()
• glPopMatrix() // recover and save
  original
• glPushMatrix() // model-view matrix
  again
• ...

32

• Analysis
• The code describes a particular tree and a
  particular traversal strategy
• Can we develop a more general approach?
• Note that the sample code does not include state
  changes, such as changes to colors
• May also want to use glPushAttrib and glPopAttrib
  to protect against unexpected state changes
  affecting later parts of the code

33
5. Use of Tree Data Structures

• Need a data structure to represent tree and an
  algorithm to traverse the tree
• We will use a left-child right sibling structure
• Uses linked lists
• Each node in data structure is two pointers
• Left next node
• Right linked list of children

34

• Left-Child Right-Sibling Tree

35

• Tree node Structure
• At each node we need to store
• Pointer to sibling
• Pointer to child
• Pointer to a function that draws the object
  represented by the node
• Homogeneous coordinate matrix to multiply on the
  right of the current model-view matrix
• Represents changes going from parent to node
• In OpenGL this matrix is a 1D array storing
  matrix by columns

36

• C Definition of treenode
• typedef struct treenode
• Glfloat m16
• void (f)()
• struct treenode sibling
• struct treenode child
• treenode

37

• Defining the torso node
• treenode torso_node, head_node, lua_node,
• / use OpenGL functions to form matrix /
• glLoadIdentity()
• glRotatef(theta0, 0.0, 1.0, 0.0)
• / move model-view matrix to m /
• glGetFloatv(GL_MODELVIEW_MATRIX, torso_node.m)
• torso_node.f torso / torso() draws torso /
• Torso_node.sibling NULL
• Torso_node.child head_node

38

• Notes
• The position of figure is determined by 11 joint
  angles stored in theta11
• Animate by changing the angles and redisplaying
• We form the required matrices using glRotate and
  glTranslate
• More efficient than software
• Because the matrix is formed in model-view
  matrix, we may want to first push original
  model-view matrix on matrix stack

39

• Preorder Traversal
• 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)

40

• Notes
• We must save model view matrix before multiplying
  it by node matrix
• Updated matrix applies to children of node but
  not to siblings which contain their own matrices
• The traversal program applies to any left-child
  right-sibling tree
• The particular tree is encoded in the definition
  of the individual nodes
• The order of traversal matters because of
  possible state changes in the functions

41

• Dynamic Trees
• If we use pointers, the structure can be dynamic
• typedef treenode tree_ptr
• tree_ptr torso_ptr
• torso_ptr malloc(sizeof(treenode))
• Definition of nodes and traversal are essentially
  the same as before but we can add and delete
  nodes during execution

42
6. Animation

• This section discusses basic animation
• It then introduces kinematics and inverse
  kinematics.

43
7. Graphical Objects

• Limitations of Immediate Mode Graphics
• When we define a geometric object in an
  application, upon execution of the code the
  object is passed through the pipeline
• It then disappears from the graphical system
• To redraw the object, either changed or the same,
  we must reexecute the code
• Display lists provide only a partial solution to
  this problem

44
7.1 Methods, Attributes, and Messages

• OpenGL and Objects
• OpenGL lacks an object orientation
• Consider, for example, a green sphere
• We can model the sphere with polygons or use
  OpenGL quadrics
• Its color is determined by the OpenGL state and
  is not a property of the object
• Defies our notion of a physical object
• We can try to build better objects in code using
  object-oriented languages/techniques

45

• Imperative Programming Model
• Example rotate a cube
• The rotation function must know how the cube is
  represented
• Vertex list
• Edge list

cube data
Application
glRotate
results
46

• Object-Oriented Programming Model
• In this model, the representation is stored with
  the object
• The application sends a message to the object
• The object contains functions (methods) which
  allow it to transform itself

Application
Cube Object
message
47

• C/C
• Can try to use C structs to build objects
• C provides better support
• Use class construct
• Can hide implementation using public, private,
  and protected members in a class
• Can also use friend designation to allow classes
  to access each other

48
7.2 A Cube Object

• Suppose that we want to create a simple cube
  object that we can scale, orient, position and
  set its color directly through code such as
• cube mycube
• mycube.color01.0
• mycube.color1mycube.color20.0
• mycube.matrix00

49

• Cube Object Functions
• We would also like to have functions that act on
  the cube such as
• mycube.translate(1.0, 0.0,0.0)
• mycube.rotate(theta, 1.0, 0.0, 0.0)
• setcolor(mycube, 1.0, 0.0, 0.0)
• We also need a way of displaying the cube
• mycube.render()

50

• Building the Cube Object
• class cube
• public
• float color3
• float matrix44
• // public methods
• private
• // implementation

51
7.3 Implementing the Cube Object

• Can use any implementation in the private part
  such as a vertex list
• The private part has access to public members and
  the implementation of class methods can use any
  implementation without making it visible
• Render method is tricky but it will invoke the
  standard OpenGL drawing functions such as glVertex

52
7.5 Geometric Objects

• Suppose that we now want to build an
  object-oriented graphics systems.
• What objects should we include?
• Points, vectors, polygons, rectangles, and
  triangles

53

• Other objects have geometric aspects
• Cameras
• Light sources
• But we should be able to have non-geometric
  objects too
• Materials
• Colors
• Transformations (matrices)

54

• Application Code
• cube mycube
• material plastic
• mycube.setMaterial(plastic)
• camera frontView
• frontView.position(x ,y, z)

55

• Light Object
• class light // match Phong model
• public
• boolean type //ortho or perspective
• boolean near
• float position3
• float orientation3
• float specular3
• float diffuse3
• float ambient3

56
8. Scene Graphs

• If we recall figure model, we saw that
• We could describe model either by tree or by
  equivalent code
• We could write a generic traversal to display
• If we can represent all the elements of a scene
  (cameras, lights,materials, geometry) as C
  objects, we should be able to show them in a tree
• Render scene by traversing this tree

57
(No Transcript)
58

• Preorder Traversal
• glPushAttrib
• glPushMatrix
• glColor
• glTranslate
• glRotate
• Object1
• glTranslate
• Object2
• glPopMatrix
• glPopAttrib

59

• Separator Nodes
• Necessary to isolate state changes
• Equivalent to OpenGL Push/Pop
• Note that as with the figure model
• We can write a universal traversal algorithm
• The order of traversal can matter
• If we do not use the separator node, state
  changes can propagate

60

• Inventor and Java3D
• Inventor and Java3D provide a scene graph API
• Scene graphs can also be described by a file
  (text or binary)
• Implementation independent way of transporting
  scenes
• Supported by scene graph APIs
• However, primitives supported should match
  capabilities of graphics systems
• Hence most scene graph APIs are built on top of
  OpenGL or DirectX (for PCs)

61

• VRML
• Want to have a scene graph that can be used over
  the World Wide Web
• Need links to other sites to support distributed
  data bases
• Virtual Reality Markup Language
• Based on Inventor data base
• Implemented with OpenGL

62
9. A Simple Scene Graph API

• In this section the author develops a scene graph
  API
• Geometry Nodes
• Cameras
• Lights and Materials
• Transformations

63
10. Scene Graph

• There are full scene graph APIs out there
• Open Scene Graph (OSG)
• Open SG

64
11. Graphics and the Web

• The world wide web has had an enormous effect on
  virtually all communications and computer
  applications.
• This section takes a graphics-oriented approach
  to see what extensions are needed to develop web
  applications.
• Protocols, HTML, VRML, Java and applets are
  discussed.

65
12. Other Tree Structures

• The polygonal representations of objects that we
  have used has many strengths and a few
  weaknesses.
• This section covers other representations that
  attempt to deal with those weaknesses
• CSG Trees
• Shade Trees
• BSP Trees
• Quadtrees and Octrees

66
Summary and Notes

• The speed at which modern hardware can render
  geometric objects has opened up the possibilities
  of a variety of modeling systems.
• As users of computer graphics, we need a large
  arsenal of techniques f we are to make full use
  of our graphics systems.

67

• We have presented the basic themes that apply to
  most approaches to modeling.
• One is the use of hierarchy to incorporate
  relationships among objects in a scene.
• We have seen that we can use fundamental data
  structures, such as trees and DAGs, to represent
  such relationships
• And traversing these data structures becomes part
  of the rendering process.

68
Suggested Readings

• Hierarchical transformations through the use of a
  matrix stack were described in the graphics
  literature almost 30 years ago New83.
• The PHIGS API ANSI88 was the first to
  incorporate them as part of a standard package.
• Scene graphs are the heart of Open Inventor
  Wer94.
• The Open Inventor database format was the basis
  for VRML Har96

69
Exercises -- Due next class