Misplaced Pages

#500499

40-406: Performer came about in 1991 when a group from SGI's Open Inventor project, then known as IRIS Inventor, decided to focus on performance rather than ease of programmability. Whereas Inventor delivered easy-to-use objects and various UI elements to interact with them, Performer focused on a scene graph system that could be re-arranged on the fly for performance reasons, allowing the various passes of

80-494: A cleaned up version of Cosmo. This project died when SGI turned their attention to an almost identical project with Microsoft known as Fahrenheit , which was also killed. Today Inventor and Performer remain separate products, and none of the combined versions ever saw the light of day. Performer consists primarily of two libraries: the lower-level libpr and the higher-level libpf. The libpr library provides an object-oriented interface to high-speed rendering functions based on

120-409: A dedicated thread and similarly culling would also have a dedicated processor. Advanced features like database paging, texture paging and point light source management (for flight simulation) and intersection testing for collision detection would also have dedicated processors allowing asynchronous I/O and processing to occur without negatively impacting graphics performance. Most of this complexity

160-546: A format-independent database interface that supports common data formats such as Open Inventor , OpenFlight , Designer's Workbench , Medit , and Wavefront .obj file . Open Inventor Open Inventor , originally IRIS Inventor , is a C++ object-oriented retained mode 3D graphics toolkit designed by SGI to provide a higher layer of programming for OpenGL . Its main goals are better programmer convenience and efficiency. Open Inventor exists as both proprietary software and free and open-source software , subject to

200-476: A number of practical problems that could have been avoided with better design. Eventually all of these ideas would come together to create the OpenGL++ effort, along with Intel , IBM and DEC . Essentially a cleaned up and more “open” version of Cosmo 3D, work on Cosmo ended and SGI turned to OpenGL++ full-time. The OpenGL++ effort would drag on and eventually be killed, and SGI then tried again with Microsoft with

240-428: A number of practical problems that could have been avoided with better design. Eventually all of these ideas would come together to create the OpenGL++ effort, along with Intel , IBM and DEC . Essentially a cleaned up and more “open” version of Cosmo 3D, work on Cosmo ended and SGI turned to OpenGL++ full-time. The OpenGL++ effort would drag on and eventually be killed, and SGI then tried again with Microsoft with

280-409: A rendering task to be performed in parallel in multiple threads . Performer allowed the scene to describe levels of detail with hysteresis bands and fade capabilities. Frame rate and statistics were monitored and a 'stress' factor was calculated. This could be used to further weight the level of detail in the scene eliminating detail to maintain a target frame rate. Other key features of Performer were

320-591: Is available from SGI. Around the same time, the Coin3D API clone library was released by SIM (Systems in Motion). SIM was later acquired by the Kongsberg group and renamed Kongsberg SIM . The Coin library had been written in a clean-room fashion from scratch, sharing no code with the original SGI Inventor library but implementing the same API for compatibility reasons. Kongsberg ended development of Coin3D in 2011, and released

360-438: Is available from SGI. Around the same time, the Coin3D API clone library was released by SIM (Systems in Motion). SIM was later acquired by the Kongsberg group and renamed Kongsberg SIM . The Coin library had been written in a clean-room fashion from scratch, sharing no code with the original SGI Inventor library but implementing the same API for compatibility reasons. Kongsberg ended development of Coin3D in 2011, and released

400-535: The IRIS Inventor project. Their goal was to create a toolkit that made developing 3D graphics applications easier to do. The strategy was based on the premise that people were not developing enough 3D applications with IRIS GL because it was too time-consuming to do so with the low-level interface provided by IRIS GL. If 3D programming were made easier, through the use of an object oriented API, then more people would create 3D applications and SGI would benefit. Therefore,

440-479: The IRIS Inventor project. Their goal was to create a toolkit that made developing 3D graphics applications easier to do. The strategy was based on the premise that people were not developing enough 3D applications with IRIS GL because it was too time-consuming to do so with the low-level interface provided by IRIS GL. If 3D programming were made easier, through the use of an object oriented API, then more people would create 3D applications and SGI would benefit. Therefore,

SECTION 10

#1733093165501

480-659: The Inventor team left to form their own group, which founded the basis of the OpenGL Performer project. Performer was also based on an internal scene graph, but was allowed to modify it for better speed as it saw fit, even dropping “less important” objects and polygons in order to maintain guaranteed performance levels. Performer also used a number of processes to run tasks in parallel for added performance, allowing it to be run (in one version) on multiple processors. Unlike Inventor, Performer remained proprietary so that SGI would have

520-550: The Inventor team left to form their own group, which founded the basis of the OpenGL Performer project. Performer was also based on an internal scene graph, but was allowed to modify it for better speed as it saw fit, even dropping “less important” objects and polygons in order to maintain guaranteed performance levels. Performer also used a number of processes to run tasks in parallel for added performance, allowing it to be run (in one version) on multiple processors. Unlike Inventor, Performer remained proprietary so that SGI would have

560-519: The OpenGL Performer project, spawned from the same context, emphasized performance optimization. The two projects later converged in an attempt to strike a balance between accessibility and performance, culminating in initiatives like Cosmo 3D and OpenGL++. These projects underwent various stages of development and refinement, contributing to the evolution of 3D graphics programming paradigms. Around 1988–1989, Wei Yen asked Rikk Carey to lead

600-460: The OpenGL Performer project, spawned from the same context, emphasized performance optimization. The two projects later converged in an attempt to strike a balance between accessibility and performance, culminating in initiatives like Cosmo 3D and OpenGL++. These projects underwent various stages of development and refinement, contributing to the evolution of 3D graphics programming paradigms. Around 1988–1989, Wei Yen asked Rikk Carey to lead

640-512: The agility to modify the API as needed to keep in step with the latest hardware enhancements. At some point in the mid-1990s it was realized that there was no good reason that the two systems could not be combined, resulting in a single high-level API with both performance and programmability. SGI started work on yet another project aimed at merging the two, eventually culminating in Cosmo 3D . However Cosmo had

680-419: The agility to modify the API as needed to keep in step with the latest hardware enhancements. At some point in the mid-1990s it was realized that there was no good reason that the two systems could not be combined, resulting in a single high-level API with both performance and programmability. SGI started work on yet another project aimed at merging the two, eventually culminating in Cosmo 3D . However Cosmo had

720-502: The code under the BSD 3-clause license. The open-source version from SGI is not maintained, and SGI has not indicated a commitment to further develop the library. The open-source release is used in MeVisLab (MeVis Medical Solutions AG and Fraunhofer MEVIS), however, and development of that continues. Thermo Scientific Open Inventor is still being developed, and has added a number of improvements to

760-405: The code under the BSD 3-clause license. The open-source version from SGI is not maintained, and SGI has not indicated a commitment to further develop the library. The open-source release is used in MeVisLab (MeVis Medical Solutions AG and Fraunhofer MEVIS), however, and development of that continues. Thermo Scientific Open Inventor is still being developed, and has added a number of improvements to

800-940: The concept of a pfGeoSet and a pfGeoState . A pfGeoSet is a collection of graphics primitives, such as polygons or lines. A pfGeoState encapsulates properties pertaining to a given pfGeoSet such as lighting, transparency, and texturing. The libpf library includes functions for the generation and manipulation of hierarchical scene graphs, scene processing (simulation, intersection, culling, and drawing tasks), level-of-detail management, asynchronous database paging, dynamic coordinate systems, environment models, light points, and so on. This library also provides transparent support for multiple viewports spread across multiple graphics pipelines. Other Performer libraries-- libpfutil, libpfdb, libpfui, etc.--provide functions for generating optimized geometry, database conversion, device input (such as for interfacing with external flyboxes and MIL-STD-1553 mux busses), motion models, collision models, and

840-427: The credo was always “ease of use” before “performance”, and soon the tagline “3D programming for humans” was being used widely. OpenGL (OGL) is a low level application programming interface that takes lists of simple polygons and renders them as quickly as possible. To do something more practical like “draw a house”, the programmer must break down the object into a series of simple OGL instructions and send them into

SECTION 20

#1733093165501

880-427: The credo was always “ease of use” before “performance”, and soon the tagline “3D programming for humans” was being used widely. OpenGL (OGL) is a low level application programming interface that takes lists of simple polygons and renders them as quickly as possible. To do something more practical like “draw a house”, the programmer must break down the object into a series of simple OGL instructions and send them into

920-425: The data in the scene graph by hand. Another practical problem was that OI could only be used with its own file format, forcing developers to write converters to and from the internal system. About a year into the Inventor project, a different philosophy began to emerge. Instead of simply making it easy to write applications on SGI systems, the goal was changed to make it difficult to write slow applications. Members of

960-425: The data in the scene graph by hand. Another practical problem was that OI could only be used with its own file format, forcing developers to write converters to and from the internal system. About a year into the Inventor project, a different philosophy began to emerge. Instead of simply making it easy to write applications on SGI systems, the goal was changed to make it difficult to write slow applications. Members of

1000-444: The engine for rendering. One problem is that OGL performance is highly sensitive to the way these instructions are sent into the system, requiring the user to know which instructions to send and in which order, and forcing them to carefully cull the data to avoid sending in objects that aren't even visible in the resulting image. For simple programs a tremendous amount of programming has to be done just to get started. Open Inventor (OI)

1040-444: The engine for rendering. One problem is that OGL performance is highly sensitive to the way these instructions are sent into the system, requiring the user to know which instructions to send and in which order, and forcing them to carefully cull the data to avoid sending in objects that aren't even visible in the resulting image. For simple programs a tremendous amount of programming has to be done just to get started. Open Inventor (OI)

1080-531: The mid-1990s it started to become clear that there was no reason that Inventor and Performer could not be combined. This led to the Cosmo 3D project that SGI was intending to build both Inventor and Performer (now essentially API shims ) out of, as well as promote as a new and higher-level standardized API for future work on the SGI platform. However, after the first beta release of Cosmo 3D, SGI joined with Intel and IBM (and later DEC ) to create OpenGL++ , essentially

1120-530: The original Inventor API for medical imaging , medical image computing , 3D reflection seismology , and petroleum reservoir modeling. The Open Inventor API is still commonly used for a wide range of scientific and engineering visualization systems around the world for the development of complex 3D application software. TGS was acquired by Mercury Computer Systems in 2004. It became an independent company, Visualization Sciences Group (VSG), in June 2009. In 2012, VSG

1160-483: The original Inventor API for medical imaging , medical image computing , 3D reflection seismology , and petroleum reservoir modeling. The Open Inventor API is still commonly used for a wide range of scientific and engineering visualization systems around the world for the development of complex 3D application software. TGS was acquired by Mercury Computer Systems in 2004. It became an independent company, Visualization Sciences Group (VSG), in June 2009. In 2012, VSG

1200-527: The requirements of the GNU Lesser General Public License (LGPL), version 2.1. The primary objective was to make 3D programming accessible by introducing an object-oriented API, allowing developers to create complex scenes without the intricacies of low-level OpenGL. The toolkit incorporated features like scene graphs, pre-defined shapes, and automatic occlusion culling to streamline scene management. While Open Inventor focused on ease of use,

1240-452: The requirements of the GNU Lesser General Public License (LGPL), version 2.1. The primary objective was to make 3D programming accessible by introducing an object-oriented API, allowing developers to create complex scenes without the intricacies of low-level OpenGL. The toolkit incorporated features like scene graphs, pre-defined shapes, and automatic occlusion culling to streamline scene management. While Open Inventor focused on ease of use,

OpenGL Performer - Misplaced Pages Continue

1280-467: The scene, making common interaction tasks easier. Finally, OI also supplied a common file format for storing “worlds,” and the code to automatically save or load a world from these files. Basic 3D applications could then be written in a few hundred lines under OI, by tying together portions of the toolkit with “glue” code. On the downside OI tended to be slower than hand-written code, as 3D tasks are notoriously difficult to make perform well without shuffling

1320-467: The scene, making common interaction tasks easier. Finally, OI also supplied a common file format for storing “worlds,” and the code to automatically save or load a world from these files. Basic 3D applications could then be written in a few hundred lines under OI, by tying together portions of the toolkit with “glue” code. On the downside OI tended to be slower than hand-written code, as 3D tasks are notoriously difficult to make perform well without shuffling

1360-513: The similar Fahrenheit project, which also died. In 1994 SGI licensed Open Inventor to two third-party developers, Template Graphics Software (TGS) and Portable Graphics; in 1996 TGS bought Portable Graphics, making them the sole licensee. After many years of being solely available under proprietary licensing from TGS (now FEI ), Inventor was released under the LGPL open source license in August 2000 and

1400-418: The similar Fahrenheit project, which also died. In 1994 SGI licensed Open Inventor to two third-party developers, Template Graphics Software (TGS) and Portable Graphics; in 1996 TGS bought Portable Graphics, making them the sole licensee. After many years of being solely available under proprietary licensing from TGS (now FEI ), Inventor was released under the LGPL open source license in August 2000 and

1440-458: The use of symmetric multi-processing capabilities, support multiple graphics pipes and the ability to utilize the scalable resources of high end systems. In this regard Performer was actually simple to use given the underlying complexity. Application culling and rendering could be running in different threads locked to different physical processors. In a multi-pipe (multiple graphics subsystems) configuration rendering to each graphics pipe would have

1480-647: Was acquired by FEI Company. FEI Company was acquired in 2016 by the Thermo Fisher Scientific Materials & Structural Analysis Division, which continues to develop (and support) Open Inventor. Open Inventor Open Inventor , originally IRIS Inventor , is a C++ object-oriented retained mode 3D graphics toolkit designed by SGI to provide a higher layer of programming for OpenGL . Its main goals are better programmer convenience and efficiency. Open Inventor exists as both proprietary software and free and open-source software , subject to

1520-507: Was hidden beneath a simpler scene graph API with relatively high level configuration calls which could be made to set up the threads and inter-process communication. Performer did not have a native file format, merely plugin loaders from 3rd parties such as MultiGen's OpenFlight format loader. Similarly there was no default runtime, there was sample code and the often used and often modified 'perfly' sample application. This probably contributed to its reputation for being difficult to use. By

1560-447: Was written to address this issue, and provide a common base layer to start working with. Objects could be subclassed from a number of pre-rolled shapes like cubes and polygons, and then easily modified into new shapes. The “world” to be drawn was placed in a scene graph run by OI, with the system applying occlusion culling on objects in the graph automatically. OI also included a number of controller objects and systems for applying them to

1600-447: Was written to address this issue, and provide a common base layer to start working with. Objects could be subclassed from a number of pre-rolled shapes like cubes and polygons, and then easily modified into new shapes. The “world” to be drawn was placed in a scene graph run by OI, with the system applying occlusion culling on objects in the graph automatically. OI also included a number of controller objects and systems for applying them to

#500499