diff --git a/doc/contents.html b/doc/contents.html
index 58d311701..2d13cdd64 100644
--- a/doc/contents.html
+++ b/doc/contents.html
@@ -37,10 +37,6 @@ containing names of contributors to the osg.
file listing coarse grained changes between releases.
ChangeLog text file listing
fine grained changes between releases.
-
TODO text
-file listing left to implement/extend/rewrite.
-
FAQ
-text file listing Frequently asked questions.
Makefile Unix makefile.
index.html This file!
diff --git a/doc/demos.html b/doc/demos.html
index a533b6d99..3eb3710c9 100644
--- a/doc/demos.html
+++ b/doc/demos.html
@@ -2,162 +2,208 @@
Index | -Introduction | -Contents | -Install | -Dependencies | -Demos | -Data | -Viewer | -Stereo | -Plan | -Reference Guides | -
Index | + +Introduction | + +Contents | + +Install | + +Dependencies | + +Demos | + +Data | + +Viewer | + +Stereo | + +Plan | + +Reference Guides | +
-Once the OpenSceneGraph is installed you will need place the location where it was installed on the you systems paths -environmental variables, and then download the demo data and set the OSG_FILE_PATH so that the file loading can locate the datasets. -It is probably worth setting you autoexec.bat, .bashrc or.tcsh etc to pick up on these settings so that next time you log in -everything is in easy reach. -
--All the demos run on the commandline, most requiring parameters, such as what file to load, if you are in any doubt -just run the application and it will either run, or provide help on what options it accepts. -
- +- | sgv cow.osg | -The scene graph viewer demo uses osgGLUT::Viewer to bring up a basic viewer. To find out what - command line arguments it takes simply run sgv without any arguments. To load a model simple - run sgv filename.ext. The osgGLUT::Viewer provides an extensive set of operations that can be - used to display information about the loaded database such as peformance stas, through to - output a snapshot of the screen, which is how these thumbnails were created. For a full list - of key presses and mouse interaction read the sgv documentaion. | -
- | sgv -stereo cessna.osg | -The scene graph viewer also supports anaglyphic, quad buffered, and split screen stereo modes, - for a full list of options and environmental variables see the stereo documentaion. | -
- | hangglide | -The hang glide demo creates a simple flying site (Don Burns local hang glide site infact!), - demonstrating how to create simple terrain, trees and skydomes, and how to implement a simple - flight camera manipulator to allow the user to fly around. - | -
- | osgbillboard lz.rgb | -Demonstrates how to create the various types of billboard supported by the OpenSceneGraph. Billboards - are typically used for trees or particles effects. - | -
- | osgcube | -Simplest of all demos, create a cube geometry and spin it! - | -
- | osghud glider.osg | -Very similar to the basic sgv demo, but adds an othographic projection over the top of the main 3D view - to create a head up display effect. Also demonstrates how to use osgText. - . | -
- | ||
- | osgimpostor Town.osg | -OpenSceneGraph is unique amoung scene graph in the fact that it supports dynamically updated impostors natively, - and this demo uses osgUtil::InsertImpostorVisitor to traverse the loaded scene graph inserting osg::Importor nodes in place of groups - and LOD, so you can add Impostor into any of your own datasets! The scene graph then - takes over full repsonsibility for managing required multistage rendering all dynamically at runtime, whilest - keeping it neatly encapsulated making it incrediable easy to use. The Impostor support demonstrates how - powerful the multi-stage multi-pass rendering framework that the OpenSceneGraph has, almost all other scene - graphs have to hardwire such effects into them and require significant application coding to do so. - | -
- | osgreflect cow.osg | -An example of how to set up planar reflections using the standard multi-pass stencil buffer algorithm. This - is all handled within the scene graph, so there is no need to hardwire multi-pass effects into your own - application. - . | -
- | osgscribe.cow.osg | -An example of how to decorate your scene graph geometry for useful effects such as scribing. This demo - uses two instances of your model, the first one uses the state values set in your scene graph, the - second instance override the polygmode to render it as wireframe, and with a polyon offset to ensure it - is seen from all angles. These two instance are grouped together and then are treated like any other - scene graph. - | -
- | osgstereoimage left.rgb right.rgb | -An example of use node maks to select different parts of the scene graph for different traversals, in this - case two seperate images are drawn for the left and right eyes to generate a stereo 3D image from two flat - images! - . | -
- | osgtext | -An example showing how to creating the various different typs of text that the osgText library supports. - | -
- | osgtexture lz.rgb reflect.rgb | -An example showing how to creating the textured quads, each with different texture parameters, including - anistrophic filtering and texture compression! - | -
- | osgviews.cow.osg | -An example of multiple viewports all running at once. - | -sgv cow.osg | + +The scene graph viewer demo uses osgGLUT::Viewer to bring up a basic +viewer. To find out what command line arguments it takes simply run sgv +without any arguments. To load a model simple run sgv filename.ext. The +osgGLUT::Viewer provides an extensive set of operations that can be used +to display information about the loaded database such as performance stats, +through to output a snapshot of the screen, which is how these thumbnails +were created. For a full list of key presses and mouse interaction read +the sgv documentation. | + + +
+ + | sgv -stereo cessna.osg | + +The scene graph viewer also supports anaglyphic, quad buffered, and +split screen stereo modes, for a full list of options and environmental +variables see the stereo documentation. | +
+ + | hangglide | + +The hang glide demo creates a simple flying site (Don Burns local hang +glide site in fact!), demonstrating how to create simple terrain, trees +and skydomes, and how to implement a simple flight camera manipulator to +allow the user to fly around. | +
+ + | osgbillboard lz.rgb | + +Demonstrates how to create the various types of billboard supported +by the OpenSceneGraph. Billboards are typically used for trees or particles +effects. | +
+ + | osgcube | + +Simplest of all demos, create a cube geometry and spin it! | +
+ + | osghud glider.osg | + +Very similar to the basic sgv demo, but adds an orthographic projection +over the top of the main 3D view to create a head up display effect. Also +demonstrates how to use osgText. . | +
+ + | osgimpostor Town.osg | + +OpenSceneGraph is unique among scene graph in the fact that it supports +dynamically updated impostors natively, and this demo uses osgUtil::InsertImpostorVisitor +to traverse the loaded scene graph inserting osg::Importor nodes in place +of groups and LOD, so you can add Impostor into any of your own datasets! +The scene graph then takes over full responsibility for managing required +multistage rendering all dynamically at runtime, whilst keeping it neatly +encapsulated making it incredible easy to use. The Impostor support demonstrates +how powerful the multi-stage multi-pass rendering framework that the OpenSceneGraph +has, almost all other scene graphs have to hardwire such effects into them +and require significant application coding to do so. | +
+ + | osgreflect cow.osg | + +An example of how to set up planar reflections using the standard multi-pass +stencil buffer algorithm. This is all handled within the scene graph, so +there is no need to hardwire multi-pass effects into your own application. +. | +
+ + | osgscribe.cow.osg | + +An example of how to decorate your scene graph geometry for useful +effects such as scribing. This demo uses two instances of your model, the +first one uses the state values set in your scene graph, the second instance +override the polygmode to render it as wireframe, and with a polygon offset +to ensure it is seen from all angles. These two instance are grouped together +and then are treated like any other scene graph. | +
+ + | osgstereoimage left.rgb right.rgb | + +An example of use node maks to select different parts of the scene +graph for different traversals, in this case two separate images are drawn +for the left and right eyes to generate a stereo 3D image from two flat +images! . | +
+ + | osgtext | + +An example showing how to creating the various different typs of text +that the osgText library supports. | +
+ + | osgtexture lz.rgb reflect.rgb | + +An example showing how to creating the textured quads, each with different +texture parameters, including anisotrophic filtering and texture compression! | +
+ + | osgviews.cow.osg | + +An example of multiple viewports all running at once. | +
Index | -Introduction | -Contents | -Install | -Dependencies | -Demos | -Data | -Viewer | -Stereo | -Plan | -Reference Guides | -
Index | + +Introduction | + +Contents | + +Install | + +Dependencies | + +Demos | + +Data | + +Viewer | + +Stereo | + +Plan | + +Reference Guides | +
The OpenSceneGraph is composed of core scene graph libraries, plugins libraries and demo programs. The core scene -graph libraries (osg, osgDB, osgUtil) are only dependant upon OpenGL and Standard C++ so should compile straight out of -the box on most systems. To run the demos one will also need to compile osgGLUT which adds the dependancy of GLUT, and -if true type text is required then the freetype library will be required. The plugins which are used to read and write -various file formats have their own sets of dependancies listed below, some have no dependancies at all. A plugin -is only needed if you need to load that specific file format, so it is not critical if you don't have all the reqiured -dependencies. -
- +The OpenSceneGraph is composed of core scene graph libraries, plugins libraries +and demo programs. The core scene graph libraries (osg, osgDB, osgUtil) +are only dependent upon OpenGL and Standard C++ so should compile straight +out of the box on most systems. To run the demos one will also need to +compile osgGLUT which adds the dependency of GLUT, and if true type text +is required then the freetype library will be required. The plugins which +are used to read and write various file formats have their own sets of +dependencies listed below, some have no dependencies at all. A plugin is +only needed if you need to load that specific file format, so it is not +critical if you don't have all the required dependencies. +To make life easier for Windows users, we have put together a .zip archives with all the required dependancies -which can be download and installed somewhere in you system. You'll need to set VisualStudio to pick up on the -include and libs, and the PATH set to pick up in the dll's. Alternatively, a more hacky but simpler solution is -to unpack this archive inside you OpenSceneGraph distribution, so that all the include files drop into -OpenSceneGraph/include, and the libs drop into OpenSceneGraph/lib, and all the dll's drop into OpenSceneGraph/bin, -this way VisualStudio will pick up the files simpler through the paths set up inside the workspace and project -files. The archives can be downloaded here: . . +To make life easier for Windows users, we have put together a .zip archives +with all the required dependencies which can be download and installed +somewhere in you system. You'll need to set VisualStudio to pick up on +the include and libs, and the PATH set to pick up in the dll's. Alternatively, +a more hacky but simpler solution is to unpack this archive inside you +OpenSceneGraph distribution, so that all the include files drop into OpenSceneGraph/include, +and the libs drop into OpenSceneGraph/lib, and all the dll's drop into +OpenSceneGraph/bin, this way VisualStudio will pick up the files simpler +through the paths set up inside the workspace and project files. The archives +can be downloaded here: . .
-Follows is the list of depedencies which some of the osgPlugins require, +Follows is the list of dependencies which some of the osgPlugins require, note the core osg and viewer do not need the following dependencies, you -only need the following if you require each specific plugin. Note, -the flt, 3ds, pic, tga, do not have any dependencies other than Standard -C++ so will compile straight of the bag. Under Linux the majority -of the depedancies below come as standard with distributions so you may not need to download them at all. -Its best to try out a straight compile of the osg, if you get missing includes/libs -errors then chase up the below. -
- +only need the following if you require each specific plugin. Note, the +flt, 3ds, pic, tga, do not have any dependencies other than Standard C++ +so will compile straight of the bag. Under Linux the majority of the dependencies +below come as standard with distributions so you may not need to download +them at all. Its best to try out a straight compile of the osg, if you +get missing includes/libs errors then chase up the below.Index | -Introduction | -Contents | -Install | -Dependencies | -Demos | -Data | -Viewer | -Stereo | -Plan | -Reference Guides | -
Index | + +Introduction | + +Contents | + +Install | + +Dependencies | + +Demos | + +Data | + +Viewer | + +Stereo | + +Plan | + +Reference Guides | +
Introduction | -Introduction to Scene Graph in general, the OpenSceneGraph project itself and how to use it. | - +|
Introduction | -||
Contents | -A list of the directories in the distribution. | - +Introduction to Scene Graph in general, the OpenSceneGraph project +itself and how to use it. | +
Install | -A guide of how to compile and install on all the supported platforms. | - +|
Contents | -||
Dependencies | -Listing of all the dependancies of the project, with links of where to download them. | - +A list of the directories in the distribution. | +
Demos | -Thumbnails and info on all the demo applications which come with this distribution. | - +|
Install | -||
Data | -List of websites where one can download interesting and useful data from. | - +A guide of how to compile and install on all the supported platforms. | +
Viewer | -List of key bindings support by the osgGLUT::Viewer and hence sgv and the rest of demos. | - +|
Dependencies | -||
Stereo | -Documentation on the commandline paramters and environmential variables which control stereo. | - +Listing of all the dependencies of the project, with links of where +to download them. | +
Plan | -Details of development plans. | - +|
Demos | -||
Reference Guides | -Reference guides of the core libraries. | - +Thumbnails and info on all the demo applications which come with this +distribution. | +
Data | + +List of websites where one can download interesting and useful data +from. | +|
Viewer | + +List of key bindings support by the osgGLUT::Viewer and hence sgv and +the rest of demos. | +|
Stereo | + +Documentation on the commandline parameters and environmental variables +which control stereo. | +|
Plan | + +Details of development plans. | +|
Reference Guides | + +Reference guides of the core libraries. | +
Index | -Introduction | -Contents | -Install | -Dependencies | -Demos | -Data | -Viewer | -Stereo | -Plan | -Reference Guides | -
Index | + +Introduction | + +Contents | + +Install | + +Dependencies | + +Demos | + +Data | + +Viewer | + +Stereo | + +Plan | + +Reference Guides | +
-The scene graph depends upon Standard C++, STL and OpenGL so you need -a C++ compiler up to the task and OpenGL or Mesa installed. The viewer -depends upon GLUT which you'll need to download and install from the GLUT -website. The OSG has it own native ascii file format, and .rgb image reader -inbuilt which allows you read the example data with any dependencies other -than C++, STL and OpenGL. -
- --The osgText library adds the dependency of the freetype library -for support of true type fonts, however it is not essential to the core -library, so you can comment it out from compilation by modifying the src/Makefile, +
The osgText library adds the dependency of the freetype library for +support of true type fonts, however it is not essential to the core library, +so you can comment it out from compilation by modifying the src/Makefile, and src/Demos/Makefile. I you wish to use fonts then you can download freetype from www.freetype.org. The osgText library also requires an up to date GLU implementation which supports GLU1.2 tessellation routines. If you your current GLU is out of date you'll need to download the latest, for instance the sgi's sample implementation for GLU from the www.opengl.org website. -
- --The OSG also has a set of plug-ins which support non-native 3d database +
The OSG also has a set of plug-ins which support non-native 3d database and image formats, several have no dependencies on external libraries (flt,3ds,obj, lwo,dw, tga & pic), while others (pfb,jpeg,gif,tiff) require other libraries to be installed to compile them. If you don't already have them @@ -60,146 +61,143 @@ only and if they are required to load a specific data set. If you don't need them for your datasets then it won't matter that you haven't been able to compile all the plug-ins. A full list of dependencies and where to download the required libraries are listed in the - -dependencies.html -
- --If you're coming across the OSG for the first time and want to get started +dependencies.html +
If you're coming across the OSG for the first time and want to get started quickly, go right ahead and follow the compilation instructions. You can always later download the libraries which the plug-ins require if you eventually need them. -
--Building the OSG requires 'gmake', due to the extensive use of gmake directives -in the Makefiles. You can get gmake from here if you don't already have -it installed: http://www.gnu.org/software/make/ -
- --Almost all of the unix compling is done simply with make; make install with make help to bring up help. -For platform specific details: -
+
Building the OSG requires 'gmake', due to the extensive use of gmake
+directives in the Makefiles. You can get gmake from here if you don't already
+have it installed: http://www.gnu.org/software/make/
+
Almost all of the unix compiling is done simply with make; make install +with make help to bring up help. For platform specific details:
The Microsoft Visual C++ 6.0 workspace file is VisualStudio.dsw located +Compiling under +Windows with Visual Studio. +The Microsoft Visual C++ 6.0 workspace file is VisualStudio.dsw located in the VisualStudio below the OSG this root directory. The OSG will compile -with the basic VisualC++6.0, but, and this is a big but, the STL version which -comes with VisualC++6.0 is extremely buggy and unable to handle things even -as simple as std::mamp without crashing, even the latest severice packs (which are -recommended won't fix the STL bugs). This is a problem for the OpenSceneGraph -since it makes proper use of Standard C++. One can struggle on with the MS's -and expect crashes and optimization disabled, or adopt one of the follwing: - +with the basic VisualC++6.0, but, and this is a big but, the STL version +which comes with VisualC++6.0 is extremely buggy and unable to handle things +even as simple as std::mamp without crashing, even the latest service packs +(which are recommended won't fix the STL bugs). This is a problem for the +OpenSceneGraph since it makes proper use of Standard C++. One can struggle +on with the MS's and expect crashes and optimization disabled, or adopt +one of the following:
The OSG is composed of a number of scene graph libraries (with Core in front of the project names), -executables (with Demos in front of the project names), and plugins which read and write 3D data formats -and 2D image formats. To get the OSG running you'll need at least to compile Core osg,osgUtil,osgDB,osgGLUT, -osgPlugin dot_osg and Demo sgv. The rest of the libraries and executables are optional and can -be compiled if you need them, however for simplicity I would recommend -doing a batch build of all the libraries and executables in the distribution, -some of the plug-ins which support non native file formats may not compile -due to dependencies on other libraries (such as libpng), you can ignore -these compilation errors unless you need to load the related file types. To help -the compilationon the plugins, osgGLUT and osgText one can download .zip -archive will all the dependancies in it. Further details on this .zip file can -be found in dependencies.html - -
+The OSG is composed of a number of scene graph libraries (with Core in +front of the project names), executables (with Demos in front of the project +names), and plugins which read and write 3D data formats and 2D image formats. +To get the OSG running you'll need at least to compile Core osg,osgUtil,osgDB,osgGLUT, +osgPlugin dot_osg and Demo sgv. The rest of the libraries and executables +are optional and can be compiled if you need them, however for simplicity +I would recommend doing a batch build of all the libraries and executables +in the distribution, some of the plug-ins which support non native file +formats may not compile due to dependencies on other libraries (such as +libpng), you can ignore these compilation errors unless you need to load +the related file types. To help the compilation the plugins, osgGLUT and +osgText one can download .zip archive will all the dependencies in it. +Further details on this .zip file can be found in dependencies.htmlTo execute the viewer the file path for the .dll's and .exe, both compiled into the OSG's bin directory, need to be setup, such as by adding the PATH to your autoexec.bat, its also useful to add the OSGFILEPATH to your autoexec.bat to help the location of datafiles. For example : -
-SET OSGFILEPATH=D:\OpenSceneGraph-Data;D:\OpenSceneGraph-Data\Images
+SET OSGFILEPATH=D:\OpenSceneGraph-Data;D:\OpenSceneGraph-Data\Images
SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;D:\osg-0.8.43\bin;
To help compilation of the image reader plugins, various image libraries -have been zipped up for your convienice, your find these on the OSG release +have been zipped up for your convenience, your find these on the OSG release download directory.
-Looks like Microsoft have eventually got their act together on the compiler front, -the compiler looks Standard C++ compilient with a solid STL implement, so this is -the recommend route.
+Looks like Microsoft have eventually got their act together on the compiler +front, the compiler looks Standard C++ compliant with a solid STL implement, +so this is the recommend route.-The basic jist is that you'll need to download their STL implementation, and follow their -instructions of how toforce VisualStudio to pick up the new STL implementation. More details -at http://www.dinkumware.com/vc_fixes.html. -
--Once it is installed everything should compile fine and not crash, but you won't be running at full -speed since the build #odef's out some important state optimizations since the basic VisualStudio -can't handle it. You can safely remove the #ifdef from src/osgUtil/Otimizer.cpp, Line 44. - -The #ifdef is smart enough to do this automatically when using VIsualStudio .NET and STLport so that -modification by hand won't be required. Unfortunately there doesn't seem to be a special define associated -with the Dinkumware STL for the #ifdef to pick up on. -
-Once it is installed everything should compile fine and not crash, but +you won't be running at full speed since the build #ifdef's out some important +state optimizations since the basic VisualStudio can't handle it. You can +safely remove the #ifdef from src/osgUtil/Otimizer.cpp, Line 44. The #ifdef +is smart enough to do this automatically when using VisualStudio .NET and +STLport so that modification by hand won't be required. Unfortunately there +doesn't seem to be a special define associated with the Dinkumware STL +for the #ifdef to pick up on. +
% makeNote, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
% make install+
% make installor -
% make instlinks+
% make instlinksTo get full details of make options, type: -
% make help+
% make help(highly recommended)
The osgText library now depends upon GLU1.3 functionality, and only
-the recent Mesa version have this as stanadard. Unfortnately not all Linux
-distribtions are upto date even recent ones. If you have problems compiling
+the recent Mesa version have this as standard. Unfortunately not all Linux
+distributions are up to date even recent ones. If you have problems compiling
osgText due to GLU problems then check out the details at the bottom of
this file, under the title RedHat7.1 & GLU1.3 for a quick way of installing
GLU1.3 in the right place.
@@ -226,63 +224,58 @@ a README in the tarball with some info on what the script actually does.
There's nothing wrong with OSG itself; the problem with Redhat 7.2 is that
it doesn't have GLU 1.3 by default, which OSG is now dependent on (for
osgText.) Good luck everyone. - Clay
-
-
-
+
% makeNote, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
% make install+
% make installor -
% make instlinks+
% make instlinksTo get full details of make options, type: -
% make help+
% make help(highly recommended) - -
Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
% makeNote, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
% make install+
% make installor -
% make instlinks+
% make instlinksTo get full details of make options, type: -
% make help+
% make help(highly recommended)
% makeNote, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
% make install+
% make installor -
% make instlinks+
% make instlinksTo get full details of make options, type: -
% make help+
% make help(highly recommended)
You need to have installed the Developer tools from the CD that comes @@ -293,7 +286,7 @@ OS rather than the Aqua gloss. The Mac comes with an app in Applications/Utiliti called Terminal - open up any Finder window (e.g double-click on your hard disk icon), click on the Applications icon at the top right of the window, then click on the Utilities folder to get access to all the grubby apps -which give away the real OS roots underneath the shiny paintwork. Anyone +which give away the real OS roots underneath the shiny paint work. Anyone developing will need Terminal so much they should put it in their Dock. You do that by grabbing the icon of the app in the Utilities folder and dragging it to the bottom of your screen, at which point the other app @@ -309,7 +302,7 @@ folder of the harddisk the machine booted from). filename that the Mac won't let you see from the Finder or in fact generate from an app, so I used vi to create that. Then I just went
cd $OSGHOME -
% make clean +% make clean
% make macosx
And it sounds too good to be true but it is that simple. It's worth @@ -323,11 +316,9 @@ built osg rgb 3ds and a couple others - will check and get back to you. account on the machine, which by default is switched off as the machines ship for security reasons. Rather than typing in and risking error through paraphrase, here is a link to a site which tells you how to do this - -http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html+http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.htmlOr alternately, -http://www.thinkmacintosh.com/osxfaq.html+http://www.thinkmacintosh.com/osxfaq.html
One you have a root account enabled, you have to su root you cd to the directory which the Fink installer generates, and it puts libdl.a @@ -341,27 +332,24 @@ but at the point it tries to use GLUT to open a window it falls over with a CGS error (which is I think Core Graphics System). If you explicitly go bin/hangglide it works fine. Weird, it may be an OS X 10.04 issue which is gone in 10.1 or it may be a weirdy in the Mac GLUT implementation, but -forewarned is forearmed. - +forewarned is forearmed.
- -Compiling under Cygwin
++Compiling under Cygwin
To compile, from the OSG root directory, type: make Note, make should automatically detect your system and build optimized targets for your system. And if you wish to install the OSG type: make install Note that make symbolic links don't seem to work under cygwin, so a make instlinks will simply copy files just like make install. 'make install' places all files in /usr/local/OpenSceneGraph -under appropriate subdirectories. To get full details of make options, +under appropriate sub directories. To get full details of make options, type: make help (highly recommended) -OSGFILEPATH environmental variable -
For the OSG to locate file data files easily an environmetal variable -OSGFILEPATH is used at run-time by the osgDB library. Note, for examples +
OSG_FILE_PATH environmental variable +
For the OSG to locate file data files easily an environmental variable +OSG_FILE_PATH is used at run-time by the osgDB library. Note, for examples below substitute in the ${OSGDATA} directory with your own path where appropriate) -Add the following to your .cshrc (note paths seperated by colon's): setenv -OSGFILEPATH ./:${OSGDATA}:${OSGDATA}/Images Or the following if you're -using a sh compatible shell : export OSGFILEPATH=./:${OSGDATA}:${OSGDATA}/Images: -Or under windows (note paths seperated by semi-colon's) : SET OSGFILEPATH=./:${OSGDATA};${OSGDATA}/Images - - +Add the following to your .cshrc (note paths separated by colon's): setenv +OSG_FILE_PATH ./:${OSGDATA}:${OSGDATA}/Images Or the following if you're +using a sh compatible shell : export OSG_FILE_PATH=./:${OSGDATA}:${OSGDATA}/Images: +Or under windows (note paths seperated by semi-colon's) : SET OSG_FILE_PATH=./:${OSGDATA};${OSGDATA}/Images diff --git a/doc/introduction.html b/doc/introduction.html index 00e98443a..9feea0904 100644 --- a/doc/introduction.html +++ b/doc/introduction.html @@ -7,21 +7,30 @@
--
- +Index -Introduction -Contents -Install -Dependencies -Demos -Data -Viewer -Stereo -Plan -Reference Guides -+ Index + +Introduction + +Contents + +Install + +Dependencies + +Demos + +Data + +Viewer + +Stereo + +Plan + +Reference Guides +@@ -62,9 +71,7 @@ scientific and commercial visualization, training through to modeling programs.
Why use a Scene Graph - Performance, Productivity, Portability and Scalability.
--
+underlying hardware configurations.- -
-Performance - scene graphs provide an excellent framework for +
Performance - scene graphs provide an excellent framework for maximize 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 @@ -76,12 +83,10 @@ 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. -
- -
-Productivity - scene graphs take much of the hard work required +
Productivity - scene graphs take much of the hard work required to develop high performance graphics applications. The scene graphs manage all the graphics for you, reducing what would be thousands of lines of -OpenGL down to a few simple calls. Furthermoe, one of most powerful concepts +OpenGL down to a few simple calls. Furthermore, one of most powerful concepts in Object Orientated programming is that of object composition, enshrined in Composite Design Pattern, which fits the scene graph tree structure perfectly which makes it highly flexible and reusable design - in real @@ -91,25 +96,19 @@ helping users set up and manage graphics windows to import of 3d modes 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! -
- -
-Portability - scene graphs encapsulate much of the lower level +
Portability - scene graphs encapsulate much of the lower level 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. -
- -
-Scalability - along with being able to dynamic manage the complexity +
Scalability - 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 complex hardware configurations, such as clusters of graphics machines, or multiprocessor/multipipe systems such as SGI's Onyx. A good scene graph will allow the developer to concentrate on developing their own application while the rendering framework of the scene graph handles the different -underlying hardware configurations. -
@@ -124,9 +123,7 @@ 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: -
-
+- -
-Performance - supports view frustum culling, small feature culling, +
Performance - 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 @@ -137,9 +134,7 @@ 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 with the OpenSceneGraph. -
- -
-Productivity - by combining lessons learned from established +
Productivity - 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 @@ -148,13 +143,10 @@ to the OpenSceneGraph and to integrate 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. -
- -
-Portability - The core scene graph has also been designed to +
Portability - 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 +ported on 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. @@ -162,22 +154,18 @@ 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 with Motif, and X. -
- -
-Scalability - the scene graph not only runs from 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 traversals -have been designed to cache rendering data locally and use the scene gaph -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 -like the Onyx and graphics clusters -
Scalability - the scene graph not only runs from 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 +traversals have been designed to cache rendering data locally and use the +scene gaph 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 +like the Onyx and graphics clusters All the source to is published under the GNU Library 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. @@ -219,13 +207,15 @@ for using the developers using the OpenSceneGraph.
The source distribution contains the 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.
If you are using a source distribution then read the installation 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 -dependencies +OpenSceneGraph is dependent upon such as glut, check the dependencies list for further details. +
For full instructions of how to run the demos read the demos +page.
diff --git a/doc/plan.html b/doc/plan.html index aa88e8a79..6c107f3ed 100644 --- a/doc/plan.html +++ b/doc/plan.html @@ -2,111 +2,126 @@ - +
Plans for future developments --
+- +Index -Introduction -Contents -Install -Dependencies -Demos -Data -Viewer -Stereo -Plan -Reference Guides -+ Index + +Introduction + +Contents + +Install + +Dependencies + +Demos + +Data + +Viewer + +Stereo + +Plan + +Reference Guides ++Plans for future developments
+The plan for the next release after 0.8.45 is to from alpha (all 0.8 series +version) to beta for the next release, at this point will bump the version +number up to 0.9.0 and all subsequent 0.9 releases will be beta, up till +the release of 1.0. The current goal is to move to beta in early summer, +with 1.0 in late summer, with SIGGRAPH being a possibility. ++Features planed for the next release (0.9.0) include:
-Plans for future developments
- --The plan for the next release after 0.8.45 is to from alpha (all 0.8 series version) to beta for the next release, -at this point will bump the version number up to 0.9.0 and all subsequent 0.9 releases will be beta, uptill the -release of 1.0. The current goal is to move to beta in early summer, with 1.0 in late summer, with SIGGRAPH -being a possibility. -
- -Features planed for the next release (0.9.0) include:
-
-- New osg::Geometry drawable to deprecate osg::GeoSet, the new Geometry class -will support multiple text coords, use std::vector<> for easy management of -attributes.and support gl extensions to provide greater polygon performance. -
+will support multiple text coords, use std::vector<> for easy management +of attributes and support gl extensions to provide greater polygon performance. +- -Multi-texturing support in osg::Texture. osg::TexMat, osg::TexGen. -
+Multi-texturing support in osg::Texture. osg::TexMat, osg::TexGen. +- -Multi-pass fallback for when multi-texturing is not supported. -
+Multi-pass fallback for when multi-texturing is not supported. +- -Clean up the API for managing multi-stage and multi-pass rendering within the scene graph. -
+Clean up the API for managing multi-stage and multi-pass rendering within +the scene graph. +- Replace osgGLUT with a cleaner windowing API for the demos, move osgGLUT -out of the distribution and into the bazaar. -
+out of the distribution and into the bazaar. +- -Introduce a new library osgGA, which acts as GUI abstraction layer, move the -current osgUtil camera manipulators into osgGA.
+Introduce a new library osgGA, which acts as GUI abstraction layer, move +the current osgUtil camera manipulators into osgGA. +- -Introduce a new library osgEnv/osgShapes, which adds support for creating shapes and -environmental effects such as stars, planats, cloud layers and ground planes. -
+Introduce a new library osgEnv/osgShapes, which adds support for creating +shapes and environmental effects such as stars, planets, cloud layers and +ground planes. +- -Integrate unit tests for all classes, and develop a test suite. -
+Integrate unit tests for all classes, and develop a test suite.Books, tutorials and demostrations
++Books, tutorials and demonstrations
+-
- Don Burns and Robert Osfield to write the OpenSceneGraph book!
+- -Development of tutorials to published as part of the distribution and on the bazaar
+Development of tutorials to published as part of the distribution and on +the bazaar +- -Development of technoglogy demonstrations for shows, presentations and training.
+Development of technology demonstrations for shows, presentations and training.Development of commerical add on libraries:
++Development of commercial add on libraries:
++
-- +osgMP - cross platform library for transparently managing mulitpipe and +cluster graphics systems. Similar in concept to OpenGL multipipe SDK, except +cross platform and with support of graphics clusters.
- -osgMP - cross platfrom library for transparently managing mulitpipe and -cluster graphics systems. Similar in concept to OpenGL multipipe SDK, except cross -platform and with support of graphics clusters. -
-- -osgLP - cross platform libary for support for light points.
+osgLP - cross platform library for support for light points.Professional services
++Professional services
++
- -For further details on osgMP, osgLP, OSGPL licensing, professional support, training and consultancy -services contact Robert Osfield at robert@openscenegraph.com or -Don Burns at don@andesengineering.com. - +For further details on osgMP, osgLP, OSGPL licensing, professional support, +training and consultancy services contact Robert Osfield at robert@openscenegraph.com +or Don Burns at don@andesengineering.com. diff --git a/doc/stereo.html b/doc/stereo.html index 79ea445ea..752abfc83 100644 --- a/doc/stereo.html +++ b/doc/stereo.html @@ -2,228 +2,305 @@ - +- +Set up a support contract and support systems for confidential, email, +phone and onsite support.
- -Set up a support contract and support systems for confidential, -email, phone and onsite support.
-- -Set up the Open Scene Graph Professional License (OSGPL) which is -conventional propriatary license.that allows companies to distribute -projects that do not comply wiht the terms of the LGPL, such as turn -key systems.
+Set up the Open Scene Graph Professional License (OSGPL) which is conventional +proprietary license that allows companies to distribute projects that do +not comply with the terms of the LGPL, such as turn key systems. +- Develop training courses.
Native stereo support - --
-- +Index -Introduction -Contents -Install -Dependencies -Demos -Data -Viewer -Stereo -Plan -Reference Guides -+ Index + +Introduction + +Contents + +Install + +Dependencies + +Demos + +Data + +Viewer + +Stereo + +Plan + +Reference Guides +Native Support for Stereo
- -The OSG has support for anaglyphic stereo -(i.e. red/green or red/cyan glasses), quad buffered stereo (i.e. active stereo using shutter glasses, -or passive stereo using polarized projectors & glasses) and horizontal and vertical split window stereo implementations. -Almost all OSG applications have the potential for stereo support simply by setting the relevant environmental variables, or via command line arguments. Little or no code changes will be required, the support is -handled transparently inside osgUtil::SceneView's handling of rendering.It is a simple as: -
- sgv -stereo cow.osg - -If the user is planning to use head tracked stereo, or a cave then it is currently recommend to set it -up via a VR toolkit such as VRjuggler, in this case refer to the VR toolkits handling of stereo, and keep -all the OSG's stereo specific environment variables (below) set to OFF, or set the values to off within own -your own applications. -
++Native Support for Stereo
+The OSG has support for anaglyphic stereo (i.e. red/green or red/cyan glasses), +quad buffered stereo (i.e. active stereo using shutter glasses, or passive +stereo using polarized projectors & glasses) and horizontal and vertical +split window stereo implementations. Almost all OSG applications have the +potential for stereo support simply by setting the relevant environmental +variables, or via command line arguments. Little or no code changes will +be required, the support is handled transparently inside osgUtil::SceneView's +handling of rendering. It is a simple as: +
sgv -stereo cow.osg +If the user is planning to use head tracked stereo, or a cave then it +is currently recommend to set it up via a VR toolkit such as VRjuggler, +in this case refer to the VR toolkits handling of stereo, and keep all +the OSG's stereo specific environment variables (below) set to OFF, or +set the values to off within own your own applications. +
-The environmental variables of interest:
++The environmental variables of interest:
-
+- -OSG_STEREO -ON -Turn stereo on -- -- OFF -Turn stereo off (default). -- -OSG_STEREO_MODE -ANAGLYPHIC -Use anaglyphic stereo when in stereo (default). -- -- QUAD_BUFFER -Use quad buffered stereo when in stereo. -- -- HORIZONTAL_SPLIT -Use horizontal split stereo mode when in stereo -- -- VERTICAL_SPLIT -Use vertical split stereo mode when in stereo -- -OSG_SCREEN_DISTANCE -0.50 -Set the distance the viewer is from screen in metres (default shown) -- -OSG_SCREEN_HEIGHT -0.26 -Set the height if image on the screen in metres (default shown) -- -OSG_EYE_SEPERATION -0.06 -Set the eye seperation - interoccular distance (default shown.) -- -OSG_SPLIT_STEREO_HORIZONTAL_SEPERATION -42 -Set the number of pixels betweent the left and right viewports (default shown). -- -OSG_SPLIT_STEREO_HORIZONTAL_EYE_MAPPING -LEFT_EYE_LEFT_VIEWPORT -Set the left eye to render to left viewport, right eye to right viewport (default). -- -- LEFT_EYE_RIGHT_VIEWPORT -Set the left eye to render to right viewport, right eye to left viewport. -- -OSG_SPLIT_STEREO_VERTICAL_SEPERATION -42 -Set the number of pixels betweent the top and bottom viewports (default shown). -- -OSG_SPLIT_STEREO_VERTICAL_EYE_MAPPING -LEFT_EYE_TOP_VIEWPORT -Set the left eye to render to top viewport, right eye to bottom viewport (default). -- -- LEFT_EYE_BOTTOM_VIEWPORT -Set the left eye to render to bottom viewport, right eye to top viewport. -+ -OSG_STEREO -
+ON -Command line arguments can be used to override these settings:
+Turn stereo on +-
- --stereo -- Switch on stereo. -- --stereo -ON -Switch on stereo. -- -- OFF -Switch off stereo. -- -- ANAGLYPHIC -Switch on ANAGLYPHIC stereo. -- -- QUAD_BUFFER -Switch on QUAD_BUFFER stereo. -- -- VERTICAL_SPLIT -Switch on VERTICAL_SPLIT stereo. -- +- HORIZONTAL_SPLIT -Switch on VERTICAL_SPLIT stereo. -+ + ++ + OFF + +Turn stereo off (default). ++ + +OSG_STEREO_MODE + +ANAGLYPHIC + +Use anaglyphic stereo when in stereo (default). ++ + ++ + QUAD_BUFFER + +Use quad buffered stereo when in stereo. ++ + ++ + HORIZONTAL_SPLIT + +Use horizontal split stereo mode when in stereo ++ + ++ + VERTICAL_SPLIT + +Use vertical split stereo mode when in stereo ++ + +OSG_SCREEN_DISTANCE + +0.50 + +Set the distance the viewer is from screen in metres (default shown) ++ + +OSG_SCREEN_HEIGHT + +0.26 + +Set the height if image on the screen in metres (default shown) ++ + +OSG_EYE_SEPERATION + +0.06 + +Set the eye separation - interoccular distance (default shown.) ++ + +OSG_SPLIT_STEREO_HORIZONTAL_SEPERATION + +42 + +Set the number of pixels between the left and right viewports (default +shown). ++ + +OSG_SPLIT_STEREO_HORIZONTAL_EYE_MAPPING + +LEFT_EYE_LEFT_VIEWPORT + +Set the left eye to render to left viewport, right eye to right viewport +(default). ++ + ++ + LEFT_EYE_RIGHT_VIEWPORT + +Set the left eye to render to right viewport, right eye to left viewport. ++ + +OSG_SPLIT_STEREO_VERTICAL_SEPERATION + +42 + +Set the number of pixels between the top and bottom viewports (default +shown). ++ + +OSG_SPLIT_STEREO_VERTICAL_EYE_MAPPING + +LEFT_EYE_TOP_VIEWPORT + +Set the left eye to render to top viewport, right eye to bottom viewport +(default). ++ + + LEFT_EYE_BOTTOM_VIEWPORT + +Set the left eye to render to bottom viewport, right eye to top viewport. +
++Command line arguments can be used to override these settings:
-Examples:
- To invoke stereo from the comandline:
- sgv -stereo cow.osg -To invoke quad buffered stereo from the commandline:
+
- sgv -stereo QUAD_BUFFER cow.osg+
+ ++ + +-stereo + ++ + Switch on stereo. ++ + +-stereo + +ON + +Switch on stereo. ++ + ++ + OFF + +Switch off stereo. ++ + ++ + ANAGLYPHIC + +Switch on ANAGLYPHIC stereo. ++ + ++ + QUAD_BUFFER + +Switch on QUAD_BUFFER stereo. ++ + ++ + VERTICAL_SPLIT + +Switch on VERTICAL_SPLIT stereo. ++ ++ + HORIZONTAL_SPLIT + +Switch on VERTICAL_SPLIT stereo. +
++Examples:
+To invoke stereo from the comandline: +
sgv -stereo cow.osg +To invoke quad buffered stereo from the commandline: +
sgv -stereo QUAD_BUFFER cow.osgTo force all apps to start up in quad buffered stereo (if system supports - it)
-
- export OSG_STEREO=ON
- export OSG_STEREO_MODE=QUAD_BUFFER
- sgv cow.osgTo set quad buffered stereo to the default, but use the commandline to - switch stereo on:
- +it) +
- export OSG_STEREO=OFF
- export OSG_STEREO_MODE=QUAD_BUFFER
- sgv -stereo cow.osg
-
export OSG_STEREO=ON +
export OSG_STEREO_MODE=QUAD_BUFFER +
sgv cow.osg +To set quad buffered stereo to the default, but use the commandline +to switch stereo on: +
export OSG_STEREO=OFF +
export OSG_STEREO_MODE=QUAD_BUFFER +
sgv -stereo cow.osg +
- -Size matters:
-For appropriate depth perception the stereo code creates separate left +
+Size matters:
+For appropriate depth perception the stereo code creates separate left and eye views, both the frustum and modelview are shifted to account for -the separate eye views. To achieve the right amount of adjustment the -OSG requires the users eye separation, the distance from the eyes to the screen -and the height of the screen. The OSG will use the defaults of 0.05m,0.5m -and 0.26m respectively which are assumed to be reasonable defaults for most -users workstation configurations, note the OSG_SCREEN_HEIGHT is the image -height rather than total size of your monitor/display surface. For -the best stereo effects please measure these values and set them up via the -environmental variables. Once set the views you get should give improved -depth perception. A good way of measuring how well you are configured -for your display is to fly away from objects (using the FlightManipulator -for instance, but not the TrackballManipulator, see below) so that they -go of toward infinity. As they move away the offset between the two images -should tend towards your eye separation, if you achieve this then the object -will be perceived as at infinity. - +the separate eye views. To achieve the right amount of adjustment +the OSG requires the users eye separation, the distance from the eyes to +the screen and the height of the screen. The OSG will use the defaults +of 0.05m,0.5m and 0.26m respectively which are assumed to be reasonable +defaults for most users workstation configurations, note the OSG_SCREEN_HEIGHT +is the image height rather than total size of your monitor/display surface. +For the best stereo effects please measure these values and set them up +via the environmental variables. Once set the views you get should +give improved depth perception. A good way of measuring how well +you are configured for your display is to fly away from objects (using +the FlightManipulator for instance, but not the TrackballManipulator, see +below) so that they go of toward infinity. As they move away the offset +between the two images should tend towards your eye separation, if you +achieve this then the object will be perceived as at infinity. +
- -Camera Manipulator Modes:
-There are three osgUtil::CameraManipulator's which come with osgUtil, -which operate as a Trackball, Drive and Flight modes of interaction (see -sgv.html for how to invoke them in the scene graph viewer). The osgUtil::Trackball +
+Camera Manipulator Modes:
+There are three osgUtil::CameraManipulator's which come with osgUtil, which +operate as a Trackball, Drive and Flight modes of interaction (see sgv.html +for how to invoke them in the scene graph viewer). The osgUtil::Trackball Manipulator automatically scales the fusion distance to that which will -fusion on center point of rotation - this will appear at the middle of the -monitor at the monitors depth. Whereas, the osgUtil::DriveManipualtor, osgUtil::FlightManipulator -scale the fusion distance to the distance the viewer is from the screen, -the results in a perception that the virtual world is scaled to physical -world, this is clearly better for simulators and alike. You can control -the fusion of the image in these two modes via the osg::Camera::setFusionDistanceMode(FusionDistanceMode -mode) where mode can be osg::Camera::PROPORTIONAL_TO_LOOK_DISTANCE (used -by Trackball) or osg::Camera::PROPORTIONAL_TO_SCREEN_DISTANCE (used by -Drive and Flight), and osg::Camera::setFusionDistanceRatio(float). See -include/osg/Camera for further details, and the camera manipulators for -implementation details. The fusion distance ratio defaults to 1.0 but -can be biased to move objects out or into screen, they will also appear -to get smaller and larger respectively. The camera manipulators allow -the user to alter this value at runtime via the '+' and '-' keys. - - +fusion on center point of rotation - this will appear at the middle of +the monitor at the monitors depth. Whereas, the osgUtil::DriveManipualtor, +osgUtil::FlightManipulator scale the fusion distance to the distance the +viewer is from the screen, the results in a perception that the virtual +world is scaled to physical world, this is clearly better for simulators +and alike. You can control the fusion of the image in these two modes via +the osg::Camera::setFusionDistanceMode(FusionDistanceMode mode) where mode +can be osg::Camera::PROPORTIONAL_TO_LOOK_DISTANCE (used by Trackball) or +osg::Camera::PROPORTIONAL_TO_SCREEN_DISTANCE (used by Drive and Flight), +and osg::Camera::setFusionDistanceRatio(float). See include/osg/Camera +for further details, and the camera manipulators for implementation details. +The fusion distance ratio defaults to 1.0 but can be biased to move objects +out or into screen, they will also appear to get smaller and larger respectively. +The camera manipulators allow the user to alter this value at runtime via +the '+' and '-' keys. diff --git a/index.html b/index.html index fa9b94444..fcd10ff77 100644 --- a/index.html +++ b/index.html @@ -1,84 +1,107 @@ - + - +Documentionn Index - --
- +Index -Introduction -Contents -Install -Dependencies -Demos -Data -Viewer -Stereo -Plan -Reference Guides -+ Index + +Introduction + +Contents + +Install + +Dependencies + +Demos + +Data + +Viewer + +Stereo + +Plan + +Reference Guides +-Index
+Index-
- Introduction -Introduction to Scene Graph in general, the OpenSceneGraph project itself and how to use it. - ++ Introduction -- -Contents -A list of the directories in the distribution. - +Introduction to Scene Graph in general, the OpenSceneGraph project +itself and how to use it. +- Install -A guide of how to compile and install on all the supported platforms. - ++ Contents -- -Dependencies -Listing of all the dependancies of the project, with links of where to download them. - +A list of the directories in the distribution. +- Demos -Thumbnails and info on all the demo applications which come with this distribution. - ++ Install -- -Data -List of websites where one can download interesting and useful data from. - +A guide of how to compile and install on all the supported platforms. +- Viewer -List of key bindings support by the osgGLUT::Viewer and hence sgv and the rest of demos. - ++ Dependencies -- -Stereo -Documentation on the commandline paramters and environmential variables which control stereo. - +Listing of all the dependencies of the project, with links of where +to download them. +- Plan -Details of development plans. - ++ Demos -- +Reference Guides -Reference guides of the core libraries. - +Thumbnails and info on all the demo applications which come with this +distribution. ++ + +Data + +List of websites where one can download interesting and useful data +from. ++ + +Viewer + +List of key bindings support by the osgGLUT::Viewer and hence sgv and +the rest of demos. ++ + +Stereo + +Documentation on the commandline parameters and environmental variables +which control stereo. ++ + +Plan + +Details of development plans. ++ Reference Guides + +Reference guides of the core libraries. +