Before looking into various rendering effects and playing with carefully selected code snippets, let us first get a glimpse of the history of OpenSceneGraph, learn about its structures and capabilities, and join a web community to learn and discuss OSG online. You will also have the chance to create a "Hello World" application in OSG style, through which you will gain necessary information about OSG's syntax and structure.
In this book, OSG is short for OpenSceneGraph. It will be used from time to time to replace OpenSceneGraph's full name, for convenience.
In this chapter, we will:
Before entering the world of OpenSceneGraph, we assume that you are already experienced in OpenGL programming. You work with stacks of matrices, set pipeline states, look for new extensions, call rendering APIs or commands and immediately draw them on a context, no matter if you are enjoying or suffering from the whole process.
A rendering middleware is a solution that raises the level of abstraction and eases the complexity of using a low-level OpenGL API, at the cost of flexibility. The concepts of modularity and object-orientation are often applied to manage graphics primitives, materials, and different visual data sets in user applications, saving much development time and allowing new functionalities to be combined as modules and plugins.
OpenSceneGraph is a well-designed rendering middleware application. It is actually a retained rendering (or deferred rendering) system based on the theory of scene graph, which records rendering commands and data in a buffer, for executing at some other time. This allows the system to perform various optimizations before rendering, as well as implement a multithreaded strategy for handling complex scenes.
A scene graph is a general data structure that defines the spatial and logical relationship of a graphical scene for efficient management and rendering of graphics data. It is typically represented as a hierarchical graph, which contains a collection of graphics nodes including a top-level root node, a number of group nodes each of which can have any number of child nodes, and a set of leaf nodes each of which has zero child nodes and that serve together as the bottom layer of the tree. A typical scene graph does not allow a directed cycle (where some nodes are connected in a closed chain) or an isolated element (a node that has no child or parent) inside of itself.
Each group node can have any number of children. Grouping these child nodes allows them to share the information of the parent and be treated as one unit. By default, an operation performed by a parent propagates its effects to all of its children.
It also happens that certain nodes have more than one parent node, in which case the node is considered to be "instanced", and the scene graph can be defined as a directed acyclic graph (DAG). Instancing produces many interesting effects, including data sharing and multi-pass rendering.
The concept of scene graph has been widely applied in many modern software and applications, for instance, AutoCAD, Maya, CorelDraw, VRML, Open Inventor, and the one that we are going to investigate—OpenSceneGraph.
The OpenSceneGraph project was initiated as an avocation by Don Burns in 1998. He used to work for SGI and is a hang-gliding enthusiast. He wrote a simplified SGI Performer-like scene graph API on a humble Linux PC, named SG, which was the prototype of OSG.
In 1999, Robert Osfield, a design consultant for a hang-glider manufacturer, started to take part in this young project. He suggested continuity to develop SG as a standalone, open source project and soon ported its elements to Windows. At the end of the year, Robert took over the project and changed its name to OpenSceneGraph. The project was then fully rewritten to take advantage of C++ standards and design patterns.
In 2001, in response to the growing interest in the project, Robert set up OpenSceneGraph Professional Services. He gave up the opportunity to work for other companies, and went full-time providing both commercial and free OSG services. Don also formed his own company, Andes Computer Engineering, and continues to support the development of OSG.
The first OpenSceneGraph birds-of-a-feather (BOF) meeting occurred the same year, at SIGGRAPH 2001, with only 12 people attending. After that, attendance at the OSG BOF continues to grow every year, with more and more people getting to know this great OpenGL-based API.
The Producer library, which was initially created to provide windowing and multi-pipe graphic system integrations for customer's needs, was added, along with other two important libraries, osgText and osgFX, in 2003. Then, in 2005, OSG 1.0 was announced, to the delight of over 1,100 members in the mailing list.
In 2007, a totally new OSG 2.0 was released, with improved multi-core, multi-GPU support, and three important new libraries: osgViewer, osgManipulator, and osgShadow. From then on, the unified build system CMake was used to simplify the build process. Then the old Producer was deprecated and maintained by Andes Computer Engineering as an independent project. The first two OSG books, OpenSceneGraph Quick Start Guide and OpenSceneGraph Reference Manuals, were available, too. Paul Martz dedicated them to all developers who were new to scene graph technology.
How time flies! Years have slipped away and OSG is developing at an incredible speed all the time: osgWidget was first introduced in 2008; osgVolume and osgAnimation came out in 2009; and osgQt was born in 2010, with the coming 3.0 release and the amazing OpenGL ES and OpenGL 3.0 support.
Today, several hundred high-performance applications are using OSG to render complex scenes and manage massive datasets. With the great efforts made by 432 core contributors and the continuous support of software developers around the world, it can be anticipated that OSG has a very bright future ahead of it.
The computing infrastructure of OSG is designed to be highly scalable in order to enable runtime access to extended functionalities. In addition to the standard core libraries, a set of additional modular libraries known as NodeKits have been delivered to meet specific development requirements.
The core OSG functionality consists of four libraries:
The OpenThreads library: This library is intended to provide a minimal and complete Object-Oriented (OO) thread interface for C++ programmers. It is used by OSG as the main threading model implementation.
The osg library: This library provides basic elements used to build scene graphs, such as nodes, geometries, rendering states and textures, as well as related management tools and methods. It also contains a few necessary math classes, which are used to implement vector and matrix operations that are commonly used in two-dimensional and three-dimensional spaces.
The osgDB library: This library provides a plugin mechanism for reading and writing 2D and 3D files, with a derivable class containing access to data files and stream I/O operations. Its built-in database pager also supports dynamic loading and unloading of scene graph segments, in order to achieve the scheduling of huge collections of user data.
The osgUtil library: This library is designed for building the OSG rendering backend, which traverses the scene tree, performs culling in each frame, and finally converts the OSG scene into a series of OpenGL calls. There are also functionalities for user intersections, and polygon modification algorithms.
The extra NodeKits and utilities available with current OSG distributions are:
The osgAnimation library: This library provides a range of general purpose utilities for various animations, including skeleton and morphing. It uses generic templates to construct multiple kinds of key frames and animation channels.
The osgFX library: This library has a framework for implementing special effects in the 3D space, and contains several useful effect classes.
The osgGA library, which stands for OSG GUI abstraction: This library is an abstract user interface on top of various windowing systems. It helps to handle interactive events from peripheral devices, for example, a keyboard or mouse.
The osgManipulator library: This library extends the scene graph to support 3D interactive manipulation, such as moving, rotating, and scaling of transformable nodes.
The osgParticle library: This library makes it possible to render explosions, fire, smoke, and other particle-based effects.
The osgShadow library: This library provides a framework for various shadow rendering techniques.
The osgSim library: This library meets some special requirements from simulation systems, especially from the OpenFlight databases.
The osgTerrain library: This library provides geographic terrain rendering support using height field and imagery data.
The osgText library: This library fully supports the rendering of TypeType and a series of other font formats, based on the FreeType project. It can draw 2D and 3D texts in 3D space or on the screen.
The osgViewer library: This library defines a set of viewer-related classes, and therefore integrates OSG scene graphs and renders the backend with a wide variety of windowing systems, including Win32, X11, Carbon, and Cocoa, as well as providing indirect support for many other famous GUI toolkits.
The osgVolume library: This library includes an initial support for volume rendering techniques.
The osgWidget library: This library extends the core OSG elements and provides a 2D GUI widget set for 3D applications.
The osgQt library: This library embeds the Qt GUI into scene graphs and thus has the ability to display web pages and common Qt widgets in space.
All OSG core libraries and NodeKits, no matter what kind of features they implement or who contributed them, have the same prefix "osg", and a short word or abbreviation followed as the keyword.
The whole OSG architecture can be illustrated as follows:
In most cases, the osg, osgDB, osgUtil, and osgViewer libraries are the major components of an OSG-based application, and will be discussed in more detail in the following chapters of this book, while other less frequently used NodeKits may also be mentioned in specific chapters.
The OSG project is open sourced and released under a modified GNU Lesser General Public License (LGPL), named OSGPL. It brings about significant benefits to its users:
Rigorous structure: OSG makes full use of the Standard Template Library (STL) and multiple design patterns. It also takes advantage of the open source development model in order to provide a legacy-free and user-centric application programming interface.
Superior performance: A series of scene graph techniques are already well-implemented in OSG, including view-frustum and occlusion culling, level of detail (LOD) configuration, rendering state sorting, particle and shadow supports, and complete encapsulation of OpenGL extensions and the shader language.
High scalability: The core OSG functionalities are clean and highly extensible. This makes it easy for users to write their own NodeKits and file I/O plugins, and integrate them into scene graphs and applications.
Software and hardware portability: The core OSG is already designed to have minimal dependency on any specific platform or windowing system, requiring only Standard C++ and OpenGL. This provides great convenience in being able to rapidly port OSG-based applications to Windows, Linux, Mac OSX, FreeBSD, Solaris, and even embedded platforms.
Latest activity: With an active developer community, OSG is growing at an incredible speed. It supports the latest OpenGL and OpenGL ES extensions and various graphics concepts and techniques, along with a great deal of feedback in the development cycle.
Open source: In modern industry, open source means co-intelligence, quality and flexibility, rather than merely inexpensive. Users and companies also don't have to worry about software patent violations when using OSG in their own applications.
The following is a rough list of some of the organizations that are using or have used OSG as a development tool for their applications and products:
|
Organization name |
Download link (if downloadable) |
Purpose using OSG |
|---|---|---|
|
Boeing |
- |
Flight simulation |
|
Delta 3D |
Game engine | |
|
Flight Gear |
Flight simulation | |
|
Intra |
- |
Train simulation |
|
Magic Earth |
- |
Oil and gas probing |
|
NASA |
- |
Earth simulation |
|
Norcontrol |
- |
Maritime simulation |
|
ossimPlanet |
Geo-spatial visualization | |
|
Virtual Terrain Project |
CAD and GIS related fields | |
|
VR Juggler |
Virtual reality system |
Other customers include ESA, Landmark Graphics, Sony, STN Atlas, Northrop Grumman, and even the military sectors. To learn more about the large number of OSG-based projects and outcome, just search the whole web, and always keep in contact with developers all over the world through the web community.
Before sitting down and coding, you should have already set up an OSG development environment consisting of header files and libraries, either by obtaining a prebuilt package compliant to your compiler version, or building everything with the source code. Please refer to Chapter 2, Compilation & Installation of OpenSceneGraph for details.
Can't wait to have a taste of OSG programming? Here is the simplest example, which shows how to load an existing model file and render it on the screen. It is much more interesting than just printing a "Hello World" text on the console:
Create a new project with any source code editor:
#include <osgDB/ReadFile> #include <osgViewer/Viewer> int main( int argc, char** argv ) { osgViewer::Viewer viewer; viewer.setSceneData( osgDB::readNodeFile("cessna.osg") ); return viewer.run(); }Specify the OSG header location and dependent libraries. You need to tell the linker to link your project with five libraries: OpenThreads, osg, osgDB, osgUtil, and osgViewer. You will learn more about configuring an OSG application in the next chapter.
Build your project. Make sure the file
cessna.osgalready exists in the same directory as the executable file, or in the path specified with the OSG_FILE_PATH environment variable.Check it out! You get a full-screen display with a flight model shown in the middle:
Try to make some changes to what you are observing simply with your mouse. Press and hold the left, middle, and right mouse buttons when you are moving the mouse, to rotate, move, and scale the Cessna. Note that you are not actually modifying the model but changing the virtual view point instead.
An easy-to-read example was just created to show how powerful and clear OSG is. The osgDB::readNodeFile() function is used to read an existing node file, that is, a scene graph that represents the Cessna model. The osgViewer::Viewer instance is then created to set the scene data and provide a simulation loop for the application.
Here, osgDB and osgViewer are namespaces, and Viewer is a class name. The naming style of a function or class member uses the same convention as the famous "camel-case", that is, the first word of the function name starts with a lowercase letter, and additional ones start with upper-case letters.
Everyone interested in learning and making use of OSG is welcome to join the community at any time. There are several ways to get in touch with the core developing team and thousands of OSG programmers.
The preferred way is to use one of the two major public mailing lists. A mailing list here is a list of subscribers who have discussions on the same particular topic, via e-mail. To subscribe to an OSG mailing list, follow the appropriate links mentioned:
|
Mailing list |
Subscription link |
Description |
|---|---|---|
|
osg-users |
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org |
General technique support and discussions |
|
osg-submissions |
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org |
Submission of code changes and bug fixes only |
The forum, which is already linked to the mailing lists, is also provided for people who like this form: http://forum.openscenegraph.org/.
You will find a greater variety of OSG discussion groups on the internet, such as IRC channel, Google group, LinkedIn, and even a Chinese mirror:
Companies and individuals may ask for professional services, too, by making the appropriate payments. A number of professional OSG contractors are listed here as a reference: http://www.openscenegraph.org/projects/osg/wiki/Community/Contractors.
Finally, remember to visit the wiki website and developer blog at any time. This contains an enormous wealth of information, including the latest news and download links for OSG distributions:
This chapter gave a bird's eye view of OSG, in which we have drawn in mind a rough image about what we are going to learn about this widely used 3D graphics API. We sincerely hope the following chapters of this small book will serve as a ladder to help the readers, rung by rung, to get into the world of OSG-based programming.
In this chapter, we specially covered:
The cornerstone and funder of OSG
The basic structure of OSG including various functional modular libraries
A quick view of how to write OSG-style applications
The way to join the OSG community and obtain the latest news
