OpenGL++: Difference between revisions

Revision as of 14:58, 23 December 2006

Latest revision as of 09:11, 11 August 2025

(33 intermediate revisions by 23 users not shown)

Line 1:

{{Short description|Overview of OpenGL++}}

'''OpenGL++''' was intended to be a powerful layer above the [[OpenGLgraphics library]] 3D graphics system written in [[C++]] that supported [[Object-oriented programming|object-oriented]] data structures on top of the [[OpenGL]] 3D graphics system. The project started as the result of a partnership between [[Silicon Graphics|SGI]], [[IBM]] and [[Intel]], (and later, [[Digital Equipment Corporation]]. asIt well)was intended to provide a higher level [[API]] than the "bare metal" support of OpenGL, as well as being an implementation for [[Java3D]].<ref>{{Cite web |url=http://www.sdsc.edu/~nadeau/Talks/NASA_EOSDIS/3djava4.htm |title=3D Java APIs, OpenGL++ |access-date=2008-05-05 |archive-date=2009-06-26 |archive-url=https://web.archive.org/web/20090626034706/http://www.sdsc.edu/~nadeau/Talks/NASA_EOSDIS/3djava4.htm |url-status=live }}</ref> Work on OpenGL++ ended when SGI decided to partner with [[Microsoft]] instead, leading to the [[Fahrenheit graphics API|Fahrenheit]] project, which also died.

==DevelopmentBackground==

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 [[tree data structure]], 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.

OpenGL++ (OGL++) was intended to offer a selection of routines and standardized data structures to dramatically simplify writing "real" programs using OpenGL. Instead of the programmer having to keep track of the objects in the 3D world and make sure they were culled properly, OpenGL++ would include its own [[scene graph]] system and handle many of the basic manipulation duties for the programmer. In addition, OGL++ included a system for modifying the scene graph on the fly, re-arranging it for added performance.

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.

Much of OGL++ was a combination of ideas from earlier SGI projects in the same vein, namely [[Open Inventor]] which offered ease-of-use, and [[OpenGL Performer]] which was written separately from Inventor to deliver a system that optimized scene graphs for increased performance and exploited scalable architectures. It was later intended that a new design could get the best of both worlds while forming the underlying framework for several projects including [[Computer Aided Design|CAD]], [[image processing]], [[flight simulator|visual simulation]], [[scientific visualization]] and user interfaces or 3D manipulators allowing them to interoperate, thereby offering both rapid development and high performance.

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.<ref name=ARB>[http://www.cg.tuwien.ac.at/~wimmer/apis/opengl++_summary.html Scene Graph Standard for OpenGL] {{Webarchive|url=https://web.archive.org/web/20080614114917/http://www.cg.tuwien.ac.at/~wimmer/apis/opengl++_summary.html |date=2008-06-14 }}, ARB Meeting Notes</ref>

SGI has recently been involved in a similar effort in partnership with [[Sun Microsystems]] that was intended to produce a scene graph for the [[Java programming language]]. This project eventually failed, and led to the separation of Sun and SGI's efforts, Sun releasing theirs as [[Java3D]]. SGI packaged some of their developments into the [[Cosmo3D]] produce suite, which as a sort of marketing name for a wide variety of semi-related products. By then a CAD/"Large Model Visualization" layer of functionality called OpenGL Optimizer had already been 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, it ran on OpenGL directly. 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.

==Cosmo3D==

The Inventor and Performer 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. This led to the [[Cosmo3D]] system, basically, a standardized high-performance scene graph that sat on top of OpenGL. Cosmo3D introduced a new [[file format]] that could be used to store entire scenes and all the data needed to reconstruct them, the [[VRML]] format that is still in use.<ref name=ARB/>

SGI produced a number of products that used Cosmo3D. Among these were a variety of VRML tools, and a large model visualization system for [[Computer-aided design|CAD]] purposes called OpenGL Optimizer. Oddly, Cosmo Code, a VRML authoring tool, was produced by a different division and did not use the Cosmo scene graph at all.

Cosmo's scene graph was by no means a unique solution at the time, and a number of other graphics companies were working on similar ideas at about this time.

==OpenGL++==

At the 20–21 August 1996 meeting of the [[OpenGL Architecture Review Board]] (ARB), SGI floated the idea of a new standardized scene graph similar to Cosmo3D but with the express intent of being based on "standard" OpenGL. There was some interest in the concept, so at the 9–10 December 1996 meeting the group presented the first draft of the OpenGL++ concept.<ref name=ARB/> A follow-up meeting during 17–19 February 1997 demonstrated that there was considerable interest from most parties, with the exception of Microsoft and Sun, although there were concerns as to whether or not the ARB was the right body to support such an effort without diluting their primary job of supporting OpenGL.<ref>{{Cite web|url=http://www.mrpowers.com/Papers/OpenGLPlus/OGLARB.htm|title="Meeting Notes, February 17-19, 1997"|access-date=2008-05-05|archive-date=2008-02-27|archive-url=https://web.archive.org/web/20080227042753/http://www.mrpowers.com/Papers/OpenGLPlus/OGLARB.htm|url-status=live}}</ref> Development continued throughout 1997 including several distributions of the [[API]]. However, the ARB notes "There's been lots of work, but relatively little communication."<ref>{{Cite web |url=http://www.opengl.org/about/arb/meeting_notes/notes/OpenGL++_notes_6-3-97.html |title="OpenGL ++ ARB Interest Subcommittee Meeting Notes" |access-date=2008-05-05 |archive-date=2008-05-16 |archive-url=https://web.archive.org/web/20080516080031/http://www.opengl.org/about/arb/meeting_notes/notes/OpenGL++_notes_6-3-97.html |url-status=live }}</ref>

While the work on OpenGL++ continued, Sun and SGI had also been working on a 3D standard suitable for Java. These efforts eventually broke down, and Sun went on to release Java3D. SGI suggested their Cosmo work was a sample Java3D implementation, and as this work evolved into OpenGL++ these plans moved with it. During the definition of OpenGL++, Sun stated that they were not interested in working on the effort as they were focussed on their Java3D work.<ref name=ARB/> Comparatively, Java3D spans two layers of the 3D stack, the scene graph and the visual interface and its widgets.

By late 1997 SGI appeared to be fully committed to the OGL++ effort. They had stated that the existing Cosmo work would be abandoned and that Open Inventor, Performer and OpenGL Optimizer would be re-written to be hosted on top of OGL++. As 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.<ref>{{Cite web |url=http://www.opengl.org/about/arb/meeting_notes/notes/OpenGL++_notes_9-8-97.html |title="OpenGL ++ ARB Interest Subcommittee Meeting Notes, September 8, 1997" |access-date=May 5, 2008 |archive-date=May 16, 2008 |archive-url=https://web.archive.org/web/20080516080222/http://www.opengl.org/about/arb/meeting_notes/notes/OpenGL++_notes_9-8-97.html |url-status=live }}</ref><ref>{{Cite web|url=http://www.vidimce.org/college/summer97/|title="Skimmer in OpenGL++ Maze in OpenGL++"|access-date=2008-05-05|archive-date=2009-01-07|archive-url=https://web.archive.org/web/20090107023301/http://www.vidimce.org/college/summer97/|url-status=live}}</ref>

==At the end==

At the March 1998 ARB meeting, to everyone's surprise, SGI presented Fahrenheit, an entirely new project. The ARB notes from that meeting note "SGI felt it was critical to work together with Microsoft, which had not been moving in compatible directions, to be able to build value-added products in the Windows environment. Fahrenheit is a large step in that direction."<ref name=ARB/> OpenGL++ was abandoned.

In the end, there is little to show for any of these efforts. Partnerships with Sun, Intel and IBM and Microsoft all led to nothing as SGI jumped from project to project. In retrospect, SGI reacted badly to a rapidly changing environment. An internal desire to create an generic but extensible scene graph was constantly sidetracked by a belief that SGI couldn't go it alone. Partnerships were formed and later abandoned due to irreconcilable differences or simply as priorities and internal pressures shifted. OGL++ was the most nacent of these efforts and its failure forced an unholy alliance between Microsoft and SGI in the form of Fahrenheit. Ancillary issues like powerful CAD APIs running on Cosmo3D complicated the picture. In the final analysis the new unified scene graph concept was bounced from project to project, and eventually died in 2000 when Fahrenheit was killed.

The project appears to have been a victim of SGI's shifting priorities through this period, changing directions in order to partner with larger companies. When these companies exited the 3D space to focus on other product niches, SGI was left as the only supporter of the project, exactly what they were trying to avoid. Eventually, the only other company with a 3D focus was Microsoft, and the [[Fahrenheit graphics API|Fahrenheit]] project started and ended shortly after the OpenGL++ efforts.

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 license|open source]], but the source to OGL++ was never completed to any satisfactory degree. No finalized specification exists and, as with OpenGL, the spec and idea behind such an [[open platform]] would have been what lent it it'sits lasting value, not a single implementation of a scene graph idea.

==References==

{{reflist}}

==Further reading==

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 it's lasting value, not a single implementation of a scene graph idea.

* [http://citeseerx.ist.psu.edu/showciting;jsessionid=025249BB98D6EE772FB05B0A08BFAEB2?cid=1095575 An OpenGL++ Specification]

* [https://web.archive.org/web/20110714123001/http://www.mrpowers.com/Papers/OpenGLPlus/Layers/layers.html OpenGL++ (OpenGLPlus) Possible Layers] (Wayback snapshot)

{{DEFAULTSORT:Opengl}}

[[Category:3D computer graphics]]

[[Category:3D Scenegraphscenegraph APIs]]

[[Category:OpenGL]]