Tutorial 3 - Basic OSG SetupIntroduction In this tutorial we explain how to integrate OSG into existing applications. We also explain the concepts underlying OSG operation, and some of the important functionality. Concepts
Scene Graphs Scene Graphs OpenSceneGraph (OSG) is an API that can be used to represent a scene as a tree-shaped data structure; nodes in the graph are objects in the scene. The tree has a single root node and each child of the root node has zero or more children. The root represents a Scene, and decedents of the root are some of the objects in the scene. Usually a scene includes a camera, lighting, models, and textures. Scene Graphs use Vector and Matrix mathematics, and matrix transforms are provided for a Scene Graph tree. A basic principle of a Scene Graph is that for any children that are added to a node, those children will inherit the properties of that node. For example, if we create a transformation node and bind it to a node as a child, all children of the tranformation node are effected by the transformation. However, the parent and sibling nodes of the transformation node are not affected by the transformation node. Effects of a transformation node are applied to the children, grandchildren and all descendents of the transformation node down to leaf nodes. Design Patterns are heavily exploited by OSG and the Visitor Pattern is used to draw a scene by traversing the Scene Graph tree using a visitor. As a visitor reaches a node, calls are made to OpenGL to construct the proper low level entities. After completion of the tree traversal, the Scene Graph data is sent to the OpenGL buffer, which is swapped with the old buffer. Then the buffer's contents are drawn to the screen. OSG/SDL Integration For the games that we will build, OSG will work with SDL to draw objects to the screen. OSG constructs the scene, using OpenGL function calls, and then sends that data to SDL; SDL the obtains the buffer for the next frame, and paints it onto the screen. To get OSG and SDL to work together, we use the following parameters to SDL_SetVideoMode:
Note that for all of the OSG classes we use the 'OSG::' prefix. This is to reference the correct namespace in which the class resides. If ever there is a compiler error when using OSG libraries, more than half the time it is because 'OSG::' was not prefixed to an OSG class. Be careful with this. OSG::SceneView 
The OSG::SceneView is the root node in the Scene Graph, as it ties all other parts of the Scene Graph together. It represents an individual scene, composed of a camera, lighting, and scene data. In this tutorial, all we must do is create a OSG::SceneView, extract the OSG::Camera, set the camera properties, and initialize the OSG::SceneView. OSG::Camera The OSG::Camera is a special type of OSG::Node that represents the functions of a camera. With it we can define the viewing area of the screen, the direction of viewing, the aspect ratio, clipping distances (how far an object may be rendered), and clear color (background color).Though we will be dealing with the OSG::Camera more in future, for now we can pretend that the OSG::Camera is a set and forget part of the Scene Graph. OSG::VecXY OSG::Vec will be used extensively throughout this tutorial set. The Vec represents a tuple or vector of varying sizes. That is why this section is labeled VecXY: X represents the size of the tuple. What does Y represent then? The data type contained by the tuple. This can be either float or double, f or d. Thus in total, we have OSG::Vec2d, or OSG::Vec4f. Typically the data structures work the same, containing the same basic functionality. The exception is the number of elements contained within the tuple, and of course the associated accessor functions. These items will be used to represents coordinates, in both 2D and 3D systems, colors, trajectories, momentum, and other things that can be defined with vectors. As such, the OSG::VecXY contains overloaded operators that follow typical vector math, such as addition, subtraction, dot and cross products, and others. Screen Updates Refreshing the screen is fairly easy with SDL/OSG. In our event loop the system goes about it's normal process, possibly changing the scene data, and reaches the end where a screen refresh is necessary. We call 4 simple functions to do this; 3 from OSG::SceneView:
and then the last one from SDL:
The first three functions tell OSG::SceneView to gather data on the new state of the Scene Graph, cull any geometry that is not visible to the user, and copy the data to the OpenGL graphics buffer. Then the last function tells OpenGL to swap the buffers, which paints the screen with the latest frame of data. References
SDL_GL_SwapBuffers Conclusion If everything was absorbed, the example program compiles and is run, we get a lovely blue window now instead of the regular black SDL window. An improvement, yes, but not by much. What this tells us, though, is that we were able to initialize both SDL and OSG, create a basic default SceneGraph, render the scene graph data, and draw the contents to the screen. That's not bad! 
Getting your mind wrapped around the concepts of OSG is the hardest task at this point. Don't go mucking around in the OSG references documentation, only to freak out at the enormity and obscurity of it all. Instead, take things piece by piece. These tutorials were designed to be taken a piece at a time, at a modest pace. |