13.1ABriefHistory 203
■ Inventor provided user interaction with the 3D data as well as an interface to
it. Performer did not have much in terms of built-in tools for user interaction,
but instead focused on generating images at fixed frame rates. Performer was
often used in a simulation environment where the interface to the user was an
external system, such as an airplane cockpit.
SGI tried several times to combine both the performance of Performer and
usability of Open Inventor. First, SGI introduced the Cosmo 3D library, which
offered an Open Inventor-style scene graph built on an Iris Performer-style low-
level graphics API. After the first beta release, SGI joined with Intel and IBM to
push OpenGL++ on the OpenGL architecture review board (ARB) [6] as a stand-
ard scene graph layer on top of OpenGL that could be used to port Performer or
Inventor (or Optimizer, yet another scene graph for the computer-assisted design
(CAD) market). The ARB was also interested in seeing OpenGL++ become a
standard for the web. This project died when SGI turned their attention to an al-
most identical project with Microsoft named Fahrenheit. The idea was that SGI
would focus on the high-level API (scene graph) while Microsoft worked on the
low-level Fahrenheit (FLL) API that would eventually replace both OpenGL and
Direct3D. Fahrenheit was killed when it became clear Microsoft was playing SGI
and was instead focused on releasing DirectX 7 in 1999 [7].
Sun Microsystems was also interested in creating a standard scene graph API
that could be universal and bridge desktop applications with web application:
Java3D [8], based on the cross-platform Java development language and run-time
library. The first version was released in December 1998, but the effort was dis-
continued in 2004. It was restarted as a community source project but then “put
on hold” in 2008 [9]. Project Wonderland, a Java virtual world project based on
Java3D, was ported to the Java Monkey Engine (jME) API, a Java game engine
used by NCSoft that produced better visuals and performance and reduced design
constraints.
Today, game engines are closer in design to Iris Performer than to Open In-
ventor. For instance, game engines provide offline tools that can preprocess the
data into a format that is closer to the internal data structures needed on the target
platform, thus eliminating complex and time-consuming data processing in the
game application itself in order to save precious resources, such as CPU time,
memory, and user patience. Also, game engines often create interactivity and
user interfaces with native programming through scripting languages such as
Lua. This provides maximum flexibility for tuning the user experience without
having to spend too much time in designing the right object model and file
format.