Scene Graph
XSG is a scene graph used to describe all of the data that makes up a game or simulation. XSG starts where Fahrenheit left off, creating a scene graph standards that truly encompasses all of a game or simulation project.
Scene graphs are methods of storing, organising and managing the data that
describes the geometry of a 3D computer generated scene. They can be useful in improving the performance of a game or simulation.
However, the increasing complexity of current scene graphs impacts the
efficiency they are supposed to deliver. XSG is a consolidation of many
different scene graph ideas. It proposes a structure that both increases the
number of features that the scene graph can handle while at the same time simplifying the scene graph.
Extensible Scene Graph is a set of specifications that define a data model
for describing games and simulations and their infrastructure. XSG is implemented using MORPH; an HLA compliant xml-based language that supports prototypes and hierarchical data structures.
A scene graph is a method of organising the data that describes a scene. Traditionally, scene graphs
were used to describe the geometry and spatial information that makes up a 3D
scene. Current scene graphs often go beyond just geometry and spatial
information; they try to include behaviours. The inclusion of behaviours
has led to very complicated
scene graph structures.
Scene graphs are often structured as a collection of nodes in a
directed acyclic graph (DAG). Nodes in a DAG
are connected by unidirectional (one way) paths. In an acyclic graph, if you follow a
path away from a node there is no way to return to that node by any path. In other words, no path through a DAG visits any individual node more than once.
Scene graphs describe relationships between objects, and are used to pass
information and effects along the graph based on these relationships, which reduces the
amount of programming required. If an object that resides at a node(N1) is
affected by something, everything that is below N1 in the graph (that is, any
node that can be reached by following a path away from N1) is also affected. By
using relationships to propagate effects, the scene graph can be used to handle low level-graphics code rather than
a programmer individually coding the required updates and interactions for each
affected node. Grouping related objects allows a program to apply changes to an
entire group of nodes rather than individually changing each node.
Scene graphs help process large amounts of information quickly by providing a logical model for sorting and identifying data. The data
model allows for quick filtering of the data before it is sent to be rendered or executed, ensuring that only data
which has a noticeable effect on the scene is processed. For example, a ball
that is hidden entirely behind a wall will not be processed, since it cannot be
seen and does not affect how the scene appears.
Filtering the data saves both time and computational resources, helping the scene
run smoothly.
XSG fuses ideas from a variety of sources including existing scene graphs,
expressed desired scene
graph features, and research on games and scene graphs. Current scene graphs and
3D interchange languages had an influence on the development of XSG. XSG combines a number of interesting ideas and
influences. The timeline below gives an overview of the major influences
that led to the development of XSG, and highlights the ideas from each instance
that were of particular interest for XSG.
1989-1997: VRML Developed
VRML is a platform independent language for describing 3D objects. Of
particular interest in creating XSG were the following features:
- VRML is a declarative language. It describes what the 3D objects and
scenes are, not how to create them.
- VRML does not require a programming API,
instead the VRML language is VRML interpreted to create the scene
that is being described. That is, it is up to the application to
understand VRML instead of VRML getting results by sending various calls
to the application.
Early 1997: Fahrenheit Announced
In late 1997, HP joined with Silicon Graphics (SGI) and Microsoft to
start a project named Fahrenheit [4]. Fahrenheit was intended to be a scene
graph technology that went beyond the geometry of the scene to also include
sounds, animations, or other information relevant to the scene in the scene
graph. Though the participating parties went their separate ways in 1999
without actually completing Fahrenheit, there were a number of exciting
ideas proposed by Fahrenheit. Some of the interesting features proposed
included:
- Storage of all scene related information. Storing sounds, animations, and other scene data alongside the polygonal geometry would make Fahrenheit capable of more aggressive optimization due to its greater knowledge about the scene.
- Extensible to allow storage users defined datatypes.
- Hardware dependent performance enhancement. Fahrenheit was to collect information from the hardware vendors that could be used in optimization and rendering. Rendering no longer based on lowest-common denominator support.
- Support for multiprocessing
- Scalable handling of low level systems to high-end, high-bandwidth systems with multiprocessing and multiple graphics subsystems
1998: Hewlett Packard's Direct Model released
Direct Model improves graphic rendering by sorting scene data and optimizing the information sent to the graphics card for rendering by reducing both the amount of data and the number of state changes required to render that data [3]. Of interest with Direct Model was:
- It took advantage of the hierarchical nature of the scene graph to quickly sort data.
- Data was optimized before being sent to be processed, helping
processing occur faster by reducing the number of times the processor
needed to change its state.
2001: Jupiter Toolkit released
The Jupiter Toolkit, a product of collaboration between Hewlett Packard Engineering Animation Inc. and researchers at Tübingen University in Germany, is software that improves graphic rendering performance [1]. The Jupiter Toolkit is based on DirectModel with extensions that include:
- A Linux version
- A new method for depth testing, that allows
- More efficient occlusion culling
The main interesting point of the Jupiter Toolkit is the possibility of
interoperability. A techniques that can be implemented on different
platforms and different operating systems would be a great step ahead for
the game industry, so that game companies can easily distribute their games
to a larger audience.
The scene graph is constantly developing as 3D graphics get more advanced, and people try to handle more and more information with the scene graph.
Magnetar XSG is a technique for handling the large amounts of
data that describe a scene in a simple, easy to use, manner. The Magnetar Scene graph handles all of the content necessary to describe a game or simulation, and lets the engine worry about how to display that content.