OpenSceneGraph (OSG) FAQs 1 thru 50

FAQs 1 thru 50 square72_blue.gif FAQs 101 thru 150 square72_blue.gif FAQs 101 thru 150 square72_blue.gif FAQs 151 thru 200 square72_blue.gif


    This unofficial Open Scene Graph (OSG) FAQ Part 1 ( 1 thru 50) is provided by Gordon Tomlinson , I hope you find the information contained with these FAQ's useful and helpful. If you have a tip, FAQ or code snippet you would like to share you can send it me at faqs@3dscenegraph.com and I will add to the FAQ, or if you spot an error in a FAQ or a change in OSG that makes a topic out dated let me know and I will get the items updated


     

  1. What is Open Scene Graph (OSG)
  2. Is OSG the Same as Open Scene Graph
  3. What does Open Scene Graph Give Me
  4. Where can I get the Latest OSG
  5. Is there an OSG Mailing list
  6. Is there an OSG User Forum
  7. Are there any OSG Tutorials
  8. What 3d  Formats Does OSG Support
  9. What Image Formats Does OSG Support
  10. What's Wrong with the Header Files in OSG
  11. Can I Make my Editor Recognize OSG Header File
  12. How Can I Retrieve the Bounding Box of an osg::Node
  13. How Can I Retrieve the Bounding Sphere of an osg::Node
  14. Can I compute a bounding sphere for only certain Nodes
  15. How Can I Position a osg::Node in my Scene.
  16. How Can Set the HPR of my osg::Node
  17. Why does OSG ignore my Near Far Clipping Planes
  18. How can I get the Current Near &  Far Clipping Planes
  19. Why are my Scaled Models Shaded Incorrectly
  20. How Can I Set the Debug Info Level
  21. How do I Create a Debug Message
  22. My Geometry and Points Seem to be Being Culled by OSG
  23. Does OSG have any Terrain Support
  24. My osg::Drawable, drawImplementation Function is Called Only Once, Why
  25. Compiler Warning C4541: 'dynamic_cast' used on polymorphic type
  1. How Can I get Syntax Colouring with Extension Less Headers
  2. Why is My Dynamic Geometry is Not Being Updated
  3. How Do Import file format Not Supported by OSG
  4. Does OSG have a Native Binary Format Such  like PFB's.
  5. What is osgconv
  6. What Arguements are Supported by osgconv
  7. Why do Gridlines Appear in PagedLOD Ground Texture
  8. What is the Relationship Between  osg::State/OpenGL context ID's
  9. Sharing Scene Views amongst Rendering Surfaces
  10. With multiple rendering windows, I get weird results & textures display incorrectly
  11. Can I use OSG without Producer
  12. Where is the reference manual and programmers guide for OSG
  13. Whats the difference between Open Scene Graph and  OpenSG
  14. Particle system looks strange when I position them in my scene
  15. Can I use OSG within an existing Renderer engine
  16. Does OSG Support Multiple Threads or Processes
  17. How Can I get a Borderless window on win32
  18. Where can I Get CVS From
  19. How to disable lighting on a Node
  20. How to Force lighting on a Node
  21. How to disable texturing on a Node
  22. How to enable texturing on a Node
  23. How to Enable wireFrame mode on a Node
  24. How to disable wireFrame mode on a Node
  25. Can I share a single HUD over Multiple Windows

 

Resources

 

**  What is OSG - Open Scene-Graph b


    Open Scene Graph also commonly known as OSG is an Open Source, cross platform graphics toolkit for the development of high performance graphics applications such as flight simulators, games, virtual reality and scientific visualization.

    OSG is based around the concept of a Scene-Graph, it provides an object oriented framework on top of OpenGL freeing the developer from implementing and optimizing low level graphics calls, and provides many additional utilities for rapid development of graphics applications.

    For more details on what Open Scene Graph is visit the OSG Web Site

     

**  Is OSG the Same as Open Scene Graphb

     

    In the 3d simulation world many of the people use OSG and Open Scene Graph interchangeably. So yes in the is it is the same thing but the acronym OSG is used else were out side the 3d simulation world for other meanings, a quick google will show this to be the case

    But in the 3d World if you use OSG most people will know what you doing

     

**  What Does OSG Give Meb

     

    The stated goal of Open Scene Graph is to make the benefits of scene graph technology freely available to all, both commercial and non commercial users. OSG is written entirely in Standard C++ and OpenGL, it makes full use of the STL and Design Patterns, and leverages the open source development model to provide a development library that is legacy free and focused on the needs of end users.

    The stated key strengths of Open Scene Graph are its performance, scalability, portability and the productivity gains associated with using a fully featured scene graph, in more detail:

    • Performance

      Supports view frustum culling, occlusion culling, small feature culling, Level Of Detail (LOD) nodes, state sorting, vertex arrays and display lists as part of the core scene graph. These together make the Open Scene Graph one of the highest performance scene graph available.
    • Productivity

      The core scene graph encapsulates the majority of OpenGL functionality including the latest extensions, provides rendering optimizations such as culling and sorting, and a whole set of add on libraries which make it possible to develop high performance graphics applications very rapidly. The application developer is freed to concentrate on content and how that content is controlled rather than low level coding.

     

    • Format Support

      OSG now states that it includes 45 separate plugin's for loading various 3D database and image formats.
       

      3D database loaders include

      • OpenFlight (.flt)
      • TerraPage (.txp) including multi-threaded paging support
      • LightWave (.lwo), Alias Wavefront (.obj)
      • Carbon Graphics GEO (.geo)
      • 3D Studio MAX (.3ds)
      • Peformer (.pfb)
      • Quake Character Models (.md2)
      • Direct X (.x)
      • Inventor Ascii 2.0 (.iv)
      • VRML 1.0 (.wrl)
      • Designer Workshop (.dw)
      • AC3D (.ac)
      • .osg Native OSG ASCII format.
      • .osg Native OSG banary Format

       

      Image loaders include

      • .rgb
      • .gif,
      • .jpg
      • .png
      • .tiff
      • .pic
      • .bmp
      • .dds
      • .tga
      • quicktime (under OSX).
      • Fonts (via the freetype plugin)


    • Node Kits
    • OSG also has a set of Node Kits which are separate libraries that can be compiled in with your applications or loaded in at runtime, which add support for

      • particle systems (osgParticle)
      • high quality anti-aliased text (osgText)
      • special effects framework (osgFX)
      • OpenGL shader language support (osgGL2)
      • large scale geospatial terrain database generation (osgTerrain)
      • navigational light points (osgSim)
      • osgNV ( support for NVidia's vertex, fragment, combiner, Cg shaders )
      • Demeter (CLOD terrain + integration with OSG)
      • osgCal (which integrates Cal3D and the OSG)
      • osgVortex (which integrates the CM-Labs Vortex physics enginer with OSG)



    • Portability

      The core scene graph has been designed to have minimal dependency on any specific platform, requiring little more than Standard C++ and OpenGL. This has allowed the scene graph to be rapidly ported to a wide range of platforms - originally developed on IRIX, then ported to:
       
      • Irix
      • Linux
      • Windows
      • FreeBSD
      • Mac OSX
      • Solaris
      • HP-UX
      • PlayStation2
         
    • Window Systems

      The core OSG library is completely windowing system independent, which  makes it easy for users to add their own window-specific libraries and applications on top.

      In the distribution thereis already the osgProducer library which integrates with OpenProducer, and in the Community/Applications section of this website one can find examples of applications and libraries written on top of GLUT, Qt, MFC, WxWindows and SDL. Users have also integrated it with Motif, and X.

    • Scalability

      OSG will not only run on portables all the way up to Onyx Infinite Reality Monsters, but also supports the multiple graphics subsystems found on machines like a multi-pipe Onyx

    ( Note the above is more or less pulled straight from the OSG Web Site

     

**  Where Can I Get OSG Fromb


    You can basically 2 main ways to get hold of OSG

    You can down load pre-compiled binaries from the OSG downloads page

    Or you can retrieve the source for OSG from a CVS repository and build it your self using one of the following methods

    • Command line checkout
    • WinCVS checkout
    • MacCVS Pro checkout
    • CVS Browsing and Commit Query's


    CVS command line checkout instructions

    • Login to the cvs server and indicate the repository location with:

      cvs -d :pserver:anon@openscenegraph.net:/cvs/osg login

    You can supply an empty password (just hit return).

    • Checkout the source code with:

      cvs -z 6 -d :pserver:anon@openscenegraph.net:/cvs/osg co OpenSceneGraph

    • Updates occur nearly daily to the OpenSceneGraph source code, so it is recommended to update frequently. Update from within the OpenSceneGraph source tree with :

      cd OpenSceneGraph
      cvs update -Pd

    The -P argument will prune empty directories and the -d argument builds new directories if they've been added.

    I personally prefer to use and can highly recommend  WinCVS

     

**  Is there a OSG Mailing Listb

     

    Yes thereare currently four public OSG  mailing lists:

    osg-users

    For support and discussion.

    osg-news

    For news of new releases.

    osg-cvs

    To be notified when commits are made to the CVS repository.
    (Note: this list is read-only)

    osg-submissions

    To submit code changes, bug fixes, enhancements or code additions.
    (Note All submissions must confirm to the Submissions Protocol)

     

**  Is there a OSG User Forumb

**  Are there any OSG Tutorialsb


    thereare several sets of tutorials covering basic aspects of OSG and use with certain node kits and GUI, the following are list as of July 05


    ( Note that some of these sites can be un-accessible from certain countries or at times not available all

      

**  What 3d Formats Does OSG Supportb


    OSG supports the following 3D database formats

    • OpenFlight (.flt)
    • TerraPage (.txp) including multi-threaded paging support
    • LightWave (.lwo), Alias Wavefront (.obj)
    • Carbon Graphics GEO (.geo)
    • 3D Studio MAX (.3ds)
    • Performer (.pfb)
    • Quake Character Models (.md2)
    • Direct X (.x)
    • Inventor As 2.0 (.iv)
    • VRML 1.0 (.wrl)
    • Designer Workshop (.dw)
    • AC3D (.ac)
    • .osg Native OSG ASCII format.
    • .osg Native OSG binary Format

    See the OSG distribution for the latest full list of supported formats
     

**  What Image Formats Does OSG Supportb

     

    OSG supports the following Image formats

    • .rgb
    • .gif,
    • .jpg
    • .png
    • .tiff
    • .pic
    • .bmp
    • .dds
    • .tga
    • quicktime (under OSX).
    • Fonts (via the freetype plugin)

    See the OSG distribution for the latest full list of supported formats

 

* 10  *  What's With the Header Files in OSGb

* 11  *  Can I Make my Editor Recognise OSG headersb


    Is thereany way I can get my editor to recognise those darn extension-less headers in OSG

    It all depends on your editor and platform, some possibilities include:

    • Visual Studio:
      OSG source includes a file called LANGEXT.DAT in the OSG/Visual Studio directory. See the documentation for instructions for how to use the file
       
    • Vim:
      Can be made to recognize the mode string, "-*-c++-*-", at the beginning of each header file. Start vim. type ":set runtimepath" to see where vim looks for scripts. You can make a file in any of these directories (for example, ~/.vim on Linux). Make the directory if it doesn't already exist, and make a file called scripts.vim in that directory. The contents of that file should be:

      if getline(1) =~ '-*-c++-*-'

      set filetype=cpp

      endif

     

    • Emacs:
      Should recognize the mode string right out of the box.
       
    • Nedit:
      Can be told to treat files as C++ based on their location in an include directory
       
    • Dev-C++:
      In Tools/Editor Options/General thereis an option "Use Syntax Highlighting". In the box below add ;;. The final line will look like this: c;cpp;h;hpp;;. This will enable syntax highlighting in all files without extension.
       

* 12  *  How Can I Retrieve  the Bounding Box of an osg::Nodeb


    OSG stores a bounding sphere for all internal nodes (osg::BoundingSphere)

    To get  a Bounding Box of an osg::Node have to convert the Bounding Sphere to a BoundingBox along the following line:

Code :

--


    osg::BoundingBox bbox;

    bbox.expandBy( m_node->getBound() );

     

 

    Note that OSG use Bounding Box's at the  Drawable leaves level.
     

* 13  *  How Can I Retrieve the Bounding Sphere of an osg::Nodeb

     

    OSG stores a bounding sphere for all internal nodes (osg::BoundingSphere)

    Simply call the following to get the bounding sphere:

Code :

--


    osg::BoundingSphere bsphere =  m_node->getBound();

     

 

     

* 14  *  Can I compute a bounding sphere for only certain Nodesb

     

    Yes you can use the   osg::Node::ComputeBoundingSphereCallback mechanism to do this

    void setComputeBoundingSphereCallback(ComputeBoundingSphereCallback* callback)

    You will need to derive your own class from override the osg::Node::ComputeBoundingSphereCallback then you ovveride the computeBound  function

    (virtual BoundingSphere computeBound(const osg::Node&) ) with this function you place your logic in to identify the nodes of interest etc. 

    I have not seen this used in an samples as yet.

     

* 15  * How can I Position my Nodes or Models within the Scene b

     

    To move a node in OSG you need to attach that node to an osg::PositionAttitudeTransform or osg::Transform ( if the node is note one of these types)

    For example using a osg::PositionAttitudeTransform postion a node ate x = 100.00, y = 250.0 and z = 75.0
     

Code :

--


    osg::PositionAttitudeTransform *transform = new osg::PositionAttitudeTransform;

    transform->addChild(  myNode );

    transform->setPosition( osg::Vec3( 100.0, 250.0, 75.0 ) );

     

 

    or if your node is already an  osg::PositionAttitudeTransform simply
     

Code :

--

 

    myNode->setPosition( osg::Vec3( 100.0, 250.0, 75.0 ) );

     

 

     

* 16  *  How Can I set the HPR of my OSG Nodeb

     

    To set the orientation of an node in OSG you need to attach that node to an osg::PositionAttitudeTransform or osg::Transform ( if the node is note one of these types)

    OSG does note provide nice convenience functions for setting HPR angles like Performer or Vega Prime supply

    In OSG you have to use Matrices or Quaternion's for example

    To set the Heading you can do something along the lines of:    
     

Code : Set heading

--

 

    transform->setAttitude(osg::Quat(osg::DegreesToRadians( heading ),osg::Vec3(0,0,1)));

     

 

          

    To set the Pitch you can do something along the lines of:      
        

Code : Set Pitch

--

 

    transform->setAttitude(osg::Quat(osg::DegreesToRadians( heading ),osg::Vec3( 1,0,0)));

     

 

         

    To set the Roll you can do something along the lines of:          
          

Code : Set Roll

--

 

    transform->setAttitude(osg::Quat(osg::DegreesToRadians( heading ),osg::Vec3(0,1,0)));

     

 

    Setting HPR all at once  you can do something along the lines of:


 

Code : Set Roll

--

 

    transform->setAttitude(osg::Quat( osg::DegreesToRadians( roll ),osg::Vec3(0,1,0),

                                   osg::DegreesToRadians( pitch ),osg::Vec3(1,0,0),

                                   osg::DegreesToRadians( heading ),osg::Vec3(0,01,0)));

     

 

     

* 17  *  Why does OSG ignore my Near Far Clipping Planesb

     

    Why does OSG ignore my Near Far Clipping Planes

    When using osgUtil::SceneView, OSG is set up by default such that near and far clipping planes are recomputed on the fly based on eye point and viewable scene. This means that your setting will be overwritten

    This is designed in OSG and is used  optimize the near/far range of the depth buffer, which might otherwise contain "z-fighting" artefacts if near and far are set to unreasonably small or large values, which is fine for certain applications for many others it is not fine and is a pain that catches many users out.

    Thankfully thereis a simple work around to this,  you can override this behaviour by calling:
     

Code :

--

 

    sceneview->setComputeNearFarMode( osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR );

     

 

    If you are using osgProducer::viewer use:

Code :

--

 

    viewer->wGetCullSettings->setComputeNearFarMode(

                              osgUtil
    ::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR );

     

 

     

* 18  *  How can I get the Current Near &  Far Clipping Planesb


    You can do something along the lines of:

Code :

--

 

    double nearclip = sceneView->getCullVisitor()->getCalculatedNearPlane();

    double farclip  = sceneView->getCullVisitor()->getCalculatedFarPlane();  

     

 


    also you can do the following:

       

Code :

--

 

    double d, nearclip = 0.0,  farclip = 0.0;

    sceneView->getProjectionMatrixAsFrustum( d, d, d, d, nearclip, d );    

    sceneView->getProjectionMatrixAsFrustum( d, d, d, d, d, farclip );

     

 

     

* 19  *  Why are my Scaled Models Shaded Incorrectlyb

     

    The problem you seeing is that your normals are being scaled along with your geometries and vertices.

    To keep your normals 'normalized',  you can set the following attribute on appropriate stateset(s):
     

Code :

--

 

    stateSet->setMode( GL_RESCALE_NORMAL, osg::StateAttribute::ON );

     

 

    Also you could consider using an osgUtil::SmoothingVisitor

     

* 20  *  How Can I Set the Debug Info Levelb


    You can do this by setting the OSG_NOTIFY_LEVEL environment variable to a higher level ( Levels in increasing levels of output )

    • ALWAYS
    • FATAL
    • WARN
    • NOTICE
    • INFO
    • DEBUG_INFO
    • DEBUG_FP  

    In code you can call the following with the level of output required

Code :

--

 

    osg::setNotifyLevel( osg::INFO );

     

 

     

* 21  *  How do I Create a Debug Messageb


    You can use the osg::Nofity class to output debug and informative information to the console window (default output)

    For example: 

     

Code :

--

 

    osg::notify( osg::NOTICE ) << "Error reading file  "

                                << srcFileName.c_str()

                                << "  "

                                << std::endl;

     

 

    Note the for the message to be displayed to the console the level must be equal to or less than level set by osg::setNotifyLevel

    Avaliable Levels in increasing levels of output

    • ALWAYS
    • FATAL
    • WARN
    • NOTICE
    • INFO
    • DEBUG_INFO
    • DEBUG_FP

     

* 22  *  My Geometry and Points Seem to be Being Culled by OSGb

     

    Yes its is quiet possible that OSG is culling away your geometry or points ( assuming you do not have LODS, that my be doing this), its another one of those little annoying gotchas that you come across ;(, ( This is where a OSG Programmers Guide would really really help)

    OSG by default uses small feature culling to cull out objects that occupy a predetermined screen size.

    This is a valuable feature for models with many details which do not contribute to the visual quality of the model when viewed from a distance. You can completely disable small feature culling by defining the cullingMode on osgUtil::SceneView with:

Code :

--

 

    osg::CullStack::CullingMode cullingMode = sceneview->getCullingMode();

     

    cullingMode &= ~ ( osg::CullStack::SMALL_FEATURE_CULLING  );

     

    sceneview->setCullingMode( cullingMode );

     

    //

    // You can also control the size of the screen space that is used to cull

    // small features with

    //

    sceneview->setSmallFeatureCullingPixelSize( minimumSize );

     

 

     

     

* 23  *  Does OSG have any Terrain Supportb


    OSG  now has the osgTerrain  Node Kit for generation large paged geospatial databases.

    For CLOD  implementation (Continuous Level of Detail) approach to terrain see Demeter (http://www.terrainengine.com/) and Virtual Terrain Project (http://www.vterrain.org/) for detailed open source approaches.

    OSG also loads Terrex TerraPage tiles

    OSG can also load the Open Flight output of Multigens Creator Terrain Studio and Creator Terrain Pro products

    At some point OSG may have a Meta-Flight loader again for output from Creator Terrain Studio ( depends if I ever write one or some one else)

     

* 24  *  My osg::Drawable, drawImplementation Function is Called Only Once, Why b

     

    When your class is derived from osg::Drawable and you derived drawImplementation is called only once, this typically means that  you have enable Display Lists for the drawable

    So try disabling the use of display list for your derived class.

    myDrawable->setUseDisplayList( false );
     

* 25  *  I get a Compiler Warning C4541: 'dynamic_cast' used on polymorphic typeb

     

    This normally means that you have disabled Run-time Type identification (RTTI), You will need to enable the run-time type identification for you compiler

    With Visual Studio, you can simply add /GR switch in the project options. Also you can find the option in the development environment, select Settings on the Project menu. Then select  the C/C++ tab, and select  C++ Language in the Category box. There's a checkbox right therefor "Enable RTTI" make sure you have it selected and ticked.

     

* 26  *  How Can I get Syntax Colouring with Extension Less Headersb


    Yes you can get Syntax colour working correctly with OSG's use of Extensionless  Headers. You can get this to work in for Visual Studio(6.0) and Visual Studio .Net ( 7.x)

    First look have a lLook in your Visual Studio directory of the Openg Scen Graph  install see the "read me" file located in therefor the latest information

    For syntax highlighting in VisualStudio which the standard C++ style headers found in the OSG :

    Visual-Studio6.0  Substitute or merge  the LANDEXT.DAT file found in this directory with the one found

    C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin

    VisualStudio .NET Install the highlightXX.reg (just double click it). This will update Extensionless file for Visual Studio.  Don't worry, it will keep the current extensionless files (STL ones) intact.

    the important files are :

    C:\OpenSceneGraph\VisualStudio\MUST_READ_ME.txt

    OpenSceneGraph\VisualStudio\highlight71.reg

    OpenSceneGraph\VisualStudio\highlight70.reg

    OpenSceneGraph\VisualStudio\LANGEXT.DAT

     

* 27  *  Why is My Dynamic Geometry is Not Being Updatedb


    Q: I have created geometry drawn using  vertex arrays which I update dynamically but OSG is not showing the changes I made

    This could be one of a couple of things

    By default OSG compiles a display list of geometry the first time it is drawn and subsequently uses the display list to draw the geometry rather than using immediate mode rendering, this is a useful optimisation.

    OSG does not currently track the state of the geometry,  you have to tell OSG to update the geometry, so you need to call the function m_geometry->dirtyDisplayList() after you have updated your geometry.

    Alternatively you can turn the use of display list of with m_geometry->setUseDisplayList( false ); , all though only do this if you changing the data every frame.

    Another problem may be that you are changing the number of primitives being draw, again you have to tell OSG that you have changed the number of primitives in use with DrawArrays::setCount()

    Finally you may also need to call  m_geometry->dirtyBound();
     

* 28  * How Do Import file format Not Supported by OSG b


    One method would be to convert the files to a format thats is supported by OSG; you should  be able to use a format conversion program such as Polytrans or Deep Exploration. These offer a good selection of import formats and the ability to output OpenFlight models.

    The other alternative is to write your own format loader.

    Take a look at any of the plugin source as an example of how to do this. You will need to  derive your loader from osgDB::ReaderWriter and implement the following functions

    • className()
    • acceptsExtension()
    • readObject()
    • readNode()

    The function readNode() will be passed the name of the file to parse and should return a pointer to the subgraph created after parsing the file.

    You will also need to declare a proxy instantiation of your class, something like (If your class is named KGLLoader):

    osgDB::RegisterReaderWriterProxy<KGLLoader> g_kglLoader_Proxy;

    This has be compiled in to a dynamic shared object .so (Unix), dll (Windows), or bundle (Mac OS).  osgDB will then load this module at run time when a file named .kgl  (or whatever extension acceptsExtension() returns true for).

     

* 29  *  Does OSG have a Native Binary Format Such like Performers PFB'sb


    Yes OSG does have its own Native fast binary format, its extension is .IVE

    You can convert files to the IVE format simply using the OSG program osgconv

    For examples ( basic usage osgconv  [args] inputFile(s) outputFile

    osgconv my_file01.flt my_file02.flt my_file03.flt  my_file99.flt  my_big_Database.ive

     

* 30  * What is osgconv  b

     

    osgconv is a Open Scene Graph  utility program for reading in 3d databases formats and writing them out to its native *.ive binary format  and the *.osg ASCII format ( similar to Vega Prime's *.vsb and Performer's *.pfb binary formats)

    osgconv can also apply optimizations to the files it reads, compact multiple files in to one output file, inline textures in to the file. The resultant binary files will load considerably faster in Open Scene Graph compared to loading native 3d formats such as 3ds, OBJ, WRL files etc.

     

* 31  *  What the command arguements are Supported by osgconv  b

     

    For a full list of command line options supported type:( see http://www.openscenegraph.org/index.php?page=UserGuides.Osgconv as well )

    osgconv --help

    Which will print out out the following:

    usage:

    osgconv [options] infile1 [infile2 ...] outfile
    

    command options:

    -O option

    ReaderWriter? option

    --compressed

    Compress textures.

    --compressed

    Enable the usage of compressed textures.

    --compressed-arb

    Enable the usage of OpenGL ARB compressed textures

    --compressed-dxt1

    Enable the usage of S3TC DXT1 compressed textures

    --compressed-dxt3

    Enable the usage of S3TC DXT3 compressed textures

    --compressed-dxt5

    Enable the usage of S3TC DXT5 compressed textures

    -l libraryName

    load plugin of name libraryName i.e. -l osgdb_pfb
    Useful for loading reader/writers which can load other file formats in addition to its extension.

    -e extensionName

    load reader/wrter plugin for file extension i.e. -e pfb
    Useful short hand for specifying full library name as done with -l above, as it automatically expands to the full library name appropriate for each platform.

    -o orientation

    Convert geometry from input files to output files.
    Format of orientation argument must be the following:

    X1,Y1,Z1-X2,Y2,Z2
    or
    degrees-A0,A1,A2

    where X1,Y1,Z1 represent the UP vector in the input files and X2,Y2,Z2 represent the UP vector of the output file, or degrees is the rotation angle in degrees around axis (A0,A1,A2). For example, to convert a model built in a Y-Up coordinate system to a model with a Z-up
    coordinate system, the argument may look like

    0,1,0-0,0,1
    or
    -90-1,0,0

    -t translation

    Convert spatial position of output files. Format of translation argument must be the following :

    X,Y,Z

    where X, Y, and Z represent the coordinates of the absolute position in world space

    -s scale

    - Scale size of model. Scale argument must be the following :

    SX,SY,SZ

    where SX, SY, and SZ represent the scale factors. Caution: Scaling will be done in destination orientation

     

* 32  * Why do Gridlines Appear in PagedLOD Ground Texture b


    At times Black Grid lines appearing  through out tmy  ground texturea,  the lines coincide with the LOD-tiles / textures Also when the gridlines appear, the update rate also reduces to 1Hz (normally 30-60Hz)

    The most probable cause for gridlines may come from the OpenGL texture edge wrap setting. Such that when your S and T wrap modes are set to GL_CLAMP, you will  sample some of the default black at the texture edge.

    The fix is to change your S and T wrap mode to GL_CLAMP_TO_EDGE. This clamps S and T values such that the edge is never sampled. In raw OpenGL, you'd use glTexParameter to do this. OSG has a similar mechanism.

    However, this will introduce a new problem though; when tiling textures, you will see a visible seam at high magnifications this will not as bad as the black gridlines, but visible nonetheless.

    thereare a couple ways you can work around this. One way is to go back to GL_CLAMP, but actually set the texture edge to contain a copy of neighbour texture border data. To do this, you'll need to make your textures a power of 2 plus 2 in both width and height. Yet another way is to essentially do the same thing, but then resample the texture back down to a power of 2 and stick with GL_CLAMP_TO_EDGE -- the benefit here being that you can use S3TC compression (which doesn't allow texture edges)
     

* 33  * What is the Relationship Between  osg::State's & OpenGL context ID's b


    A osg::State's context id, is an index / key into an std::map.  The map stores ids for texture handles and display lists.  For each texture, you will have a handle that is unique for each graphics context.  Likewise for display lists.  While the data is shared, the texture handles and display list handles are not.

    thereis no direct relationship between an osg::State's contextID, it is in fact, arbritrary, and the graphics context, other than the fact that theremust be a one to one correspondence.  During rendering, a context is made current, and all rendering that occurs while that context is current will use texture handles and display list handles that were created with in that context
     

* 34  * Sharing Scene Views amongst Rendering Surfaces b


    Q:  if I have one Scene View that draws to multiple  Render Surfaces, do those Render Surfaces have to share a context?

    Attempting to have one scene view between multiple graphics contexts, may either not be possible or be very hard.  

    The right way to do this is to have a scene view for each graphics context (note: each unique RenderSurface will need a unique context - when contexts are made current, they are made current along with the window/drawable/RenderSurface).  What is shared is the scene graph.  

    The SceneView is not a heavy data structure and little is gained by trying to share it.  A scene graph, however, can carry quite a large memory footprint, so replicating it is not efficient.  

    All that is replicated are texture handles and display list handles, like this: 
     

Code :

--

 

    osg::ref_ptr <osg::Node> database = osgdB::readNodeFile( "filename.flt" );

    osg::ref_ptr <osgUtil::SceneView> sv0 = new osgUtil::SceneView;

    sv0->setSceneData( database.get() );

    osg::ref_ptr <osgUtil::SceneView> sv1 = new osgUtil::SceneView;

    sv1->setSceneData( database.get() );

    void mainLoop()    {

        sv0->update();

        sv0->cull();

        makeContextCurrent( Context0 );    

        sv0->draw();

        sv1->cull();

        makeContextCurrent( Context1 );

        sv1->draw();

        makeContextCurrent( Context0 );

        swapBuffers();

        makeContextCurrent( Context1 );        

     

        swapBuffers();

     

 

     

     

* 35  *  With multiple rendering windows, I get weird results & textures display incorrectlyb

     

    Each rendering window has its own OpenGL context which is separate from all other contexts.  OSG doesn't know how you set up your windowing environment, you thus need to ensure that each osg::State object is tied to a unique OpenGL context. To do that you do something along the lines of:

    1. for each window, get the associated osgUtil::SceneView object
    2. for each SceneView object, get the associated osg::State object
    3. call State::setContextID() on each State, passing a unique number to identify that context

Code :

--
                                    
                                          
    osgProducer::OsgSceneHandler *m_shandle = NULL;  
     
    osgUtil::SceneView  *m_sceneview_one    = NULL;
     
    osgUtil::SceneView  *m_sceneview_two    = NULL;
     
    //
    // Grab the SceneViews  
    //
    m_shandle = dynamic_cast<osgProducer::OsgSceneHandler *>( camera_one->getSceneHandler() );    
     
    m_sceneview_one = m_shandle->getSceneView();
     
    m_shandle = dynamic_cast<osgProducer::OsgSceneHandler *>( camera_two->getSceneHandler());    
     
    m_sceneview_two = m_shandle->getSceneView();
     
     
    //  
    //  Create the default osg::State and the reset of the First Sceneviews defaults
    //
    m_sceneview_one->setDefatults();
     
    //  
    // now set the ID to 0 ,this is the default
    //
    m_sceneview_one->getState()->setContextID(0);
     
     
     
    //  
    //  Create the default osg::State and the reset of the Second Sceneviews defaults
    //
    m_sceneview_two->setDefatults();
     
    //  
    // now set the ID to 1, on the next sceneview
    //
    m_sceneview_two->getState()->setContextID(1);

     

 

    Note, that context ID's are used as indices in to vectors that grow automatically, so avoid setting large numbers, start counting from 0 and then increment by one each time

     

* 36  * Can I use OSG without Producer b

     

    Yes you can use Open Scene Graph  with or without Producer, even if you are creating your own windows

    See the osgsimple sample program for an example of using Open Scene Graph with a generic windowing environment

    OSG itself is windowing system agnostic, so setting up the window and OpenGL graphics context will be up to your application

    Note osgsimple uses Producer, but has been  written in a way to provide you the skeleton to use your own windowing system.

    Another aproach to consider it to use the Producer infrastructure in your own windowing environment as well by setting each Camera's RenderSurface to the window you have  created.

    Along the lines of:

Code:

--
     
    osgProducer::Viewer viewer;
     
    viewer.getCamera(0)->getRenderSurface()->setWindow( m_Window );
     
    //
    // note m_Window  is an X11 Windows XID  , or a Windows win32 HWND handle
    //

     

 

     

* 37  *  Where are the reference manual and programmers guide for OSGb


    Unfortunately no there is currently no real Reference manuals or Programmers guides for Open Scene Graph such as you would find with Performer or Vega for examples

    See the OSG website for the latest available documentation, the recommendation on the OSG web site it to "Use the Source"

    While having access to the source is a good thing for many , I have to disagree with some of the sentiments found in "Use the Source". Having the source assumes you readily understand how it all works or that you can deduce this from the code; this is not true for many who are new to OSG or to the simulation world and can be seen by many of the question on the mailing lists.

    Further the search the source can be a real time waster trying to find a solution to the problem your trying to solve when you don't really know what part of OSG may help you solve the problem.

    A good Programmers guide can really help you find what you looking for and how things relate very quickly SGI's Opengl Performer's programmer guide is a good example of this and is actually quite useful in understanding on how much of OSG works ( Links to Performer Docs)

    While OSG has documents generated from headers and source, a lot of material found there is does not have context and can thus be difficult to assimilate, again a good programmers guide and reference manual can give the require context

    Hopefully one day OSG will have these documents its one of the things that really lets OSG down for many users and potential user IMO, in the mean time, search forums, search mailing list, search the examples and tutorials you can find at 3dscenegraph.com and the OSG web site

     

* 38  * Whats the difference between Open Scene Graph and  OpenSG b

     

    Basically different markets is the main difference OSG is aimed at the traditional 3d real-time simulation market ( e.g flight Sim)  , while OpenSG is more aimed at the CAD/CAM markets, unfortunately the names do cause some confusion but I doubt that either will be changing its name any time soon.

    Don Burns wrote this in the subject

    The quick answer is that, no, there is no connection between Open Scene Graph and OpenSG. Robert and I know the author of OpenSG, Dirk Reiners, and have often engaged in lively conversation with him regarding scene graphs, visualization and the price of tea in China. One might consider us as "in competition", whatever that means in an open source world, but with mutual respect and cooperative attitudes toward each other.

    The initial purpose of the two projects seems quite similar at first glance, but a closer look will reveal that the focus is a bit different. One might think of the difference in a historical context as the difference between Inventor and Performer. OpenSG is used primarily in CAD and manufacturing circles (though that may have changed over the years), where frame rates need only be interactive, whereas Open Scene Graph is focused on higher performance real-time rendering. Neither seems to be exclusive of the needs of the other, but our respective expertise shows through in the final emphasis.

    There are many other differences from an architectural, modularity and software design perspective. These are arenas where the programmer must decide what works best with their environment. We are, of course, biased here.

    What is unfortunate is the coincidence of the names. It is not to be totally unexpected, however. Both projects became public the same year. This is the same year, not coincidentally, that Farenheit (some of you may recall) took a belly flop onto a large concrete slab. This ill fated belly flop, however, took place only _after_ putting the taste of a cross-platform, high-level, scene graph based rendering package in our mouths.

    Open Source responded as Open Source often does. The idea of having an open source, cross platform, scene graph was not unique to the genius behind either of the two projects. In fact, there were many, many, open source scene graphs that sprung to life at this time. It is, in fact, somewhat remarkable that only two of us came up with the most generic name "Open Scene Graph". What motivated the choice of OpenSG rather than Open Scene Graph, on Dirk's part, I can only speculate about (and I will).

    Ok, for the record (and I'm not making a huge deal over this, nor am I attempting to instigate contention), we were there first. Try this from a Unix machine:

      % whois Open Scene Graph.org | grep Created

      Created On:15-Oct-1999 08:39:02 UTC

      % whois opensg.org | grep Created

      Created On:05-Nov-1999 15:09:16 UTC

       

    So, my speculation is that the OpenSG folks wanted the name, but it was taken, so they settled on OpenSG instead of Open Scene Graph, throwing the entire known free world into a state of chaotic confusion and economic meltdown. Well... that might be an exaggeration. The truth is, we once got each others' SIGGRAPH BOF attendees when the meetings were held at the same hotel. OpenSG was in Salon A of Tower I and Open Scene Graph was in Salon A of Tower II, both held at nearly the same time.

    If these were conventional, commercial ventures, we might be spending a lot of money on lawyers (which would, of course, be reflected in the price of the conventional, commercial product) to sort this out. Thank goodness we can simply just chuckle about it together over a beer.

    In all cases, the other interesting attribute of Open Source software is that it places it in to an arena where "survival of the fittest" determines longevity. The list of useful open source scene graphs is getting shorter. Open Scene Graph is growing very quickly at the current time, and OpenSG seems to holding its own. One might argue then that as the field narrows, perhaps we could ease everyones confusion and change one of the names so it didn't look so much like the other one
     

* 39  *  Particle system looks strange when I position them in my sceneb


    You are probably rotating both the particle systems and the particle emitters. The tranform above the particle system(s) should match your world's (absolute) coordinate frame, or the reference frame that "contains" the particles (for example, an airplane or a car).

    To transform a particle system inside this reference frame you should transform only the emitters, not the ParticleSystem drawables. If you apply a transform above "fountain.osg" you actually apply a translation/rotation to both emitters and particle systems;

    To get a correct behavior you should traverse the scene graph and avoid applying the transform to any geodes containing ParticleSystem drawables

    (courtesy Marco Jez)

     

* 40  *  Can I use OSG within an existing Renderer engineb

     

    Yes this can be done but does takes a little work, but it is entirely possible to use OSG within a pre-existing rendering engine

    First of all, the central object you should know about is osgUtil::SceneView. This class will manage the OSG specific rendering tasks. If you want to take advantage of OSG's animation capabilities, you will also want to maintain your own FrameStamp object.

    The setup of these two objects will look something like this:

Code :

--

     

    unsigned int frameNumber = 0;

    osg::Timer timer;

    osg::Timer_t start_tick = timer.tick();

    osg::ref_ptr< osgUtil::SceneView > sceneViewer = new osgUtil::SceneView();

    osg::ref_ptr< osg::FrameStamp > frameStamp = new osg::FrameStamp();

    sceneViewer->setDefaults();

    sceneViewer->setComputeNearFarMode( osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR );

    sceneViewer->setSceneData( rootNode );
     

     

 

    Note, just replace rootNode with your actual root node for you OSG models.

    NOTE: The call to setComputeNearFarMode is very important. If you don't do this, then OSG will use a different near and far plane when rendering its objects, and they will have different values in the depth-buffer than the rest of your scene. This can lead to very odd effects.

    If you want to use lighting that is different from what the rest of your renderer is using, you might want to call either:
     

Code :

--

     

    sceneViewer->setLightingMode( osgUtil::SceneView::SKY_LIGHT  );

    //  or

    sceneViewer->setLightingMode( osgUtil::SceneView::HEADLIGHT );

     

     

 

    That's basically it for setup.

    Now you just need to call SceneView for rendering, and this requires a little extra work.

    First off, it is recommended that you call glPushAttribs( GL_ALL_ATTRIB_BITS ) and glPushMatrix for each of the modelview, projection and texture matrices before calling your other OpenGL code, and the corresponding pop fuctions afterwards, and do the same with OSG. This prevents OSG and your other OpenGL code from interfering with each other. For example:

     

Code :

--

     

    glPushAttrib( GL_ALL_ATTRIB_BITS );

     

    glMatrixMode( GL_PROJECTION );

     

    glPushMatrix();

     

    glMatrixMode( GL_TEXTURE );

     

    glPushMatrix();

     

    glMatrixMode( GL_MODELVIEW );

     

    glPushMatrix();

     

    //

    //........................

    //

     

    Your code here...

     

    //

    //........................

    //

     

    glMatrixMode( GL_TEXTURE );

     

    glPopMatrix();

     

    glMatrixMode( GL_PROJECTION );

     

    glPopMatrix();

     

    glMatrixMode( GL_MODELVIEW );

     

    glPopMatrix();

    glPopAttrib();

     

     

 

     

    The next important thing for using SceneView is that you need to tell it about your pre-existing viewport and projection and modelview matrices. The code to do that looks like this:

     

Code :

--

     

    GLint viewParams[4];

    glGetIntegerv( GL_VIEWPORT, viewParams );

    sceneViewer->setViewport( viewParams[0], viewParams[1], viewParams[2], viewParams[3]);

    GLfloat glMat[16];

    osg::Matrix osgMat;

    glGetFloatv( GL_PROJECTION_MATRIX, glMat);

    osgMat.set( glMat );

    sceneViewer->getProjectionMatrix().set( osgMat );

    glGetFloatv( GL_MODELVIEW_MATRIX, glMat );

    osgMat.set( glMat );

    sceneViewer->getViewMatrix().set( osgMat );

     

     

 

    The next step is to update your FrameStamp object (if you are using your own):

     

Code :

--

     

    double time_since_start = timer.delta_s( start_tick, timer.tick() );

     

    frameStamp->setReferenceTime( time_since_start);

     

    frameStamp->setFrameNumber( frameNumber++ );

     

    sceneViewer->setFrameStamp( frameStamp.get());

     

     

    //

    // Lastly, you need to make the actual calls to the SceneView object:

    //

     

    sceneViewer->update ();

     

    sceneViewer->cull ();

     

    sceneViewer->draw ();

     

 

     

    If you do all of that, you should be able to successfully use OSG within your pre-existing rendering system, thereby gaining many of the advantages of OSG, without having to scrap your existing system

     

* 41  *  Does OSG Support Multiple Threads or Processes b


    "OSG currently does not provide Multi-process or Multi-threaded support for the APP CULL and DRAW  processes in the same way that other API's such as say Vega, OpenGL Performer or Vega Prime"

    OSG's multithreaded support is done through Producer.  Not only does Producer provide multithreading support, it provides an improved mult-threading model over those offered by Vega, Performer and Vega Prime, by accomplishing this without the overhead of multi-buffering.

    This provides single-threaded performance, linearly scalable with the addition of processors and graphics subsystems.  APIs with multi-buffering have reduced scalability with the increase in processing units.

    While the statement is technically correct (OSG on its own does not offer multithreaded support) the omission of Producer's contribution is a gross underevaluation of capability.  There was mention of Keyboard and Mouse capabilities on this FAQ question as well, so I'm led to believe that the answer did not come at the exclusivity of Producer.

    On the other hand, with Robert's direction with CameraNode (the intention of which is anyone's guess) the statement might be prophetic

     

* 42  * How Can I get a Borderless window on win32 b

     

    Q: How Can I get a Borderless window on win32 for a windowed application, not a full screen application 

    You can achieve this with by using the following which needs to be called  after you have called viewer.realize();

     

Code:

--
     
    Producer::CameraConfig *cameraGrg = m_viewer->getCameraConfig();
    Producer::Camera *camera = cameraGrg->getCamera(0);
    Producer::RenderSurface  *renderSurf = *camera->getRenderSurface();    
    HWND m_hwnd =( HWND )renderSurf->getWindow();
    DWORD winStyle = ::GetWindowLong( m_hwnd, GWL_STYLE );
    winStyle  &= ~WS_OVERLAPPEDWINDOW;
    winStyle  |= WS_POPUP;  
    ::SetWindowLong( m_hwnd, GWL_STYLE, winStyle );
    //
    // You can also get the HWND with one long call, such as
    //
    m_hwnd = (HWND)m_viewer->->getCameraConfig()->getCamera(0)->getRenderSurface()->getWindow();

     

 

     

* 43  *    Where can I Get CVS Fromb

* 44  *  How to Disable Lighting On A Nodeb

     

    You can force the lighting to be OFF for a node and its children using something like the following

     

Code:

--
     
    void    
    forcedLightingModeOff( osg::Node *srcNode ) {
    // -------------------------------------------------------------------------------
    //  Public Function
    //   
    //  Force the Node and its children to be un-Lit, this will override
    //  the Lighting states of the nodes parents  
    //  
    // -------------------------------------------------------------------------------
           
        //  
        //  Quick Sanity Check we need a node
        //  
        if( srcNode == NULL )
            return;
     
        //  
        //   Grab the state set of the node, this  will a StateSet if one does not exist
        //  
        osg::StateSet *state = srcNode->getOrCreateStateSet();
     
        //  
        //   Now we can set the state to Lighting OFF  
        //  
        state->setMode( GL_LIGHTING, osg::StateAttribute::PROTECTED | osg::StateAttribute::OFF );
     
     
    } // forcedLightingModeOff
     

     

 

     

* 45  * How to Force Lighting On A Node b

       


    You can force the lighting to be ON  for a node and its children using something like the following

       

Code:

--
     
    void    
    forcedLightingModeOn( osg::Node *srcNode ) {
    // -------------------------------------------------------------------------------
    //  Public Function
    //   
    //  Force the Node and its children to be Lit, this will override  
    //  the Lighting states of the nodes parents  
    //  
    // -------------------------------------------------------------------------------
           
        //  
        //  Quick Sanity Check we need a node
        //  
        if( srcNode == NULL )
            return;
     
        //  
        //   Grab the state set of the node, this  will a StateSet if one does not exist
        //  
        osg::StateSet *state = srcNode->getOrCreateStateSet();
     
        //  
        //   Now we can set the state to Lighting On
        //  
        state->setMode( GL_LIGHTING, osg::StateAttribute::PROTECTED | osg::StateAttribute::ON );
     
     
    } // forcedLightingModeOn
     

     

 

     

*  46  *  How to Disable texturing on a Node b

     

    You can force the Texturing mode to be OFF for a node and its children using something like the following

     

Code:

--
     
    void    
    forcedTextureModeOff( osg::Node *srcNode ) {
    // -------------------------------------------------------------------------------
    //  Public Function
    //   
    //  Force the Node and its children to be un-textured, this will override
    //  the texture states of the nodes parents  
    //  
    // -------------------------------------------------------------------------------
           
    //  
    //  Quick Sanity Check we need a node
    //  
    if( srcNode == NULL )
            return;
     
     //
     //   Grab the state set of the node, this  will a StateSet if one does not exist
     //  
     osg::StateSet *state = srcNode->getOrCreateStateSet();
     
     //  
     //   Now we can set the state to Texturing OFF  
     //  
     state->setTextureMode(0,GL_TEXTURE_2D,osg::StateAttribute::PROTECTED | osg::StateAttribute::OFF);
     
     
    } // forcedTextureModeOff
     

     

 

 

* 47  *  How to Enable texturing on a Node b

     

    You can force the Texturing mode to be ON for a node and its children using something like the following

       

Code:

--
     
    void    
    forcedTextureModeON( osg::Node *srcNode ) {
    // -------------------------------------------------------------------------------
    //  Public Function
    //   
    //  Force the Node and its children to be textured, this will override
    //  the texture states of the nodes parents  
    //  
    // -------------------------------------------------------------------------------
           
    //  
    //  Quick Sanity Check we need a node
    //  
    if( srcNode == NULL )
            return;
     
     //
     //   Grab the state set of the node, this  will a StateSet if one does not exist
     //  
     osg::StateSet *state = srcNode->getOrCreateStateSet();
     
     //  
     //   Now we can set the state to Texturing ON  
     //  
     state->setTextureMode(0,GL_TEXTURE_2D,osg::StateAttribute::PROTECTED | osg::StateAttribute::ON);
     
     
    } // forcedTextureModeON
     

     

 

     

* 48  * How to Enable  wireFrame mode on a Node  b

     

    You can force the Wireframe mode to be ON for a node and its children using something like the following

         

Code:

--

     

    void    
    forcedWireFrameModeOn( osg::Node *srcNode ){
    // ---------------------------------------------------------------------------
    //  Public  Function
    //  
    //   Force the Node and its children to be wireframe, overrides parents state
    //  
    // ---------------------------------------------------------------------------
     
    //
    // Quick sanity check , we need a node
    //
    if( srcNode == NULL )
        return;
     
    // --------------------------------------------------------------------------------
    //   Grab the state set of the node, this  will a StateSet if one does not exist
    // --------------------------------------------------------------------------------
    osg::StateSet *state = srcNode->getOrCreateStateSet();
     
    // ----------------------------------------------------------------------------------------------
    //   We need to retireve the Poylgon mode of the  state set, and create one if does not have one
    // ----------------------------------------------------------------------------------------------
    osg::PolygonMode *polyModeObj;
     
    polyModeObj = dynamic_cast< osg::PolygonMode* >
                                 ( state->getAttribute( osg::StateAttribute::POLYGONMODE ));
     
    if ( !polyModeObj ) {
       
        polyModeObj = new osg::PolygonMode;
     
        state->setAttribute( polyModeObj );    
       }
     
    // --------------------------------------------   
    //  Now we can set the state to WIREFRAME
    // --------------------------------------------   
     
    polyModeObj->setMode(  osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE );
     
     
    }  // forceWireFrameModeOn
     

     

 

     

* 49  * How to Disable wireFrame mode on a Node b

     

      You can force the Wireframe mode to be OFF(normal fill Mode) for a node and its children using something like the following

           

    Code:

    --

       

      void    
      forcedWireFrameModeOff( osg::Node *srcNode ){
      // ---------------------------------------------------------------------------
      //  Public  Function
      //  
      //   Force the Node and its children to be drawn filled, overrides parents state
      //  
      // ---------------------------------------------------------------------------
       
      //
      // Quick sanity check , we need a node
      //
      if( srcNode == NULL )
          return;
       
      // --------------------------------------------------------------------------------
      //   Grab the state set of the node, this  will a StateSet if one does not exist
      // --------------------------------------------------------------------------------
      osg::StateSet *state = srcNode->getOrCreateStateSet();
       
      // ----------------------------------------------------------------------------------------------
      //   We need to retireve the Poylgon mode of the  state set, and create one if does not have one
      // ----------------------------------------------------------------------------------------------
      osg::PolygonMode *polyModeObj;
       
      polyModeObj = dynamic_cast< osg::PolygonMode* >
                                   ( state->getAttribute( osg::StateAttribute::POLYGONMODE ));
       
      if ( !polyModeObj ) {
         
          polyModeObj = new osg::PolygonMode;
       
          state->setAttribute( polyModeObj );    
         }
       
      // --------------------------------------------   
      //  Now we can set the state to Filled
      // --------------------------------------------   
       
      polyModeObj->setMode(  osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::FILL );
       
       
      }  // forceWireFrameModeOff
       

       

     

     

* 50  *  Can I share a single HUD over Multiple Windowsb

     

    Q: I am using two windows  to display my scene,  I have a single HUD overlay ortho2D but the HUD overlay  is showing up duplicated in both windows.  How do I just get a single HUD  overlay that is spread over both windows

    Reply from OSG Mailing List:

    This is quite simple to fix.  In essence, you want the CULL traversal that occurs for the left camera to have one setting for the ortho2D matrix (e.g. 0, 1280, 0, 1024) and the CULL traversal that occurs in the right camera to  have a different ortho2D matrix (1280, 2560, 0, 1024).

    There are a couple of ways to handle this, one is to use a Cull callback on your Projection node, and set the ortho2D matrix depending on which traversal (left or right) calls the callback.

    You can also use a multi-path approach, which would place two projection nodes under one Group node.  Each projection node would then be given a node mask, and each Cull traversal a traversal mask (see the FAQ for code examples for this).  Both projection nodes would then share the rest of the HUD sub graph below them.  If I were implementing this, I'd take this approach.

    You could also use Producer::Camera's to do this.  Unfortunately, the only scene handler implemented for OSG is osgProducer::OsgSceneHandler, which enforces its own screen clears and disallows the sharing of Render Surfaces by multiple cameras without a series of complicated additions to the scene graph with Clear Nodes, etc. to override this.  Had OsgSceneHandler been implemented according to Producer's design, this would be trivial.

    Another approach to consider is possibly using  the new osg::CameraNode, placing one camera in the left camera's scene graph's root where the camera will be nested within the camera's scene graph camera node.  The right camera will then sit under the right camera scene graph as a camera node and would have a sub graph containing a camera nested within a camera.

 

 

 

 

 

Copyright 2003-2006 Gordon Tomlinson  All Rights Reserved.

All logos, trademarks and copyrights in this site are property of their respective owner.