Data Structures for Scenes, The Basics of Scene Graphs Glenn G. Chappell U. of Alaska Fairbanks CS 481/681 Lecture Notes Friday, January 23, 2004

23 Jan 2004CS 481/6812 Review: More on Drawable Objects We have discussed deriving various classes of drawable objects from a base class Drawable. This makes it convenient to deal with drawable objects without knowing much about them. Thus new kinds of objects can be added to a program without altering existing drawing code. And all objects can be stored together in one big container. But watch out for that last one. These are no good: Drawable scenearray[MAX_DRAWABLES]; std::vector scenevec; But this is fine: std::vector scenevec; If you do this, make sure you handle allocation & deallocation properly!

23 Jan 2004CS 481/6813 Review: Hierarchical Objects [1/3] By a hierarchical object we mean a (moving) object with moving parts (that have moving subparts that have moving subsubparts …). We can implement hierarchical objects conveniently using the OpenGL matrix stacks, as long as we follow a few rules. Draw all objects in “standard position”. Handle model/view properly. Details on the next slide …

23 Jan 2004CS 481/6814 Review: Hierarchical Objects [2/3] A function that draws an object should draw it with a “standard” position and orientation. For example, in face.cpp, all object-drawing functions draw the object upright, centered at the origin, and fitting (roughly) within the square in which x & y lie between –1 and 1. A function that draws an object should use the current model/view transformation. Thus, the actual position, orientation, and size of the object drawn by a function are determined by the function’s caller. When model/view is modified, always do a push before the modification and a pop after you are done using the modified transformation: Do glPushMatrix. Modify model/view ( glTranslate *, etc.). Use model/view (draw something). Do glPopMatrix.

23 Jan 2004CS 481/6815 Review: Hierarchical Objects [3/3] EXAMPLE TIME A program to draw a movable “robot arm” was created in class.

23 Jan 2004CS 481/6816 Data Structures for Scenes: Introduction So far, we have generally represented an object in a program by writing a function to draw it. In serious CG applications, this is almost never done. Instead, we separate data and code. We write code to draw objects of various types. This code is applied to various data structures, which might be initialized from external files. Thus, we make it easier to modify a scene. But harder to write the initial code, of course. Using some of the OO-design ideas discussed last week, we can also allow introduction of new types of data with only minimal modification of the code. If a program is to draw an arbitrary scene, then we should store the scene objects in some kind of container. Now we look at how this might be done.

23 Jan 2004CS 481/6817 Data Structures for Scenes: Talking About Trees But first, some tree terminology: Trees are made of nodes. One node is the root. The nodes (if any) attached immediately below a given node are its children. Nodes with no children are leaves. Each node (except the root) is a child of its parent. Root A A’s children A’s parent Leaves are shown in green.

23 Jan 2004CS 481/6818 Data Structures for Scenes: Scene Containers [1/2] A scene could be stored as a linear sequence (array, vector, list) of objects. However, most often we store scenes in some kind of tree-like structure. Why? Scenes often have a natural hierarchical structure, and trees are good for representing hierarchies. Partial traversal of a tree can sometimes give us a good “approximation” of a scene. For example, have general shapes high in the tree and details lower in the tree. Then we can draw at a coarse level of detail by ignoring all nodes below a certain level. Some tree structures allow fast queries of various sorts. For example, “Am I inside an object?”. More on this later. Finding a node in a tree is fast (if the tree is reasonably balanced and has a structure that facilitates searching). Tree traversal is just about as fast as list traversal, so there is little performance penalty.

23 Jan 2004CS 481/6819 Data Structures for Scenes: Scene Containers [2/2] There are many types of tree-like structures for holding scenes. Some of the ways they vary: Trees can be organized by how the scene is constructed (scene graphs, CSG trees) or by spatial relationships of the parts (BPS trees, quadtrees & octrees). The former helps deal with transformations & such conveniently. The latter gets us quick answers to questions like “Am I inside an object?” “What is the nearest object?” or helps do certain operations like HSR efficiently. The order in which children are listed can have various meanings (BSP trees, quadtrees & octrees) or no meaning (scene graphs). Numbers of children can vary. E.g., in an octree, each node can have up to 8 children. Are objects stored in all nodes or just in leaves? What objects does the tree hold? Polygons? General drawable objects?

23 Jan 2004CS 481/68110 Data Structures for Scenes: Four Data Structures We will discuss four types of trees for holding scenes: Scene Graphs Organized by how the scene is constructed. Nodes hold objects. CSG Trees Organized by how the scene is constructed. Leaves hold 3-D primitives. Internal nodes hold set operations. BSP Trees Organized by spatial relationships in the scene. Nodes hold facets (in 3-D, polygons). Quadtrees & Octrees Organized spatially. Nodes represent regions in space. Leaves hold objects.

23 Jan 2004CS 481/68111 The Basics of Scene Graphs: Introduction We have already discussed (informally) a tree structure for holding a hierarchical object. The organization is based on the composition of the object. It helps us deal with transformations (and moving parts with moving subparts …) conveniently. This structure is a simple example of what is called a scene graph.

23 Jan 2004CS 481/68112 The Basics of Scene Graphs: Structure Structure of a (simple) scene graph: Each node corresponds to a drawable object. The children of a given node correspond to “parts” of the object; these may be movable. Thus, each node has a transformation. It, and all of its descendants, are drawn with this transformation. The descendants have, in addition, their own transformations. Data needed in each node: Drawable object (pointer to this?). Transformation (a matrix? a pointer to a matrix? a pointer to a function that returns a matrix?). Pointers to child nodes.

23 Jan 2004CS 481/68113 The Basics of Scene Graphs: Notes In face.cpp, if we stored the face in a scene graph, it might look like this: We can add functionality to scene graphs by putting other things in them. In particular: Light sources. Other things like light sources (e.g., environment maps). Head EyeEar NoseMouth Iris Pupil Eye Iris Pupil L.R. Hair