root/OpenSceneGraph/trunk/doc/introduction.html @ 1912

Revision 1912, 15.3 kB (checked in by robert, 14 years ago)

Updates to docs.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
[647]1<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
[647]4   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5   <meta name="GENERATOR" content="Mozilla/4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) [Netscape]">
[651]6   <title>Introduction to the OpenSceneGraph</title>
[647]8<body bgcolor="#FFFFFF">
[1912]9<img SRC="images/OpenSceneGraphBanner_Distribution.jpg" BORDER=0>
12<td><a href="index.html">Index</a></td>
14<td><a href="introduction.html">Introduction</a></td>
16<td><a href="contents.html">Contents</a></td>
18<td><a href="install.html">Install</a></td>
20<td><a href="dependencies.html">Dependencies</a></td>
[1862]22<td><a href="examples.html">examples</a></td>
24<td><a href="data.html">Data</a></td>
[1862]26<td><a href="osgviewer.html">Viewer</a></td>
28<td><a href="stereo.html">Stereo</a></td>
30<td><a href="plan.html">Plan</a></td>
32<td><a href="documentation.html">Reference Guides</a></td>
37<u>Introduction to the OpenSceneGraph</u></h2>
38Welcome to OpenSceneGraph project!
[1912]39<p>The OpenSceneGraph is an Open Source <a href="../LICENSE.txt">(OSGPL)</a>, Cross Platform (Windows,
40Linux, Mac OSX, FreeBSD, Irix, Solaris and HP-UX), Standard C++ and OpenGL based
[700]41graphics development library. Uses range from visual simulation, games,
42virtual reality, scientific visualization and graphics research. This page
[647]43introduces what scene graphs are, why graphics developers use them, and
[700]44details about the OpenSceneGraph project, how to learn how to use it and
[647]45contribute to the OpenSceneGraph community.
[945]46<p><i>Robert Osfield, Project Lead. July 2002.</i>
50<u>What is a Scene Graph?</u></h3>
51Its a tree! Quite simply one the best and most reusable data structures
[700]52invented. Typically drawn schematically with the root at the top, leaves at the
53bottom. It all starts with a top-most root node which encompasses your whole
54virtual world, be it 2D or 3D. The world is then broken down into a hierarchy
55of nodes representing either spatial groupings of objects, settings of the
56position of objects, animations of objects, or definitions of logical relationships
57between objects such as those to manage the various states of a traffic light.
[647]58The leaves of the graph represent the physical objects themselves, the
59drawable geometry and their material properties.
[700]60<p>A scene graph isn't a complete game or simulation engine, although it may
61be one of the main components of such an engine; it's primary focus is
62representation of your 3d worlds, and efficient rendering thereof. Physics models,
[647]63collision detection and audio are left to other development libraries that
[700]64a user will integrate with. The fact that scene graphs don't typically
65integrate all these features is actually a really good thing: it aids interoprability
66with clients' own applications and tools and allows them to serve many varied
67markets from games, visual simulation, virtual reality,
[647]68scientific and commercial visualization, training through to modeling programs.
72<u>Why use a Scene Graph - Performance, Productivity, Portability and Scalability</u>.</h3>
[1868]74<ol><b><i>Performance</i></b> - scene graphs provide an excellent framework for
[700]75maximizing graphics performance. A good scene graph employs two key techniques
[647]76- culling of the objects that won't be seen on screen, and state sorting
[700]77of properties such as textures and materials, so that all similar objects
[647]78are drawn together. Without culling the CPU, buses and GPU will all become
79swamped by many times the amount of data than they actually require to
[700]80represent your work accurately. The hierarchical structure of the scene
[647]81graph makes this culling process very efficient with whole town being culled
82with just a few operations! Without state sorting, the the buses and GPU
[700]83will thrash between states, stalling the graphics pipeline and destroying graphics
84througput. As GPU's get faster and faster, the cost of stalling the graphics
85is also going up, so scene graphs are becoming ever more important.
[1868]86<p><b><i>Productivity</i></b> - scene graphs take away much of the hard work required
[700]87to develop high performance graphics applications. The scene graph manages
[647]88all the graphics for you, reducing what would be thousands of lines of
[659]89OpenGL down to a few simple calls. Furthermore, one of most powerful concepts
[700]90in Object Oriented programming is that of object composition, enshrined
91in the <i>Composite Design Pattern</i>, which fits the scene graph tree structure
92perfectly and makes it a highly flexible and reusable design - in real
93terms this means that it can be easily adapted to solve your problems.
94With scene graphs often also come additional utility libraries which range from
95helping users set up and manage graphics windows to importing of 3d models
[647]96and images. All this together allows the user to achieve a great deal with
97very little coding. A dozen lines of code can be enough to load your data
[594]98and create an interactive viewer!
[1868]99<p><b><i>Portability</i></b> - scene graphs encapsulate much of the lower level
[647]100tasks of rendering graphics and reading and writing data, reducing or even
101eradicating the platform specific coding that you require in your own application.
102If the underlying scene graph is portable then moving from platform to
[700]103platform can be as simple as recompiling your source code.
[1868]104<p><b><i>Scalability</i></b> - along with being able to dynamic manage the complexity
[647]105of scenes automatically to account for differences in graphics performance
106across a range of machines, scene graphs also make it much easier to manage
107complex hardware configurations, such as clusters of graphics machines,
108or multiprocessor/multipipe systems such as SGI's Onyx. A good scene graph
109will allow the developer to concentrate on developing their own application
110while the rendering framework of the scene graph handles the different
[659]111underlying hardware configurations.</ol>
115<u>So what about the OpenSceneGraph project?</u></h3>
116The OpenSceneGraph is an Open Source Scene Graph, and our goal is make
117the benefits of scene graph technology available to all. Our scene graph
118is still in development, but has already gained a great deal of respect
119amongst the development community for its high performance, cleanness of
120design and portability. Written entirely in Standard C++ and OpenGL, it
[700]121makes full use of the STL and Design Patterns, and leverages the open source
[647]122development model to provide a development library that is legacy free
123and well focused on the solving the task. The OpenSceneGraph delivers on
124the four key benefits of scene graph technology outlined above using the
125following features:
[1868]126<ol><b><i>Performance</i></b> - supports view frustum culling, occlusion culling, small feature culling,
[700]127Level Of Detail (LOD) nodes, state sorting, vertex arrays and display
128lists as part of the core scene graph. These together make the OpenSceneGraph
129one of the highest performance scene graph available. User feedback is that
130performance surpasses that of much more established scene graphs such as Performer, VTree, Vega
131Scene Graph and Java3D! The OpenSceneGraph also supports easy customization
132of the drawing process, which has allowed implementation of Continuous Level
133of Detail (CLOD) meshes on top the scene graph. These allow the visualization
[647]134of massive terrain databases interactively, examples of this approach can
[700]135be found at and, both of which integrate
[647]136with the OpenSceneGraph.
[1868]137<p><b><i>Productivity</i></b> - by combining lessons learned from established
[700]138scene graphs like Performer and Open Inventor, with modern software engineering
139boosts like Design Patterns, along with a great deal of feedback early on
140in the development cycle, it has been possible to design a library that is
141clean and highly interpretable. This has made it easy for users to adopt
142to the OpenSceneGraph and to integrate it with their own applications. With
[647]143a full feature set in the core scene graph, utilities to set up the scene
144graph and viewers and a wide range of loaders it is possible to create
145an application and bring in user data with a very small amount of code.
[1868]146<p><b><i>Portability</i></b> - The core scene graph has also been designed to
[700]147have minimal dependency on any specific platform, requiring little more than
148Standard C++ and OpenGL. This has allowed the scene graph to be rapidly
149ported to a wide range of platforms - originally developed on IRIX, then
[1912]150ported to Linux, then to Windows, then FreeBSD, Mac OSX, Solaris, HP-UX and
151even a report of successful porting to PlayStation2!
153The core scene graph library being completely windowing system independent makes
154it easy for users to add their own window-specific libraries and applications on top.
155In the distribution there is already the osgProducer library which integrates with <a href="">OpenProducer</a>, and in the Bazaar
[700]156found at one can find examples of applications
157written on top of Qt, MFC, WxWindows and SDL. Users have also integrated it
[647]158with Motif, and X.
[1868]159<p><b><i>Scalability</i></b> - the scene graph will not only run on portables all
[659]160the way up to Onyx Infinite Reality Monsters, it supports the multiple
[700]161graphics subsystems found on machines like a mulitpipe Onyx. This is
162possible because the core scene graph supports multiple graphics contexts
163for both OpenGL Display Lists and texture objects, and the cull and draw
[659]164traversals have been designed to cache rendering data locally and use the
[700]165scene graph almost entirely as a read-only operation. This allows multiple
[659]166cull-draw pairs to run on multiple CPU's which are bound to multiple graphics
[1868]167subsystems. Support for multiple graphic context and multi-threading is all
168available out of the box via osgProducer - all the examples in the distribution
169can run multi-pipe just by use a simple configuation file.</ol>
[1912]171All the source to the OSG is published under the Open Scene Graph Public License
172(a relaxed version on the LGPL) which allows both open source and closed source projects to use,
173modify and distribute it freely as long its usage complies with the OSGPL.
[647]174The project has been developed over the last four years, initiated by Don
[700]175Burns, and then taken over by Robert Osfield who continues to lead the project
176today. There are many other contributors to the library, for a full list
[647]177check out the AUTHORS file. Both Robert and Don now work on the OpenSceneGraph
[700]178in a professional capacity providing consultancy and bespoke development
[647]179on top the library, and are also collaborating on the book. Work on the
180core scene graph and support of public mailing list remains unpaid as are
181the contributions of the rest of the community, but this hasn't impacted
182the quality of the source or support which once you get stuck in you grow
183to appreciate.
[945]184<p>The project is currently in beta, which means the main core features are now in
[1868]185place, with a 1.0 release in second half of 2003. Despite the beta development status,
[1912]186the project has already earned the reputation as the leading open source scene
[700]187graph, and is establishing itself as a viable alternative to the commercial
[647]188scene graphs. Numerous companies, university researchers and graphics enthusiasts
[700]189have already adopted the OpenSceneGraph for their projects, all over the world.
193<u>Getting started</u></h3>
194The first thing is to select the distribution which suits you, there are
195binary, development and source code distributions, these can be loaded
196from the
197<a href=""></a>
198page. The latest developments area available as via a nightly tarball or
199via cvs.
200<p>The binary distribution contains just the libraries (.dll's /.so's)
201and demo executables. This is suitable for using the OpenSceneGraph with
202an application that has already been compiled but depends at runtime on
203the OpenSceneGraph.
204<p>The development distribution contains the libraries (.dll's /.so's),
205demo executables, include files, and source to the demos. This is suitable
206for using the developers using the OpenSceneGraph.
[700]207<p>The source distribution contains all the source and include files
[647]208required to build the OpenSceneGraph from scratch, and is ideal if you
209want to learn more about how the scene graph works, how to extend it, and
[700]210to track down and fix any problems that you come across.
[647]211<p>If you are using a source distribution then read the <a href="install.html">installation</a>
212instructions for how to get the OpenSceneGraph compiling and installed
213on your system. You may also need to download libraries that parts of the
[1862]214OpenSceneGraph depend upon, such as Producer. Check the <a href="dependencies.html">dependencies</a>
[647]215list for further details.
[1868]216<p>For full instructions of how to run the examples read the <a href="examples.html">examples</a>
[700]221<u>Learning how to use the OpenSceneGraph</u></h3>
[647]222The OpenSceneGraph distribution comes with a reference guide for each of
[1868]223the component libraries - osg, osgDB, osgUtil, osgText, osgSim, osgParticle and osgProducer, a set
224of examples - the source of which can be found in examples. For questions
[647]225or help which can't be easily be answered by the reference guide and demo
[700]226source, one should join the mailing list (details below). There are also
227the beginnings of a <a href="">Wiki
[647]228based FAQ</a> which may help answer a few of the common queries.
229<p>A programming guide will be available in form of a OpenSceneGraph book
230which is being written by Don Burns and Robert Osfield, parts of it will
231be available online.
232<p>Although not directly related to the OpenSceneGraph, once can learn
233about scene graph technology from such sources as the <a href="">Open
234Inventor Mentor</a>, and <a href="">Performer
[700]235Programming Guides</a>. The latter is the closer in design to
236the OpenSceneGraph, although the Performer manuals are in C, alas. Also of use
[647]237as a background to some of the techniques used is a SIGGRAPH <a href="">Vis-Sim
[700]239<p>The OpenSceneGraph uses OpenGL and does so with a deliberately thin layer,
[647]240making it easy to control the underlying OpenGL and to extend it with OpenGL
241extensions. The close tie with OpenGL is also reflected in the naming of
[700]242many of the OpenGL state related classes, and the parameters that they
243encapsulate, which means that knowledge of OpenGL itself will go a long way
[647]244to understanding how to get the best out of the OpenSceneGraph. To this
245end it is worth obtaining a copy of the OpenGL programming guide - <a href="">`Red
246Book`</a> and OpenGL reference guide 'Blue Book'. The main <a href="">OpenGL
247website</a> is also a good source of links and further information.
251<u>Support and discussion - the <i>openscenegraph-news</i> mailing list</u></h3>
252For scene graph related questions, bug reports, bug fixes, and general
253design and development discussion one should join the <a href="">openscenegraph-news</a>
254mailing list, and check the the mailing list <a href="">archives</a>.
255<p>Professional support is also available in the form of confidential online,
256phone and onsite support and consultancy, for details contact Robert Osfield
257at <a href=""></a>.
Note: See TracBrowser for help on using the browser.