OpenSceneGraph Quick Start Guide 15 Spatial organization-The scene graph tree structure lends itself naturally to intuitive spatial organization. Culling-View frustum and occlusion culling on the host CPU typically reduces overall system load by not processing geometry that doesn't appear in the final rendered image. LOD-Viewer-object distance computation on bounding geometry allows objects to be efficiently rendered at varying levels of detail.Furthermore,portions of a scene can load from disk when they are within a specified viewer distance range,and deleted from memory when they are beyond that distance. Translucency-Correct and efficient rendering of translucent(non-opaque) geometry requires all translucent geometry to render after all opaque geometry. Furthermore,translucent geometry should be sorted by depth and rendered in back-to-front order.These operations are commonly supported by scene graphs. State change minimization-To maximize application performance,redundant and unnecessary state changes should be avoided.Scene graphs commonly sort geometry by state to minimize state changes,and OpenSceneGraph's state management facilities eliminate redundant state changes. File I/O-Scene graphs are an effective tool for reading and writing 3D data from disk.Once loaded into memory,the internal scene graph data structure allows the application to easily manipulate dynamic 3D data.Scene graphs can be an effective intermediary for converting from one file format to another Additional high-level functionality-Scene graph libraries commonly provide high-level functionality beyond that typically found in low-level APIs,such as full-featured text support,support for rendering effects(such as particle effects and shadows),rendering optimizations,3D model file I/O support,and cross- platform access to input devices and render surfaces. Nearly all 3D applications require some of these features.As a result,developers who build their application directly on low-level APIs typically resort to implementing many of these features in their application,which increases development costs.Using an off-the-shelf scene graph that already fully supports such features enables rapid application development. 1.5.2 How Scene Graphs Render A trivial scene graph implementation allows applications to store geometry and execute a draw traversal,during which all geometry stored in the scene graph is sent to the hardware as OpenGL commands.However,such an implementation lacks many of the features described in the previous section.To allow for dynamic geometry updates,culling,sorting, and efficient rendering,scene graphs typically provide more than a simple draw traversal. In general,there are three types of traversals:
OpenSceneGraph Quick Start Guide 15 • Spatial organization—The scene graph tree structure lends itself naturally to intuitive spatial organization. • Culling—View frustum and occlusion culling on the host CPU typically reduces overall system load by not processing geometry that doesn’t appear in the final rendered image. • LOD—Viewer-object distance computation on bounding geometry allows objects to be efficiently rendered at varying levels of detail. Furthermore, portions of a scene can load from disk when they are within a specified viewer distance range, and deleted from memory when they are beyond that distance. • Translucency—Correct and efficient rendering of translucent (non-opaque) geometry requires all translucent geometry to render after all opaque geometry. Furthermore, translucent geometry should be sorted by depth and rendered in back-to-front order. These operations are commonly supported by scene graphs. • State change minimization—To maximize application performance, redundant and unnecessary state changes should be avoided. Scene graphs commonly sort geometry by state to minimize state changes, and OpenSceneGraph’s state management facilities eliminate redundant state changes. • File I/O—Scene graphs are an effective tool for reading and writing 3D data from disk. Once loaded into memory, the internal scene graph data structure allows the application to easily manipulate dynamic 3D data. Scene graphs can be an effective intermediary for converting from one file format to another. • Additional high-level functionality—Scene graph libraries commonly provide high-level functionality beyond that typically found in low-level APIs, such as full-featured text support, support for rendering effects (such as particle effects and shadows), rendering optimizations, 3D model file I/O support, and crossplatform access to input devices and render surfaces. Nearly all 3D applications require some of these features. As a result, developers who build their application directly on low-level APIs typically resort to implementing many of these features in their application, which increases development costs. Using an off-the-shelf scene graph that already fully supports such features enables rapid application development. 1.5.2 How Scene Graphs Render A trivial scene graph implementation allows applications to store geometry and execute a draw traversal, during which all geometry stored in the scene graph is sent to the hardware as OpenGL commands. However, such an implementation lacks many of the features described in the previous section. To allow for dynamic geometry updates, culling, sorting, and efficient rendering, scene graphs typically provide more than a simple draw traversal. In general, there are three types of traversals:
16 An Overview of Scene Graphs and OpenSceneGraph Update-The update traversal(sometimes referred to as the application traversal) allows the application to modify the scene graph,which enables dynamic scenes. Updates are accomplished either directly by the application or with callback functions assigned to nodes within the scene graph.Applications use the update traversal to modify the position of a flying aircraft in a flight simulation,for example,or to allow user interaction using input devices. ● Cull-During the cull traversal,the scene graph library tests the bounding volumes of all nodes for inclusion in the scene.If a leaf node is within the view, the scene graph library adds a reference to the leaf node geometry to a final rendering list.This list is sorted by opaque versus translucent,and translucent geometry is further sorted by depth. Draw-In the draw traversal (sometimes referred to as the render traversal),the scene graph traverses the list of geometry created during the cull traversal and issues low-level graphics API calls to render that geometry. Figure 1-8 illustrates these traversals. 屋 (a (b) (c) Figure 1-8 Scene graph traversals Rendering a scene graph typically requires three traversals.In(a),the update traversal modifies geometry,rendering state,or node parameters to ensure the scene graph is up-to-date for the current frame.In(b),the cull traversal checks for visibility,and places geometry and state references in a new structure(called the render graph in OSG).In (c),the draw traversal traverses the render graph and issues drawing commands to the graphics hardware. Typically,these three traversals are executed once for each rendered frame.However, some rendering situations require multiple simultaneous views of the same scene.Stereo rendering and multiple display systems are two examples.In these situations,the update traversal is executed once per frame,but the cull and draw traversals execute once per view per frame.(That's twice per frame for simple stereo rendering,and once per graphics card per frame on multiple display systems.)This allows systems with multiple processors and graphics cards to process the scene graph in parallel.The cull traversal must be a read-only operation to allow for multithreaded access
16 An Overview of Scene Graphs and OpenSceneGraph • Update—The update traversal (sometimes referred to as the application traversal) allows the application to modify the scene graph, which enables dynamic scenes. Updates are accomplished either directly by the application or with callback functions assigned to nodes within the scene graph. Applications use the update traversal to modify the position of a flying aircraft in a flight simulation, for example, or to allow user interaction using input devices. • Cull—During the cull traversal, the scene graph library tests the bounding volumes of all nodes for inclusion in the scene. If a leaf node is within the view, the scene graph library adds a reference to the leaf node geometry to a final rendering list. This list is sorted by opaque versus translucent, and translucent geometry is further sorted by depth. • Draw—In the draw traversal (sometimes referred to as the render traversal), the scene graph traverses the list of geometry created during the cull traversal and issues low-level graphics API calls to render that geometry. Figure 1-8 illustrates these traversals. Figure 1-8 Scene graph traversals Rendering a scene graph typically requires three traversals. In (a), the update traversal modifies geometry, rendering state, or node parameters to ensure the scene graph is up-to-date for the current frame. In (b), the cull traversal checks for visibility, and places geometry and state references in a new structure (called the render graph in OSG). In (c), the draw traversal traverses the render graph and issues drawing commands to the graphics hardware. Typically, these three traversals are executed once for each rendered frame. However, some rendering situations require multiple simultaneous views of the same scene. Stereo rendering and multiple display systems are two examples. In these situations, the update traversal is executed once per frame, but the cull and draw traversals execute once per view per frame. (That’s twice per frame for simple stereo rendering, and once per graphics card per frame on multiple display systems.) This allows systems with multiple processors and graphics cards to process the scene graph in parallel. The cull traversal must be a read-only operation to allow for multithreaded access
OpenSceneGraph Quick Start Guide 17 1.6 Overview of OpenSceneGraph OSG is a set of open source libraries that primarily provide scene management and graphics rendering optimization functionality to applications.It's written in portable ANSI C++and uses the industry standard OpenGL low-level graphics API.As a result,OSG is cross platform and runs on Windows,Mac OS X,and most varieties of UNIX and Linux operating systems.Most of OSG operates independently of the native windowing system. OSG includes code to support some windowing system specific functionality,such as PBuffers,however. OSG is open source,and is available under a modified GNU Lesser General Public License,or Librury GPL(LGPL)software license.OSG's open source nature has many benefits: Improved quality-OSG is reviewed,tested,and improved by many members of the OSG community.Over 200 developers contributed to OSG v1.2. Improved application quality-To produce quality applications,application developers need intimate knowledge of the underlying middleware.If the middleware is closed source,this information is effectively blocked and limited to vendor documentation and customer support.Open source allows application developers to review and debug middleware source code,which allows free access to code internals Reduced cost-Open source is free,eliminating the up-front purchase price. No intellectual property issues-There is no way to hide software patent violations in code that is open source and easily readable by all. OSG support is easy to find by subscribing to the osg-users email list or by contracting with professional support.For more information,see the Appendix,Where to Go From Here. 1.6.1 Design and Architecture OSG is designed up front for portability and scalability.As a result,it is useful on a wide variety of platforms,and renders efficiently on a large number and variety of graphics hardware.OSG is designed to be both flexible and extensible to allow adaptive development over time.As a result,OSG is able to meet customer needs as they arise. To enable these design criteria,OSG is built with the following concepts and tools: ·ANSI standard C++. .C++Standard Template Library (STL)
OpenSceneGraph Quick Start Guide 17 1.6 Overview of OpenSceneGraph OSG is a set of open source libraries that primarily provide scene management and graphics rendering optimization functionality to applications. It’s written in portable ANSI C++ and uses the industry standard OpenGL low-level graphics API. As a result, OSG is cross platform and runs on Windows, Mac OS X, and most varieties of UNIX and Linux operating systems. Most of OSG operates independently of the native windowing system. OSG includes code to support some windowing system specific functionality, such as PBuffers, however. OSG is open source, and is available under a modified GNU Lesser General Public License, or Library GPL (LGPL) software license. OSG’s open source nature has many benefits: • Improved quality—OSG is reviewed, tested, and improved by many members of the OSG community. Over 200 developers contributed to OSG v1.2. • Improved application quality—To produce quality applications, application developers need intimate knowledge of the underlying middleware. If the middleware is closed source, this information is effectively blocked and limited to vendor documentation and customer support. Open source allows application developers to review and debug middleware source code, which allows free access to code internals • Reduced cost—Open source is free, eliminating the up-front purchase price. • No intellectual property issues—There is no way to hide software patent violations in code that is open source and easily readable by all. OSG support is easy to find by subscribing to the osg-users email list or by contracting with professional support. For more information, see the Appendix, Where to Go From Here. 1.6.1 Design and Architecture OSG is designed up front for portability and scalability. As a result, it is useful on a wide variety of platforms, and renders efficiently on a large number and variety of graphics hardware. OSG is designed to be both flexible and extensible to allow adaptive development over time. As a result, OSG is able to meet customer needs as they arise. To enable these design criteria, OSG is built with the following concepts and tools: • ANSI standard C++. • C++ Standard Template Library (STL)
18 An Overview of Scene Graphs and OpenSceneGraph .Design patterns.[Gamma95] These tools allow developers using OSG to develop on the platform of their choice and deploy on any platform the customer requires. 1.6.2 Naming Conventions The following list enumerates the naming conventions used by the OSG source code. These conventions are not always strictly enforced.The OSG plugins contain many convention violations,for example. Namespaces-OSG namespace names start with a lower-case letter,but can be upper case for clarity.Examples:osg,osgSim,osgFX. Classes-OSG class names start with an upper case letter.If the class name is composed of multiple words,each word starts with an upper-case letter. Examples:MatrixTransform,Node Visitor,Optimizer. ● Class methods-Names of methods within an OSG class start with a lower-case letter.If the method name is composed of multiple words,each additional word starts with an upper-case letter.Examples:addDrawable0,getNumChildren(, setAttributeAndModes(). ● Class member variables-Names of member variables within a class use the same convention as method names. ● Templates-OSG template names are lower case with multiple words separated by underscores.Examples:ref_ptr<>,graph_array<>,observer_ptr<>. Statics-Static variables and functions begin with s and otherwise use the same naming conventions as class member variables and methods.Examples: s applicationUsage,a ArrayNames0. Globals-Global class instances begin with g.Examples:g NotifLerel, greaderWV riter_BMP_Proxy. 1.6.3 Components The OSG runtime exists as a set of dynamically loaded libraries (or shared objects)and executables.These libraries fall into five conceptual categories: The Core OSG libraries provide essential scene graph and rendering functionality,as well as additional functionality typically required by 3D graphics applications. NodeKits extend the functionality of core OSG scene graph node classes to provide higher-level node types and special effects. OSG plugins are libraries that read and write 2D image and 3D model files
18 An Overview of Scene Graphs and OpenSceneGraph • Design patterns. [Gamma95] These tools allow developers using OSG to develop on the platform of their choice and deploy on any platform the customer requires. 1.6.2 Naming Conventions The following list enumerates the naming conventions used by the OSG source code. These conventions are not always strictly enforced. The OSG plugins contain many convention violations, for example. • Namespaces—OSG namespace names start with a lower-case letter, but can be upper case for clarity. Examples: osg, osgSim, osgFX. • Classes—OSG class names start with an upper case letter. If the class name is composed of multiple words, each word starts with an upper-case letter. Examples: MatrixTransform, NodeVisitor, Optimizer. • Class methods—Names of methods within an OSG class start with a lower-case letter. If the method name is composed of multiple words, each additional word starts with an upper-case letter. Examples: addDrawable(), getNumChildren(), setAttributeAndModes(). • Class member variables—Names of member variables within a class use the same convention as method names. • Templates—OSG template names are lower case with multiple words separated by underscores. Examples: ref_ptr<>, graph_array<>, observer_ptr<>. • Statics—Static variables and functions begin with s_ and otherwise use the same naming conventions as class member variables and methods. Examples: s_applicationUsage, a_ArrayNames(). • Globals—Global class instances begin with g_. Examples: g_NotifyLevel, g_readerWriter_BMP_Proxy. 1.6.3 Components The OSG runtime exists as a set of dynamically loaded libraries (or shared objects) and executables. These libraries fall into five conceptual categories: • The Core OSG libraries provide essential scene graph and rendering functionality, as well as additional functionality typically required by 3D graphics applications. • NodeKits extend the functionality of core OSG scene graph node classes to provide higher-level node types and special effects. • OSG plugins are libraries that read and write 2D image and 3D model files
OpenSceneGraph Quick Start Guide 19 The interoperability libraries allow OSG to easily integrate into other environments,including scripting languages such as Python and Lua. An extensive collection of applications and examples provide useful functionality and demonstrate correct OSG usage. Figure 1-9 illustrates OSG's architectural organization.The following sections discuss these libraries in more detail. Applications Examples The OSG Introspection API The OSG API OSG Core oSG Plugins OSG NodeKits Figure 1-9 OSG architecture The Core OSG libraries provide functionality to both the application and the NodeKits. Together,the Core OSG libraries and NodeKits make up the OSG APl.One of the Core OSG libraries,osgDB,provides access to 2D and 3D file l/O by managing the OSG plugins. Core OSG Core OSG provides core scene graph functionality,classes,and methods for operating on the scene graph,additional application functionality typically required by 3D graphics applications,and access to the OSG plugins for 2D and 3D file I/O.It consists of four libraries: The osg library-This library contains the scene graph node classes that your application uses to build scene graphs.It also contains classes for vector and matrix math,geometry,and rendering state specification and management.Other classes in osg provide additional functionality typically required by 3D applications,such as argument parsing,animation path management,and error and warning communication
OpenSceneGraph Quick Start Guide 19 • The interoperability libraries allow OSG to easily integrate into other environments, including scripting languages such as Python and Lua. • An extensive collection of applications and examples provide useful functionality and demonstrate correct OSG usage. Figure 1-9 illustrates OSG’s architectural organization. The following sections discuss these libraries in more detail. Figure 1-9 OSG architecture The Core OSG libraries provide functionality to both the application and the NodeKits. Together, the Core OSG libraries and NodeKits make up the OSG API. One of the Core OSG libraries, osgDB, provides access to 2D and 3D file I/O by managing the OSG plugins. Core OSG Core OSG provides core scene graph functionality, classes, and methods for operating on the scene graph, additional application functionality typically required by 3D graphics applications, and access to the OSG plugins for 2D and 3D file I/O. It consists of four libraries: • The osg library—This library contains the scene graph node classes that your application uses to build scene graphs. It also contains classes for vector and matrix math, geometry, and rendering state specification and management. Other classes in osg provide additional functionality typically required by 3D applications, such as argument parsing, animation path management, and error and warning communication