OpenSG Motivation

Motivation

The OpenSG project was initiated at SIGGRAPH 1999 by Dirk Reiners, Allen Bierbaum and Kent Watsen. After the Fahrenheit initiative between Microsoft, SGI and HP fell apart it was the only solution we could see.

Scenegraph systems had been dominated by announcements for years, with very few results. Cosmo3D/Optimizer were supposed to replace Inventor and Performer, but were themselves replaced by OpenGL++, which died before it saw the light of day, to be replaced by Fahrenheit. Which died in 1999. After 5 years of announcements we realized that companies couldn't be the right solution for providing such a fundamental component of a VR system like a scenegraph. An Open Source system was the only solution. Allen and Kent became occupied with other things, so Dirk took a long hard look at the available Open Source scenegraph systems.

The general features that are needed by every system that aspires to be used in a virtual reality context were fulfilled by most of them: decent performance due to view volume culling and optimized geometry handling (stripes etc.), support of static and dynamic objects, object-oriented C++ interface etc. Our system supports all of them, too. But a single system that reaches the specific goals we expected from a scenegraph to base future developments on:

portability
multi-threading support
support for multiple graphics pipes and clusters
extensibility & reflectivity
flexibility

couldn't be found.

Portability between different Unices is usually pretty simple, portability to Windows is a different matter. Especially in the context of dynamic libraries Windows is a gigantic pain. But it is the most widely used platform, not only in industry but also in large parts of the educational arena. Thus for a system that needs a large user base to be successful Windows support is something we couldn't get around.

The biggest technological problem is the multi-threading. This is really tricky, as asynchronous threads really need independent copies of the scenegraph, anything less won't do. Let's say you have a physical simulation that calculates the motion and interaction of complex objects. It might take longer than a frame to do every step, so you don't want to do it for every frame to give the user better feedback. But you don't want to give him inconsistent feedback, either, i.e. half of the object moved to the new position, half in the old. Thus the simulation thread needs its own copy of the data. Add to that a simulation that actually deforms the objects and you need a full copy of pretty much everything.
Admitted, this is the worst case, but simpler cases like a geometry morpher need a copy of the geometry, while a solid object motion simulation needs a copy of every transformation. And both need access to consistent geometry data, so if they are supposed to work on their own version they would have to copy everything, and keep it up to date. It's more efficient for them to just work on the scenegraph's copy.
Thus the system has to be able to handle multiple copies of the data, and do it in a way that's as transparent as possible to application writers. None of the existing scenegraphs supported this, and none do today. Some do support restricted versions, but not the general case.
In general we expect multi-threading to gain a lot more importance in the coming years, as new processor generations from all processor vendors are going to incorporate multi-threading on chip to make better use of the processor

Multiple graphics pipes are a concept that is gaining more and more acceptance.
High-end systems from sgi and other vendors have been supporting it for quite a while now, to drive multi-screen projection systems like Powerwalls or Caves (go to T.A.N., Fakespace or Mechdyne for more info on what these are). As we have both of these we needed a new system to support them. None of the existing scenegraphs supported it.
A trend that is rapidly evolving is using clusters of standard PCs for high-end applications using multiple projectors (see the gallery for examples). To do that every machine in the cluster has to have the same data for rendering, so that all images fit together seamlessly. You can either distribute the OpenGL commands, which might create a lot of traffic, as the application can store some things more compactly than OpenGL. Or you can run the application itself on multiple machines, distributing just the input and hope that they all react the same to the same input. If you also have strict timing that is distributed too it might even work, but you have to change all the applications that are to be distributed.
Our idea was to take a middle ground and distribute the scenegraph. It is a common component of all the applications, and it has a lot of structural information that helps it distribute information efficiently. No other scenegraph that we know of can handle this.

Extensibility in this context means adding new components to the system and replacing of system components by other ones, which are better suited to the hardware or problem at hand. Adding these extensions should be simple, and be possible to do dynamically by loading a dynamic library.
In addition to that it should be possible to replace system components at runtime by newer versions. The idea is to be able to replace e.g. the Geometry node by another one that can use new extensions. This change should also have an effect on the whole system, including system tools like loaders. This allows the use of new extensions for old applications without recompiling.
An added requirement was the ability to write tools that would be able to support all these dynamics. To do that the system has to give out information about itself, mainly about the attributes of objects, and define some generic access and manipulation methods. This capability has been termed reflectivity, and the idea has been around for a while. But none of the existing scenegraph systems supported all this.

Thus a decision was made to start a new initiative early in 2000. Initial support was generated by founding the OpenSG Forum in January 2000. The basic design ideas were written down in a design document that was circulated to some people with experience in creating scenegraphs. Code Design started in April, with Gerrit and Johannes joining the project, Code creation soon after.

The first alpha was finished shortly before SIGGRAPH 2000, followed by a beta in February 2001. A nearly complete 1.0 was demonstrated at SIGGRAPH 2001, followed by a release in October 2001.