10 An Overview of Scene Graphs and OpenSceneGraph One frame Frame Rate:60.04 Update:0.04 Cull:2.68 Draw:3.05 GPU:1.87 Cull Draw Figure 1-4 The traversal time graphical display This shows a typical traversal time display for an application synchronized with a 60Hz monitor.The time spent in the update traversal,0.04 milliseconds,is so insignificant that it doesn't appear in the graphical display.However,the cull and draw traversals,at 2.68 and 3.05 milliseconds respectively,display clearly as cyan and dark yellow bars spanning part of a single frame.The text output also indicates that the GPU takes 1.87 milliseconds to process the rendering commands,as measured by OpenGL. The graphical display represents a series of rendered frames.Typically,rendering is synchronized to the monitor refresh rate to avoid rendering artifacts such as image tearing. In Figure 1-4,the monitor refresh rate is 60Hz,so each frame occupies 1/60th of a second, or about 16.67 milliseconds.This display illustrates how much time is spent in the update, cull,and draw traversals.This feedback is essentially for analyzing performance problems to help determine the rendering stage of any application performance bottlenecks. 1.3.5 Recording an Animation Developers require repeatable test cases to effectively tune and measure application rendering performance.To facilitate performance tuning,osgviewer allows you to easily record a camera motion sequence and play it back.This sequence is called an animation path. While osgviewer is running,press thez'key.This causes osgviewer to immediately begin recording an animation path.Rotate the model and zoom in or out using the mouse;OSG records all camera movements.Finally,press the Z'(shift-z)key.This stops recording the animation path,and immediately plays it back.This will show you every camera motion made while the path was being recorded. Exit osgviewer with the Escape key,and get a list of files in your current directory.You will see a new file,saved_animation.path.As its name implies,this file contains the recorded animation path.osgviewer wrote this file out when you hit the Z'key.To play the animation path,issue the following command: osgviewer -p saved_animation.path cow.osg When playing an animation path,osgviewer displays the elapsed time for the sequence to std::cout.If osgviewer doesn't display this information in your shell,press Escape to exit osgviewer.Set the OSG_NOTIFY_LEVEL environment variable to INFO and restart osgviewer
10 An Overview of Scene Graphs and OpenSceneGraph Figure 1-4 The traversal time graphical display This shows a typical traversal time display for an application synchronized with a 60Hz monitor. The time spent in the update traversal, 0.04 milliseconds, is so insignificant that it doesn’t appear in the graphical display. However, the cull and draw traversals, at 2.68 and 3.05 milliseconds respectively, display clearly as cyan and dark yellow bars spanning part of a single frame. The text output also indicates that the GPU takes 1.87 milliseconds to process the rendering commands, as measured by OpenGL. The graphical display represents a series of rendered frames. Typically, rendering is synchronized to the monitor refresh rate to avoid rendering artifacts such as image tearing. In Figure 1-4, the monitor refresh rate is 60Hz, so each frame occupies 1/60th of a second, or about 16.67 milliseconds. This display illustrates how much time is spent in the update, cull, and draw traversals. This feedback is essentially for analyzing performance problems to help determine the rendering stage of any application performance bottlenecks. 1.3.5 Recording an Animation Developers require repeatable test cases to effectively tune and measure application rendering performance. To facilitate performance tuning, osgviewer allows you to easily record a camera motion sequence and play it back. This sequence is called an animation path. While osgviewer is running, press the ‘z’ key. This causes osgviewer to immediately begin recording an animation path. Rotate the model and zoom in or out using the mouse; OSG records all camera movements. Finally, press the ‘Z’ (shift-z) key. This stops recording the animation path, and immediately plays it back. This will show you every camera motion made while the path was being recorded. Exit osgviewer with the Escape key, and get a list of files in your current directory. You will see a new file, saved_animation.path. As its name implies, this file contains the recorded animation path. osgviewer wrote this file out when you hit the ‘Z’ key. To play the animation path, issue the following command: osgviewer –p saved_animation.path cow.osg When playing an animation path, osgviewer displays the elapsed time for the sequence to std::cout. If osgviewer doesn’t display this information in your shell, press Escape to exit osgviewer. Set the OSG_NOTIFY_LEVEL environment variable to INFO and restart osgviewer
OpenSceneGraph Quick Start Guide 11 1.4 Compiling OSG Applications To build OSG-based applications,you need an OSG development environment consisting of header files and libraries.The OSG runtime binary distributions contain header files and optimized libraries.To create debuggable libraries,download and build the OSG and Open'Threads source code.Obtain both OSG and OpenThreads source from the OSG Wiki Web site [OSGWikil,Downloads section.The OSG Wiki Web site contains instructions for how to build OSG. To successfully compile an OSG-based application,you must set the correct include file paths so that the compiler can find the necessary header files.Add the following two directories to the compiler's include search path <parent>/OpenSceneGraph/include <parent>/OpenThreads/include Replace <parent>with the top-level directory where you installed both OpenSceneGraph and OpenThreads.On a Linux system using gcc,specify these include paths with the-I command line option.<parent>is uaually /usr/local/include on a Linux system,so the include paths on a gcc command line appear as follows. -I/use/local/include/OpenSceneGraph/include -I/usr/local/include/OpenThreads/include In Microsoft Visual Studio,add the appropriate directories as Additional Include Directories in the Project Properties dialog,C/C++options. Similarly,you need to tell the linker where to fnd the OSG libraries.On Linux systems, OSG libraries reside in /usr/local/lib,and the linker can find them there without use of the-L option. The Microsoft Visual Studio build leaves libraries in the following two source code tree directories. <parent>/OpenSceneGraph/lib/win32 <parent>/OpenThreads/lib/win32 Add these directories as Additional Library Directories in the Project Properties dialog, Linker options. Finally,tell the linker which OSG libraries to link with.As section 1.6.3 Components describes,OSG is made up of several different libraries,each providing different functionality.For a simple OSG-based application using the osgViewer,osgDB,osgUtil, and osg libraries,the gcc command line looks like the following. -losgViewer -losgDB -losgUtil -losg
OpenSceneGraph Quick Start Guide 11 1.4 Compiling OSG Applications To build OSG-based applications, you need an OSG development environment consisting of header files and libraries. The OSG runtime binary distributions contain header files and optimized libraries. To create debuggable libraries, download and build the OSG and OpenThreads source code. Obtain both OSG and OpenThreads source from the OSG Wiki Web site [OSGWiki], Downloads section. The OSG Wiki Web site contains instructions for how to build OSG. To successfully compile an OSG-based application, you must set the correct include file paths so that the compiler can find the necessary header files. Add the following two directories to the compiler’s include search path. <parent>/OpenSceneGraph/include <parent>/OpenThreads/include Replace <parent> with the top-level directory where you installed both OpenSceneGraph and OpenThreads. On a Linux system using gcc, specify these include paths with the –I command line option. <parent> is uaually /usr/local/include on a Linux system, so the include paths on a gcc command line appear as follows. -I/use/local/include/OpenSceneGraph/include -I/usr/local/include/OpenThreads/include In Microsoft Visual Studio, add the appropriate directories as Additional Include Directories in the Project Properties dialog, C/C++ options. Similarly, you need to tell the linker where to fnd the OSG libraries. On Linux systems, OSG libraries reside in /usr/local/lib, and the linker can find them there without use of the –L option. The Microsoft Visual Studio build leaves libraries in the following two source code tree directories. <parent>/OpenSceneGraph/lib/win32 <parent>/OpenThreads/lib/win32 Add these directories as Additional Library Directories in the Project Properties dialog, Linker options. Finally, tell the linker which OSG libraries to link with. As section 1.6.3 Components describes, OSG is made up of several different libraries, each providing different functionality. For a simple OSG-based application using the osgViewer, osgDB, osgUtil, and osg libraries, the gcc command line looks like the following. -losgViewer –losgDB –losgUtil –losg
12 An Overview of Scene Graphs and OpenSceneGraph In Microsoft Visual Studio,add the library file names as Additional Dependencies in the Project Property dialog,Linker options.Under Microsoft Windows,OSG builds debug and release libraries with different names.For a release build,add the following library file names. libosgViewer.lib libosgDB.lib libosgUtil.lib libosg.lib For a debug build,insert'd'before the file extension. libosgViewerd.lib libosgDBd.lib libosgUtild.lib libosgd.lib These libraries are an example,and the actually libraries your application links with depends on what OSG functionality your application uses.You might need to link with other libraries,such as the osgText,osgShadow,and osgGA libraries. All this is handled for you on a Mac OS X system if you simply tell Xcode to use the OSG framework. If you fail to configure the compiler and linker with the correct options,your application build fails with errors such as"unable to open include file,""unable to find library file," and "unresolved symbol."If you encounter any of these errors,examine the error message Top Node Terrain Node Cow Node Truck Node Figure 1-5 A simple,abstract scene graph To render a scene consisting of terrain,a cow,and a truck,the scene graph takes the form of a top-level node with three child nodes.Each child node contains the geometry to draw its object
12 An Overview of Scene Graphs and OpenSceneGraph In Microsoft Visual Studio, add the library file names as Additional Dependencies in the Project Property dialog, Linker options. Under Microsoft Windows, OSG builds debug and release libraries with different names. For a release build, add the following library file names. libosgViewer.lib libosgDB.lib libosgUtil.lib libosg.lib For a debug build, insert ‘d’ before the file extension. libosgViewerd.lib libosgDBd.lib libosgUtild.lib libosgd.lib These libraries are an example, and the actually libraries your application links with depends on what OSG functionality your application uses. You might need to link with other libraries, such as the osgText, osgShadow, and osgGA libraries. All this is handled for you on a Mac OS X system if you simply tell Xcode to use the OSG framework. If you fail to configure the compiler and linker with the correct options, your application build fails with errors such as “unable to open include file,” “unable to find library file,” and “unresolved symbol.” If you encounter any of these errors, examine the error message Figure 1-5 A simple, abstract scene graph To render a scene consisting of terrain, a cow, and a truck, the scene graph takes the form of a top-level node with three child nodes. Each child node contains the geometry to draw its object
OpenSceneGraph Quick Start Guide 13 closely and verify that you've specified the correct compiler and linker options. 1.5 Introduction to Scene Graphs The previous sections focus on where OSG came from and how to install and run it on your system.If you've followed the instructions in this chapter so far,you've succeeded in creating a few interesting images on your screen using OSG.The rest of this book explores OSG in increasing depth.The current section describes scene graphs at the conceptual level.Section 1.6 Overview of OpenSceneGraph provides a high-level overview of OSG's feature set.Finally,Chapter 2,Building a Scene Graph,and Chapter 3,Using OpenSceneGraph in Your Application,describe portions of OSG's application interface. A scene graph is a hierarchical tree data structure that organizes spatial data for efficient rendering.Figure 1-5 illustrates an abstract scene graph consisting of terrain,a cow,and a truck. The scene graph tree is headed by a top-level root node.Beneath the root node,group nodes organize geometry and the rendering state that controls their appearance.Root nodes and group nodes can have zero or more children.(However,group nodes with zero children are essentially no-ops.)At the bottom of the scene graph,leaf nodes contain the actual geometry that makes up the objects in the scene. Applications use group nodes to organize and arrange geometry in a scene.Imagine a 3D database containing a room with a table and two identical chairs.You could organize a scene graph for this database in many ways.Figure 1-6 shows one example organization. The root node has four group node children,one for the room geometry,one for the Scene Chair Chair Table Room Chair Table Figure 1-6 A typical scene graph Group nodes can have several children,and allow applications to logically organize geometric and state data.In this case,the two chair group nodes translate their single child to two different locations,producing the appearance of two chairs
OpenSceneGraph Quick Start Guide 13 closely and verify that you’ve specified the correct compiler and linker options. 1.5 Introduction to Scene Graphs The previous sections focus on where OSG came from and how to install and run it on your system. If you’ve followed the instructions in this chapter so far, you’ve succeeded in creating a few interesting images on your screen using OSG. The rest of this book explores OSG in increasing depth. The current section describes scene graphs at the conceptual level. Section 1.6 Overview of OpenSceneGraph provides a high-level overview of OSG’s feature set. Finally, Chapter 2, Building a Scene Graph, and Chapter 3, Using OpenSceneGraph in Your Application, describe portions of OSG’s application interface. A scene graph is a hierarchical tree data structure that organizes spatial data for efficient rendering. Figure 1-5 illustrates an abstract scene graph consisting of terrain, a cow, and a truck. The scene graph tree is headed by a top-level root node. Beneath the root node, group nodes organize geometry and the rendering state that controls their appearance. Root nodes and group nodes can have zero or more children. (However, group nodes with zero children are essentially no-ops.) At the bottom of the scene graph, leaf nodes contain the actual geometry that makes up the objects in the scene. Applications use group nodes to organize and arrange geometry in a scene. Imagine a 3D database containing a room with a table and two identical chairs. You could organize a scene graph for this database in many ways. Figure 1-6 shows one example organization. The root node has four group node children, one for the room geometry, one for the Figure 1-6 A typical scene graph Group nodes can have several children, and allow applications to logically organize geometric and state data. In this case, the two chair group nodes translate their single child to two different locations, producing the appearance of two chairs
14 An Overview of Scene Graphs and OpenSceneGraph table,and one for each chair.The chair group nodes are color-coded red to indicate that they transform their children.There is only one chair leaf node because the two chairs are identical-their parent group nodes transform the chair to two different locations to produce the appearance of two chairs.The table group node has a single child,the table leaf node.The room leaf node contains the geometry for the floor,walls,and ceiling Scene graphs usually offer a variety of different node types that offer a wide range of functionality,such as switch nodes that enable or disable their children,level of detail (LOD)nodes that select children based on distance from the viewer,and transform nodes that modify transformation state of child geometry.Object-oriented scene graphs provide this variety using inheritance;all nodes share a common base class with specialized functionality defined in the derived classes. The large variety of node types and their implicit spatial organization ability provide data storage features that are unavailable in traditional low-level rendering APIs.OpenGL and Direct3D focus primarily on abstracting features found in graphics hardware.Although graphics hardware allows storage of geometric and state data for later execution (such as display lists or buffer objects),low-level API features for spatial organization of that data are generally minimal and primitive in nature,and inadequate for the vast majority of 3D applications. Scene graphs are middleware,which are built on top of low-level APIs to provide spatial organization capabilities and other features typically required by high-performance 3D applications.Figure 1-7 illustrates a typical OSG application stack. 1.5.1 Scene Graph Features Scene graphs expose the geometry and state management functionality found in low-level rendering APIs,and also provide additional features and capabilities,such as the following: 3D Application Scene graph middleware(OpenSceneGraph) Low-level rendering API (OpenGL) Figure 1-7 The 3D application stack Rather than interface directly with the low-level rendering APl,many 3D applications require additional functionality from a middleware library,such as OpenSceneGraph
14 An Overview of Scene Graphs and OpenSceneGraph table, and one for each chair. The chair group nodes are color-coded red to indicate that they transform their children. There is only one chair leaf node because the two chairs are identical—their parent group nodes transform the chair to two different locations to produce the appearance of two chairs. The table group node has a single child, the table leaf node. The room leaf node contains the geometry for the floor, walls, and ceiling. Scene graphs usually offer a variety of different node types that offer a wide range of functionality, such as switch nodes that enable or disable their children, level of detail (LOD) nodes that select children based on distance from the viewer, and transform nodes that modify transformation state of child geometry. Object-oriented scene graphs provide this variety using inheritance; all nodes share a common base class with specialized functionality defined in the derived classes. The large variety of node types and their implicit spatial organization ability provide data storage features that are unavailable in traditional low-level rendering APIs. OpenGL and Direct3D focus primarily on abstracting features found in graphics hardware. Although graphics hardware allows storage of geometric and state data for later execution (such as display lists or buffer objects), low-level API features for spatial organization of that data are generally minimal and primitive in nature, and inadequate for the vast majority of 3D applications. Scene graphs are middleware, which are built on top of low-level APIs to provide spatial organization capabilities and other features typically required by high-performance 3D applications. Figure 1-7 illustrates a typical OSG application stack. 1.5.1 Scene Graph Features Scene graphs expose the geometry and state management functionality found in low-level rendering APIs, and also provide additional features and capabilities, such as the following: Figure 1-7 The 3D application stack Rather than interface directly with the low-level rendering API, many 3D applications require additional functionality from a middleware library, such as OpenSceneGraph