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 @@ - + Demos - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
Index Introduction Contents Install Dependencies Demos Data Viewer Stereo Plan Reference Guides
IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference Guides

Running the demos

-

-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. -

-
  • Windows:
  • - +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. +
  • +Windows:
  • -

    -
  • Unix
  • - +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.osgThe 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.osgThe 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.
    hangglideThe 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.rgbDemonstrates how to create the various types of billboard supported by the OpenSceneGraph. Billboards - are typically used for trees or particles effects. -
    osgcubeSimplest of all demos, create a cube geometry and spin it! -
    osghud glider.osgVery 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.osgOpenSceneGraph 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.osgAn 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.osgAn 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.rgbAn 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! - .
    osgtextAn example showing how to creating the various different typs of text that the osgText library supports. -
    osgtexture lz.rgb reflect.rgbAn example showing how to creating the textured quads, each with different texture parameters, including - anistrophic filtering and texture compression! -
    osgviews.cow.osgAn example of multiple viewports all running at once. -
    sgv cow.osgThe 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.osgThe 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.
    hangglideThe 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.rgbDemonstrates how to create the various types of billboard supported +by the OpenSceneGraph. Billboards are typically used for trees or particles +effects. 
    osgcubeSimplest of all demos, create a cube geometry and spin it! 
    osghud glider.osgVery 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.osgOpenSceneGraph 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.osgAn 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.osgAn 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.rgbAn 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! .
    osgtextAn example showing how to creating the various different typs of text +that the osgText library supports. 
    osgtexture lz.rgb reflect.rgbAn example showing how to creating the textured quads, each with different +texture parameters, including anisotrophic filtering and texture compression! 
    osgviews.cow.osgAn example of multiple viewports all running at once. 
    diff --git a/doc/dependencies.html b/doc/dependencies.html index e159d70fd..17fdb434b 100644 --- a/doc/dependencies.html +++ b/doc/dependencies.html @@ -2,157 +2,171 @@ - + Compilation dependencies - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
    Index Introduction Contents Install Dependencies Demos Data Viewer Stereo Plan Reference Guides
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference Guides

    Scene graph 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 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. +

    -

    Windows dependency archives

    -

    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: . .


    -

    Core library dependencies

    - +

    Plug-in dependencies

    -

    -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. -
  • src/osgPlugins/gif
  • +
  • +src/osgPlugins/gif

  • The gif plugin depends upon the libungif library, if you don't already have it installed, you'll need to download, compile and install it. Project home page is: - + Ftp download at : - + -
  • src/osgPlugins/jpeg
  • +
  • +src/osgPlugins/jpeg

  • The jpeg plugin depends upon the libjpeg library, if you don't already have it installed, you'll need to download, compile and install it. Project home page is: - + -
  • src/osgPlugins/tiff
  • +
  • +src/osgPlugins/tiff

  • The tiff plugin depends upon the libtiff library, if you don't already have it installed, you'll need to download, compile and install it. Project home page is: - + -
  • src/osgPlugins/zip
  • +
  • +src/osgPlugins/zip

  • The zip compressed archive plugin depends upon the unzip executable -being available on your system. If it is not then you'll be able -to find binaries at: - +being available on your system. If it is not then you'll be able to find +binaries at: + -
  • src/osgPlugins/tgz
  • +
  • +src/osgPlugins/tgz

  • The tgz compressed archive plugin depends upon the unzip executable -being available on your system. If it is not then you'll be able -to find binaries at: +being available on your system. If it is not then you'll be able to find +binaries at: +
    ftp://prep.ai.mit.edu/pub/gnu/tar/ -
  • src/osgPlugins/osgtgz
  • +
  • +src/osgPlugins/osgtgz

  • Has the same dependencies as the tgz plugin above. - diff --git a/doc/index.html b/doc/index.html index 8e208009a..b9ee2a273 100644 --- a/doc/index.html +++ b/doc/index.html @@ -1,84 +1,107 @@ - + - + OSG Documentation - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
    Index Introduction Contents Install Dependencies Demos Data Viewer Stereo Plan Reference Guides
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference 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.
    DataList of websites where one can download interesting and useful data +from.
    ViewerList of key bindings support by the osgGLUT::Viewer and hence sgv and +the rest of demos.
    StereoDocumentation on the commandline parameters and environmental variables +which control stereo.
    PlanDetails of development plans.
    Reference GuidesReference guides of the core libraries.
    diff --git a/doc/install.html b/doc/install.html index 3a2271c89..6cd19f6c1 100644 --- a/doc/install.html +++ b/doc/install.html @@ -2,54 +2,55 @@ - + Installation instructions - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
    Index Introduction Contents Install Dependencies Demos Data Viewer Stereo Plan Reference Guides
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference Guides
    -

    Compiling and installing the OpenSceneGraph

    - - -

    -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, +

    +Compiling and installing the OpenSceneGraph

    +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, 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. -

    - +
    -

    -Compiling under Windows with Visual Studio.

    -

    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:

      -
    1. Visual Studio .NET
    2. -
    3. Dinkumware's STL bug fix patches - http://www.dinkumware.com/vc_fixes.html.
    4. -
    5. STLport - http://www.stlport.org
    6. +
    7. +Visual Studio .NET
    8. + +
    9. +Dinkumware's STL bug fix patches - http://www.dinkumware.com/vc_fixes.html.
    10. + +
    11. +STLport - http://www.stlport.org
    - -

    -

    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.html

    To 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.

    Using Visual Studio .NET

    -

    -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.

    Using Dinkumware STL

    -

    -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. -

    -

    Using STLport

    -

    +The basic jist is that you'll need to download their STL implementation, +and follow their instructions of how to force 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 #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. +

    +Using STLport

    The OSG has been tested under Windows with STLport-4.5, which allows the users to configure the type of STL support required for STLport itself. The key configuration that the OSG needs to do is to enable the wrapping of MS's own iostreams, than using STLport's own implementation. The later is not required because this has not be problematic under Windows, it is only the container classes and algorithms that need replacing (thanks to -MS's utterly hopeless implementation of these). Using the iostream wrappping +MS's utterly hopeless implementation of these). Using the iostream wrapping option means the STLport can just be used on your include path, there is no need to compile STLport itself, or link into any special libraries. To configure STLport simply comment IN (its commented out by default), -the follwing line from STLport-4.5/stlport/stl_user_config.h so it should +the following line from STLport-4.5/stlport/stl_user_config.h so it should look: # define _STLP_NO_OWN_IOSTREAMS 1 Then configure the includes path in Visual Studio to pick up on STLport: Select the "Tools" menu. Select "Options" In the Options dialog, select the "Directories" tab Under the "include" option, add the path to STLport4.5, something like: D:/STLport4.5/stlport Then press the up array to move the entry all the way to the top of the list, thus overriding MS's own STL implementations. -


    - - -

    Compiling under Linux

    +

    +Compiling under Linux

    Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
    % make
    Note, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
    % make install
    +
    % make install
    or -
    % make instlinks
    +
    % make instlinks
    To 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 - -
    -
    +


    - -

    Compiling under FreeBSD

    +

    +Compiling under FreeBSD

    Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
    % make
    Note, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
    % make install
    +
    % make install
    or -
    % make instlinks
    +
    % make instlinks
    To get full details of make options, type: -
    % make help
    +
    % make help
    (highly recommended) - -
    -
    +


    - -

    Compiling under IRIX

    +

    +Compiling under IRIX

    Since the OSG uses Standard C++ features such as STL it is important to have an up to date version of the MIPSPro compilers, ie. 7.3 or later. Support for MIPSPro7.2.1 has now been dropped since it was becoming to -unwildy to support and is very rarely used in the OSG commiunity. It is +unwildy to support and is very rarely used in the OSG community. It is recommended to use MIPSPro7.3.1.1m.

    Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:

    % make
    Note, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
    % make install
    +
    % make install
    or -
    % make instlinks
    +
    % make instlinks
    To get full details of make options, type: -
    % make help
    +
    % make help
    (highly recommended)
    -
    - -

    Compiling under Solaris

    +

    +Compiling under Solaris

    Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
    % make
    Note, make should automatically detect linux and build optimized targets for your system. And if you wish to install the OSG type: -
    % make install
    +
    % make install
    or -
    % make instlinks
    +
    % make instlinks
    To get full details of make options, type: -
    % make help
    +
    % make help
    (highly recommended)
    -
    - -

    Compiling under MacOS X (instructions written by Phil Atkin)

    +

    +Compiling under MacOS X (instructions written +by Phil Atkin)

    For anyone who's ever used a Unix box for development it really is so simple it's insane.

    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.html
    Or 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
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference Guides

    @@ -62,9 +71,7 @@ scientific and commercial visualization, training through to modeling programs.

    Why use a Scene Graph - Performance, Productivity, Portability and Scalability.

    -
      -
    1. -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. -

        -
      1. -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! -

      2. -
      3. -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. -

      4. -
      5. -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. -

      6. -
      +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: -
      -
    1. -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. -

        -
      1. -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. -

      2. -
      3. -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. -

      4. -
      5. -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 -

      6. -
      +

      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
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference 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:

    -

    Books, tutorials and demostrations

    +

    +Books, tutorials and demonstrations

    + -

    Development of commerical add on libraries:

    +

    +Development of commercial add on libraries:

    + -

    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 @@ - + Native stereo support - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
    Index Introduction Contents Install Dependencies Demos Data Viewer Stereo Plan Reference Guides
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference 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_STEREOON Turn stereo on
    OFFTurn stereo off (default).
    OSG_STEREO_MODEANAGLYPHIC 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.
    -stereoON 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.
    OFFTurn stereo off (default). 
    OSG_STEREO_MODEANAGLYPHICUse anaglyphic stereo when in stereo (default). 
    QUAD_BUFFERUse quad buffered stereo when in stereo. 
    HORIZONTAL_SPLITUse horizontal split stereo mode when in stereo 
    VERTICAL_SPLITUse vertical split stereo mode when in stereo 
    OSG_SCREEN_DISTANCE0.50Set the distance the viewer is from screen in metres (default shown) 
    OSG_SCREEN_HEIGHT0.26Set the height if image on the screen in metres (default shown) 
    OSG_EYE_SEPERATION0.06Set the eye separation - interoccular distance (default shown.) 
    OSG_SPLIT_STEREO_HORIZONTAL_SEPERATION42Set the number of pixels between the left and right viewports (default +shown).
    OSG_SPLIT_STEREO_HORIZONTAL_EYE_MAPPINGLEFT_EYE_LEFT_VIEWPORTSet the left eye to render to left viewport, right eye to right viewport +(default). 
    LEFT_EYE_RIGHT_VIEWPORTSet the left eye to render to right viewport, right eye to left viewport. 
    OSG_SPLIT_STEREO_VERTICAL_SEPERATION42Set the number of pixels between the top and bottom viewports (default +shown).
    OSG_SPLIT_STEREO_VERTICAL_EYE_MAPPINGLEFT_EYE_TOP_VIEWPORTSet the left eye to render to top viewport, right eye to bottom viewport +(default). 
    LEFT_EYE_BOTTOM_VIEWPORTSet 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

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    -stereoSwitch on stereo. 
    -stereoONSwitch on stereo. 
    OFFSwitch off stereo. 
    ANAGLYPHICSwitch on ANAGLYPHIC stereo. 
    QUAD_BUFFERSwitch on QUAD_BUFFER stereo. 
    VERTICAL_SPLITSwitch on VERTICAL_SPLIT stereo. 
    HORIZONTAL_SPLITSwitch 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.osg

    To 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.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
    -  

    - +it) +
        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
    IndexIntroductionContentsInstallDependenciesDemosDataViewerStereoPlanReference 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.
    DataList of websites where one can download interesting and useful data +from.
    ViewerList of key bindings support by the osgGLUT::Viewer and hence sgv and +the rest of demos.
    StereoDocumentation on the commandline parameters and environmental variables +which control stereo.
    PlanDetails of development plans.
    Reference GuidesReference guides of the core libraries.