SSG: A Simple Scene Graph API

for OpenGL

by Steve Baker

Introduction

Simple Scene Graph (SSG) is intended to be a really simple, low-impact, scene graph API that layers nicely on top of OpenGL using C++ and which works with or without GLUT.

SSG is a part of PLIB.

This document assumes a certain degree of knowledge of OpenGL.

SSG includes a subsidiary library of simple matix and vector math with support for some intersection testing, field-of-view culling and such like. This is called 'Simple Geometry' (SG). SG is used extensively by SSG - but is also useful as a standalone library.

A Scene Graph is essentially just a tree-structured database containing a hierarchy of branches - and a bunch of leaf nodes. Each leaf node does some OpenGL rendering - the branch nodes are intended to manage things like: field of view (FOV) culling, level of detail (LOD) management, transformations, and animation.

In addition, each leaf node has a structure tacked on to it to encapsulate OpenGL state information - and that in turn may optionally have a texture applied to it.

In addition to managing the scene graph, SSG contains code to manage the positions of cameras, lights and other rendering aspects of OpenGL.

Symbol Conventions.

Both SSG an SG follow conventions for symbols and tokens that are the conventions used by OpenGL and GLUT.

Hence, all SSG symbols for classes and functions start with ssg and all #define tokens start with SSG. Functions and symbols that belong to the SG library similarly start with sg or SG.

Words within a class or function name are Capitalised and NOT separated with underscores. Words within #define tokens may be separated with underscores to make them readable.

Initialisation.

The first SSG call in any program must always be ssgInit(). Call ssgInit only after you have obtained an OpenGL rendering context (or called glutInit() and created a rendering window if you are using glut).

Classes

The following class hierarchy makes up the core package - which can be extended to add functionality or to change some underlying mechanisms.


   class ssgBase
    |__ class ssgSimpleList
    |    |
    |    |__ class ssgVertexArray
    |    |__ class ssgNormalArray
    |    |__ class ssgTexCoordArray
    |    |__ class ssgColourArray
    |    |__ class ssgIndexArray
    |
    |__ class ssgEntity
    |    |
    |    |__ class ssgLeaf
    |    |    |__ class ssgVTable (deprecated)
    |    |    |__ class ssgVtxTable
    |    |          |__ class ssgTween
    |    |          |__ class ssgVtxArray
    |    |
    |    |__ class ssgBranch
    |         |__ class ssgRoot
    |         |__ class ssgInvisible
    |         |__ class ssgSelector
    |         |    |__ class ssgTimedSelector
    |         |    |__ class ssgRangeSelector
    |         |
    |         |__ class ssgBaseTransform
    |         |    |__ class ssgTransform
    |         |    |__ class ssgTexTrans
    |         |
    |         |__ class ssgCutout
    |         |__ class ssgTweenController
    |
    |___ class ssgState
    |     |__ class ssgSimpleState
    |         |__ class ssgStateSelector
    |
    |___ class ssgTexture

The general idea is that, all geometry is contained in ssgLeaf classes, all data heirarchy is in a ssgBranch classes and all OpenGL state information is in ssgStates.

You may not declare instances of ssgBase, ssgEntity, ssgBaseTransform, ssgLeaf or ssgState since they are all abstract classes.

It is presumed that applications will add new kinds of leaves, branches, states and textures to customise SSG to their needs.

Here are the further chapters:

The base class
An entity of the graph
A leaf of the graph
A branch of the graph
States (material etc)
ssgContext
Non-class functions: Loading, saving and optimizing databases
How to write plib-loaders and writers

You can go through all the SSG-documentation by clicking on the "= next =>"-links at the bottom of each page.

= next =>

Steve J. Baker. <sjbaker1@airmail.net>