FGFS-4.1/OpenSceneGraph
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Typo and grammer fixes to introduction.html from Neil Salter.

Browse Source
This commit is contained in:
Robert Osfield 2002-05-21 19:34:16 +00:00
parent bf872fa7ac
commit 50301583f4
1 changed files with 79 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
doc/introduction.html
View File

@ -36,12 +36,12 @@
<h2>
<u>Introduction to the OpenSceneGraph</u></h2>
Welcome to OpenSceneGraph project!
<p>The OpenSceneGraph is an Open Source (LGPL), Cross Platform (Widows,
<p>The OpenSceneGraph is an Open Source (LGPL), Cross Platform (Windows,
Linux, Mac OSX, FreeBSD, Irix, Solaris), Standard C++ and OpenGL based
graphics development library, uses range from visual simulation, games,
virtual reality, scientific visualization and graphics research. This pages
graphics development library. Uses range from visual simulation, games,
virtual reality, scientific visualization and graphics research. This page
introduces what scene graphs are, why graphics developers use them, and
details about the OpenSceneGraph, project, how to learn how to use it and
details about the OpenSceneGraph project, how to learn how to use it and
contribute to the OpenSceneGraph community.
<p><i>Robert Osfield, Project Lead. April 2002.</i>
<br>
@ -49,22 +49,22 @@ contribute to the OpenSceneGraph community.
<h3>
<u>What is a Scene Graph?</u></h3>
Its a tree! Quite simply one the best and most reusable data structures
invented. Typically drawn schematically as root at the top, leaves at the
bottom. It all starts with a topmost root node which encompasses your whole
virtual world, be it 2D or 3D. The world is then broken down into hierarchy
of nodes representing either a spatial grouping of objects, setting the
position of objects, animating objects,. or define a logical relationship
between objects such as to manage the various states of a traffic light.
invented. Typically drawn schematically with the root at the top, leaves at the
bottom. It all starts with a top-most root node which encompasses your whole
virtual world, be it 2D or 3D. The world is then broken down into a hierarchy
of nodes representing either spatial groupings of objects, settings of the
position of objects, animations of objects, or definitions of logical relationships
between objects such as those to manage the various states of a traffic light.
The leaves of the graph represent the physical objects themselves, the
drawable geometry and their material properties.
<p>A scene graph isn't a complete game or simulation engine, although may
be one of the main components of such an engine, it's primary focus is
representing your 3d worlds, and rendering it efficiently. Physics models,
<p>A scene graph isn't a complete game or simulation engine, although it may
be one of the main components of such an engine; it's primary focus is
representation of your 3d worlds, and efficient rendering thereof. Physics models,
collision detection and audio are left to other development libraries that
a user will integrate with.. The fact that scene graphs don't typically
integrate all these features is actually a really good thing, it aids interoprability
with clients own applications and tools they wish to use and allows them
to serve many varied markets from games, visual simulation, virtual reality,
a user will integrate with. The fact that scene graphs don't typically
integrate all these features is actually a really good thing: it aids interoprability
with clients' own applications and tools and allows them to serve many varied
markets from games, visual simulation, virtual reality,
scientific and commercial visualization, training through to modeling programs.
<br>
<hr>
@ -72,27 +72,27 @@ scientific and commercial visualization, training through to modeling programs.
<u>Why use a Scene Graph - Performance, Productivity, Portability and Scalability</u>.</h3>
<ol><i>Performance</i> - scene graphs provide an excellent framework for
maximize graphics performance. A good scene graph employs two key techniques
maximizing graphics performance. A good scene graph employs two key techniques
- culling of the objects that won't be seen on screen, and state sorting
of properties such as textures and materials so that all similar objects
of properties such as textures and materials, so that all similar objects
are drawn together. Without culling the CPU, buses and GPU will all become
swamped by many times the amount of data than they actually require to
represent you work accurately. The hierarchical structure of the scene
represent your work accurately. The hierarchical structure of the scene
graph makes this culling process very efficient with whole town being culled
with just a few operations! Without state sorting, the the buses and GPU
will thrash between states, stalling the graphics and destroying graphics
throughout. As GPU's get faster and faster, the cost of stalling the graphics
is also going up, so scene graph are become ever more important.
<p><i>Productivity</i> - scene graphs take much of the hard work required
to develop high performance graphics applications. The scene graphs manage
will thrash between states, stalling the graphics pipeline and destroying graphics
througput. As GPU's get faster and faster, the cost of stalling the graphics
is also going up, so scene graphs are becoming ever more important.
<p><i>Productivity</i> - scene graphs take away much of the hard work required
to develop high performance graphics applications. The scene graph manages
all the graphics for you, reducing what would be thousands of lines of
OpenGL down to a few simple calls. Furthermore, one of most powerful concepts
in Object Orientated programming is that of object composition, enshrined
in <i>Composite Design Pattern</i>, which fits the scene graph tree structure
perfectly which makes it highly flexible and reusable design - in real
terms this means that it can be easily adapted it to solve your problems.
Scene graph also often come additional utility libraries which range for
helping users set up and manage graphics windows to import of 3d modes
in Object Oriented programming is that of object composition, enshrined
in the <i>Composite Design Pattern</i>, which fits the scene graph tree structure
perfectly and makes it a highly flexible and reusable design - in real
terms this means that it can be easily adapted to solve your problems.
With scene graphs often also come additional utility libraries which range from
helping users set up and manage graphics windows to importing of 3d models
and images. All this together allows the user to achieve a great deal with
very little coding. A dozen lines of code can be enough to load your data
and create an interactive viewer!
@ -100,7 +100,7 @@ and create an interactive viewer!
tasks of rendering graphics and reading and writing data, reducing or even
eradicating the platform specific coding that you require in your own application.
If the underlying scene graph is portable then moving from platform to
platform can be a simple as recompiling your source code.
platform can be as simple as recompiling your source code.
<p><i>Scalability</i> - along with being able to dynamic manage the complexity
of scenes automatically to account for differences in graphics performance
across a range of machines, scene graphs also make it much easier to manage
@ -118,75 +118,75 @@ the benefits of scene graph technology available to all. Our scene graph
is still in development, but has already gained a great deal of respect
amongst the development community for its high performance, cleanness of
design and portability. Written entirely in Standard C++ and OpenGL, it
makes full use of STL and Design Patterns, and leverages the open source
makes full use of the STL and Design Patterns, and leverages the open source
development model to provide a development library that is legacy free
and well focused on the solving the task. The OpenSceneGraph delivers on
the four key benefits of scene graph technology outlined above using the
following features:
<ol><i>Performance</i> - supports view frustum culling, small feature culling,
Level Of Details (LOD') nodes, state sorting, vertex arrays and display
list as part of the core scene graph, these together make the OpenSceneGraph
one highest performance scene graph available. User feedback is that performance
surpasses much more established scene graphs such as Performer, VTee, Vega
Scene Graph and Jave3D! The OpenSceneGraph also supports easy customization
of the drawing process, which has allowed implementation of Continuos Level
of Detail (CLOD) meshes on top the scene graph, these allow the visualization
Level Of Detail (LOD) nodes, state sorting, vertex arrays and display
lists as part of the core scene graph. These together make the OpenSceneGraph
one of the highest performance scene graph available. User feedback is that
performance surpasses that of much more established scene graphs such as Performer, VTree, Vega
Scene Graph and Java3D! The OpenSceneGraph also supports easy customization
of the drawing process, which has allowed implementation of Continuous Level
of Detail (CLOD) meshes on top the scene graph. These allow the visualization
of massive terrain databases interactively, examples of this approach can
be found at both Vterrain.org and TerrainEngine.com which both integrate
be found at Vterrain.org and TerrainEngine.com, both of which integrate
with the OpenSceneGraph.
<p><i>Productivity</i> - by combining lessons learned from established
scene graph like Performer and Open Inventor, with modern software engineering
methodologies like Design Patterns and a great deal of feedback early on
in the development cycle, it has been possible to design a design that
clean and highly interpretable. This has made it easy for user to adopt
to the OpenSceneGraph and to integrate with their own applications. With
scene graphs like Performer and Open Inventor, with modern software engineering
boosts like Design Patterns, along with a great deal of feedback early on
in the development cycle, it has been possible to design a library that is
clean and highly interpretable. This has made it easy for users to adopt
to the OpenSceneGraph and to integrate it with their own applications. With
a full feature set in the core scene graph, utilities to set up the scene
graph and viewers and a wide range of loaders it is possible to create
an application and bring in user data with a very small amount of code.
<p><i>Portability</i> - The core scene graph has also been designed to
be have minimal platform specific dependency, requiring little more than
Standard C++ and OpenGL. The has allowed the scene graph to be rapidly
ported on wide range of platforms - originally developed on IRIX, then
have minimal dependency on any specific platform, requiring little more than
Standard C++ and OpenGL. This has allowed the scene graph to be rapidly
ported to a wide range of platforms - originally developed on IRIX, then
ported to Linux, then to Windows, then FreeBSD, then Mac OSX and most recently
Solaris! Being completely windowing system independent makes it easy for
users to add their own window specific libraries and applications on top.
users to add their own window-specific libraries and applications on top.
In the distribution there is already the osgGLUT library, and in the Bazaar
found at openscenegrph.org/download/ once can find examples of how applications
written on top Qt, MFC, WxWindows and SDL. Users have also integrated it
found at openscenegrph.org/download/ one can find examples of applications
written on top of Qt, MFC, WxWindows and SDL. Users have also integrated it
with Motif, and X.
<p><i>Scalability</i> - the scene graph not only runs from portables all
<p><i>Scalability</i> - the scene graph will not only run on portables all
the way up to Onyx Infinite Reality Monsters, it supports the multiple
graphics subsystems found on machines like the a mulitpipe Onyx. This is
possible since the core scene graph supports multiple graphics context
for both OpenGL DisplayLists and texture objects, and the cull and draw
graphics subsystems found on machines like a mulitpipe Onyx. This is
possible because the core scene graph supports multiple graphics contexts
for both OpenGL Display Lists and texture objects, and the cull and draw
traversals have been designed to cache rendering data locally and use the
scene gaph almost entirely as a read only operation. This allows multiple
scene graph almost entirely as a read-only operation. This allows multiple
cull-draw pairs to run on multiple CPU's which are bound to multiple graphics
subsystems. This has been demonstrated using the OpenSceneGraph in conjunction
with sgi's OpenGL multipipe SDK. We also have osgMP in development which
will be cross platform and transparently support multiple multipipe systems
with SGI's OpenGL multipipe SDK. We also have osgMP in development, which
will be cross platform and will transparently support multiple multipipe systems
like the Onyx and graphics clusters</ol>
All the source to is published under the GNU Library General Public License
All the source to the OSG is published under the GNU Lesser General Public License
(LGPL) which allows both open source and closed source projects to use,
modify and distribute it freely as long its usage complies with the LGPL.
The project has been developed over the last four years, initiated by Don
Burns, and then taken over by Robert Osfield who continues to lead project
today, there are many other contributors to the library, for a full list
Burns, and then taken over by Robert Osfield who continues to lead the project
today. There are many other contributors to the library, for a full list
check out the AUTHORS file. Both Robert and Don now work on the OpenSceneGraph
in a professional capacity providing consultancy and bespoke developments
in a professional capacity providing consultancy and bespoke development
on top the library, and are also collaborating on the book. Work on the
core scene graph and support of public mailing list remains unpaid as are
the contributions of the rest of the community, but this hasn't impacted
the quality of the source or support which once you get stuck in you grow
to appreciate.
<p>The project is current in alpha, which means parts of the API are still
<p>The project is currently in alpha, which means parts of the API are still
to be developed, or subject to change, but the vast majority of the scene
graph is there, and a beta will be published within the next few months,
with a 1.0 release in late summer. Despite the alpha development status,
with a 1.0 release in late summer 2002. Despite the alpha development status,
the project has already earned the reputation the leading open source scene
graph, and is establishing itself a viable alternative to the commercial
graph, and is establishing itself as a viable alternative to the commercial
scene graphs. Numerous companies, university researchers and graphics enthusiasts
have already adopted their projects, and are from all over the world.
have already adopted the OpenSceneGraph for their projects, all over the world.
<br>
<hr>
<h3>
@ -204,28 +204,27 @@ the OpenSceneGraph.
<p>The development distribution contains the libraries (.dll's /.so's),
demo executables, include files, and source to the demos. This is suitable
for using the developers using the OpenSceneGraph.
<p>The source distribution contains the all the source and include files
<p>The source distribution contains all the source and include files
required to build the OpenSceneGraph from scratch, and is ideal if you
want to learn more about how the scene graph works, how to extend it, and
to
track down and fix any problems that you come across.
to track down and fix any problems that you come across.
<p>If you are using a source distribution then read the <a href="install.html">installation</a>
instructions for how to get the OpenSceneGraph compiling and installed
on your system. You may also need to download libraries that parts of the
OpenSceneGraph is dependent upon such as glut, check the <a href="dependencies.html">dependencies</a>
OpenSceneGraph depend upon, such as glut. Check the <a href="dependencies.html">dependencies</a>
list for further details.
<p>For full instructions of how to run the demos read the <a href="demos.html">demos</a>
page.
<br>
<hr>
<h3>
<u>How to learn to use the OpenSceneGraph</u></h3>
<u>Learning how to use the OpenSceneGraph</u></h3>
The OpenSceneGraph distribution comes with a reference guide for each of
the component libraries - osg, osgDB, osgUtil, osgText and osgGLUT, a set
of demos - the source of which can be found in src/Demos/. For questions
of demos - the source of which can be found in src/Demos. For questions
or help which can't be easily be answered by the reference guide and demo
source, one should join the mailing list (details below). There is also
the beginnings of <a href="http://www.c2.com/cgi/wiki?OpenSceneGraphFaq">Wiki
source, one should join the mailing list (details below). There are also
the beginnings of a <a href="http://www.c2.com/cgi/wiki?OpenSceneGraphFaq">Wiki
based FAQ</a> which may help answer a few of the common queries.
<p>A programming guide will be available in form of a OpenSceneGraph book
which is being written by Don Burns and Robert Osfield, parts of it will
@ -233,15 +232,15 @@ be available online.
<p>Although not directly related to the OpenSceneGraph, once can learn
about scene graph technology from such sources as the <a href="http://www.sgi.com/software/inventor/manuals.html">Open
Inventor Mentor</a>, and <a href="http://www.cineca.it/manuali/Performer/ProgGuide24/html">Performer
Programming Guides</a>. The later is the closest in design concepts to
the OpenSceneGraph, although Performer manuals is in C alas. Also of use
Programming Guides</a>. The latter is the closer in design to
the OpenSceneGraph, although the Performer manuals are in C, alas. Also of use
as a background to some of the techniques used is a SIGGRAPH <a href="http://www.opengl.org/developers/code/sig99/advanced99/course_slides/vissim/index.htm">Vis-Sim
course</a>.
<p>The OpenSceneGraph uses OpenGL and does with a deliberately thin layer,
<p>The OpenSceneGraph uses OpenGL and does so with a deliberately thin layer,
making it easy to control the underlying OpenGL and to extend it with OpenGL
extensions. The close tie with OpenGL is also reflected in the naming of
many of the OpenGL state related classes, the the parameters that they
encapsulate and means that knowledge of OpenGL itself will go a long way
many of the OpenGL state related classes, and the parameters that they
encapsulate, which means that knowledge of OpenGL itself will go a long way
to understanding how to get the best out of the OpenSceneGraph. To this
end it is worth obtaining a copy of the OpenGL programming guide - <a href="http://fly.cc.fer.hr/~unreal/theredbook/">`Red
Book`</a> and OpenGL reference guide 'Blue Book'. The main <a href="http://www.opengl.org">OpenGL