OpenGL++: Difference between revisions

Revision as of 23:17, 7 February 2008

Revision as of 03:02, 5 May 2008

Line 1:

'''OpenGL++''' was intended to be a powerful layer above the [[OpenGL]] 3D graphics system written in [[C++]] that supported [[object-oriented]] data structures. The project started as the result of a partnership between [[Silicon Graphics|SGI]], [[IBM]] and [[Intel]] (and later [[Digital Equipment Corporation]] as well) to provide a higher level [[API]] than the "bare metal" support of OpenGL, as well as being an implementation for [[Java3D]]<ref>[http://www.sdsc.edu/~nadeau/Talks/NASA_EOSDIS/3djava4.htm 3D Java APIs, OpenGL++]</ref>. Work on OpenGL++ ended when SGI decided to partner with [[Microsoft]] instead, leading to the [[Fahrenheit graphics API|Fahrenheit]] project, which also died.

==Development==

Line 5:

The vast majority of applications using 3D systems describe the objects in their "world" in a [[data structure]] known as a [[scene graph]]. A scene graph is normally organized as some sort of a [[binary tree]], with the nodes representing objects, and the edges their relationship to other objects in the world. For instance, a table might be represented by a single "table" object with several edges connecting its parts together, the table top, legs, etc. Key to high performance in 3D applications is deciding what objects in the world are actually visible given the current camera position and direction. For instance, objects behind the camera do not have to be drawn. Quick traversal of the scene graph is essential to making this "culling" operation occur quickly.

Scene graphs were generally left to the developer to implement, and it was all too common to see poor examples that led to poor performance. SGI had worked on a number of projects that were intended to help the developer produce a high-quality scene graph, but none of these had become widely used for a variety of reasons. [[Open Inventor]] was one such example, and was intended to simplify building the scene graph, but the results were not necessarily very high performance. [[OpenGL Performer]] was a similar project that was intended to produce high-speed scenes and support very large numbers of objects in the "world", but was not particularly easy to use. Both teams had already realized that there was no particular reason the two systems could not be combined into one, offering both ease-of-development and high-performance.<ref name=ARB>[http://www.cg.tuwien.ac.at/~wimmer/apis/opengl++_summary.html Scene Graph Standard for OpenGL], ARB Meeting Notes</ref>

SGIDuring hadthis beenperiod involvedSGI instarted suchwork anon effort in partnership withtheir [[Sun MicrosystemsCosmo3D]] thatsuite, which was intendeda tomarketing producename for a scenewide graphvariety forof semi-related products. Much of the [[Javaeffort (programmingrevolved language)|Javaaround programmingthe language[[VMRL]]. Thisstandard, projectwhich eventuallywould failed,live andon led tobeyond the separationCosmo3D ofproject. SunIn andorder SGI'sto efforts,make SunVMRL releasingsomething theirsmore asthan [[Java3D]].a paper standard, SGI packagedalso someprovided ofthe theirCosmo developmentsproducts intothat theuse [[Cosmo3D]]VRML suitenatively, which wasincluding a marketingscene namegraph forsystem athat wideread varietyand ofwrote semi-relatedVMRL products.and Byrendered thenit using a custom OpenGL stack, CosmoGL. A CAD/"Large Model Visualization" layer of functionality called OpenGL Optimizer had already beenwas implemented on Cosmo3D and then released as a product. Other "front end" packages like, Cosmo Code, a [[VRML]] authoring tool, were produced by a different division and did not use the Cosmo scene graph at all.

At the same time, SGI had been involved in such an effort in partnership with [[Sun Microsystems]] that was intended to produce a scene graph for the [[Java (programming language)|Java programming language]]. This project eventually failed, and led to the separation of Sun and SGI's efforts, Sun releasing a new specification as [[Java3D]]. As talks between the parties continued, SGI offered Cosmo3D as a possible implementation of Java3D. During discussions in the ARB, a new idea formed to make a new implementation with the specific intent of offering Java3D support "on top", and rendering to an existing standard OpenGL "on the bottom". At the February 17-19, 1997 ARB meeting, these concepts had evolved into the OpenGL++ concept.<ref name=ARB/> At the talks, SGI stated they would be "throwing away" the Cosmo3D implementation in favor of the new system.

OGL++ was intended to be a cleaned up and more flexible version of Cosmo3D. Most of the Cosmo3D team started work on OGL++ and a lot of the effort was aimed at a specification and implementation that could deliver on the promise of a truly powerful yet generic scene graph. Practically every company involved in the 3D [[workstation]] market joined the effort.

Line 16 ⟶ 18:

Today, no such standardized scene graph exists, and SGI has all but exited the API world. SGI has released the earlier Open Inventor code into [[open source]], but the source to OGL++ was never completed to any satisfactory degree. No specification exists and as with OpenGL the spec and idea behind such an open platform would have been what lent it its lasting value, not a single implementation of a scene graph idea.

==References==

http://www.cg.tuwien.ac.at/~wimmer/apis/opengl++_summary.html

[[Category:3D computer graphics]]