OpenSceneGraph/FAQ

o API's feature set

   - scene graph based?
   
        The scene graph is arranged with geometry nodes (osg::Geode's) as leaf
        nodes and internal nodes such as osg::DCS's/Groups/LOD etc for position the 
        geometry objects within the scene and organizing scene behavior.
        
   - culling techniques?
   
        Currently view frustum culling, small feature culling, and OpenGL's
        native backface culling. The OSG has been designed so it can be 
        easily extended, so if you have a favored culling technique it 
        won't be difficult to utilize it in the OSG.
        
   - terrain / indoor support

        The osg::GeoSet encapsulates all the main OpenGL drawing primitive
        so its possible to represent pretty well anything you can with straight
        OpenGL including terrain and room objects and characters.  More 
        details below.
        
        However, if you wish to take advantage of specific optimization such 
        as adaptive meshing such as ROAM, or procedural culling such as when
        entering a room or when racing round a track then the OSG's could be
        easily extend to achieve this.  This is demonstrated in VTP Enviro
        which is is based on the OSG, extended osg::GeoSet to provide CLOD
        for terrain.
        
        These features are not currently on the todo list for version 1.0 as
        we intend to keep the OSG focused on the core scene graph. However,
        you're more than welcome to take on the challenge yourself.
   
   - etc, etc (the viz sim capabilities of it)
   
        Key features of OpenGL are encapsulated such as Points, Lines, Triangle
        and Quad Meshed primitives in osg::GeoSet, and Textures, Projected & 
        Environmental Textures, Transparency etc. in osg::GeoState. 
        
        The osgUtil::RenderVisitor currently implements the cull/draw traversal
        placing objects to be rendered in either a transparency bin or a 
        opaque bin. The transparent bin is depth sorting w.r.t to the eye point
        to ensure transparent objects appear correctly. The opaque bin
        is sorted w.r.t to their osg::GeoState to minimize OpenGL state changes
        to avoid cache misses in the rendering pipeline.
        
        osg::Billboards can be used for rendering trees, or even particle
        effects such a smoke, snow, explosions etc.


o What is the design philosophy behind the OSG.

    (An extract from an email from Don Burns beginnings of the OSG.)

    Thought I'd jot a couple of thoughts down regarding OSG.  A full 
    simulation package should really be made up of four parts:

        - Scene Graph
        - Traversers (App, Cull, Draw)
        - An MP harness
        - Channel configuration

    The Scene Graph is just that.  It manages a tree structure of different
    node types that allow management over the behavior of graphical
    objects.  The Traversers allow us to use the scene graph to render
    scenes in the most efficient manner, as well as providing maximum
    functionality for a real-time simulation.  The stages are (taken from
    the Performer approach) :

    App - This is the application part of the simulation that interfaces
    with the outside world, that is control devices, pilot input, animation
    engines, effects, event engines, etc, etc (there's much more).  This is
    also the stage that determines what the viewpoint is and consequently
    the viewing frustum.  App does a full traversal of the scene graph,
    calling callbacks that may be attached to nodes.

    Cull - This stage takes the information that has been updated by App
    (mainly the viewing frustum) and effects a cull of all objects, based on
    trivial accept or reject based on whether the bounds are contained in
    the viewing frustum or not.  Every node should have a bound associated
    with it reflecting the bounds of all children under it.  This way, Cull
    can quickly prune a large section of the scene graph, during traversal.
    It also implies that scene graphs should be organized spatially, such
    that groups of objects that are close to each other should also be close
    to each other on the scene graph.  During traversal, Cull gathers all
    leaf nodes that wind up being trivially accepted and creates a display
    list of geosets with their geostates.  These are then sorted by
    geostate, binning things like states that contain transparencies, and
    need to be sorted back to front and drawn last.  Cull can also perform
    accepts/rejects of geosets based on their bounding boxes.  Note that
    geosets have bounding boxes and geodes have bounding spheres.  This for
    efficiency.

    Cull also needs to gather nodes that would cause any glcommands, such as
    SCSs and DCSs which create transforms.

    Draw-  This does not traverse the scene graph, but rather, traverses the
    resultant display list produced by Cull.  Draw is to be as brain-dead as
    possible since it has the bulk of compute time reserved for actually
    drawing.  (Unless, of course you have the luxury of an SGI machine that
    does all transforms down in the graphics hardware... perhaps NV10 will
    help a bit on this end).

    The MP harness is a set of management routines for doing
    multiprocessing.  Ideally, you want to be able to run App, Cull and Draw
    as separate processes on their own dedicated processors.  Further, you
    want to run one complete Draw process for every graphics subsystem that
    you will be rendering to.  In our case, we can assume that most of our
    users will be on single processor PC's, in which case we stand to
    benefit from Cull's capability to prune the scene graph, but not much
    else.  However, this day and age four processor PC's are not that
    uncommon, and Linux does have pretty good support for this.

    The MP issues include, process (or thread) management and
    synchronization.  Performer has several MP models.  We also need to
    consider that this software will probably run on separate PCs
    altogether, so that the SGI concept of a single machine with multiple
    rendering pipes needs to be extended to include multiple PC's, which
    need to be synchronized across Ethernet or something.

    Note that each Draw process needs its own Cull process, but that there
    can be only one App for multiple Cull/Draw pairs.  This model might
    extend quite nicely to a multiple PC environment, in which each PC runs
    a Cull/Draw pair, and one central machine runs App, broadcasting the
    viewing frustum for each viewing channel and synchronizing all.

    Lastly, channel configuration.  Currently we now do this by opening a
    window, choosing a visual, size, etc.  It is often desirable to have
    multiple channels (or viewports) for one simulator.  There is a whole
    package of routines that can be written to set this up and initialize
    it.

    That all being said, as I write this my feeling is that we should limit
    the scope of OSG to that of only the first item above.  That is, Open
    Scene Graph will be a Scene Graph and nothing more.  Limiting the scope
    will allow us to concentrate on quality and robust functionality.  This
    is one of the best software steps that was taken during the design of
    OpenGL, in my opinion.  I recall Iris GL and all of its end-all, be-all
    approach, becoming very convoluted and confusing as it tried to be a
    windowing system, an input device interface, an imaging package and so
    forth.  Once the spec defined it as being a rendering API and nothing
    more, the picture got much clearer.

    Once OSG is in place and it becomes useful, we can then write the
    traversers, etc, but not limit our version of traversers.  My thinking
    is that we can publish examples and documents on How to Write an
    OSG Traverser, or  some such and sit back and watch the world develop
    the best.  This will also leave us flexible to use the OSG as a protocol
    for doing 3D on the web, or whatever.  We can write the viewers,
    traversers, MP harnesses, and channel config software as separate
    packages.

    Further, I think this will help in the acceptability of OSG as a good
    standard scene graph.  One of Performer's biggest weaknesses is that it
    is a huge API and the learning curve is so steep that many but the most
    hearty are put off by it.  We can make the Scene Graph that anyone can
    use.


o Would the OSG be a good candidate for terrain visualization.

    Terrain is one of the great candidates for scene graphs.  Two management
    schemes will help you out : Level Of Detail management and Visibility
    Culling.

    LOD management consists of defining your visual database (including your
    terrain) with differing levels of detail.  The further away you are the
    less detail your terrain needs to have and you can cut down on the amount
    of polygons required to render it.

    You can also do this with objects in your scene.  For example from 10
    meters, you'd like a barn to have all the details present, but from 1000
    meters, you could probably get away with the lack of the silo, windows and
    detail around the doors.  From 10000 meters it could just as easily be a
    square red box and at 15000 meters it might as well not be there since
    its representation may be less than a pixel on the screen.

    Visibility Culling is also important to high performance rendering,
    especially if your visual database is large.  All nodes on the scene graph
    have a bounding sphere.   Each parent node has a bounding sphere that
    encompasses all of its children.  The Cull process traverses the scene
    graph and tests each node for whether any part of it is in the current
    viewing frustum.  If not it throws it away.

    With this in mind, you can arrange your database  to make best use of
    culling.  For example, if you have a lot of trees on your terrain.  Rather
    than having one Group node that contains all trees (in which case Cull
    would have to  test every tree for visibility), you arrange your trees in
    a hierarchical fashion, such that trees are group by geographical
    location.  Then neighboring groups of trees can be parented together,
    groups of groups can be parented together and so forth.  This way Cull can
    visit a high level node,  determine that none of the trees under it are
    visible and proceed to test the rest of the scene graph.

    This also works for terrain.  Rather than defining one large piece of
    terrain, you should break it up into smaller sections.  This way, what is
    not in the viewing frustum can be discarded and the rendering pipeline
    left unbothered by transforming and clipping polygons that would never
    appear anyway.

    One of the goals of OSG is to be, again, "Just a scene graph".  Which
    means that the Cull traversal would not be included as part of the
    software.  It would be up to the user to provide that, OR, we can add it
    as a separate piece outside of the scene graph.  We want users to not be
    limited to what WE think might be the best cull traversal, but rather
    leave it as an exercise to optimize, be creative and/or create specific
    cull/draw traversals that best suit your needs.

    One such traversal I can think of is a game in which you are on a track.
    At any point on this track you can know exactly what is in view and what
    is not.  You could do something much more creative with this if you are
    not limited to the implementation "hard coded" in the scene graph
    software.

o What are the intended target platforms?

    Any platform which supports OpenGL and Standard C++!
    
    The real limit being the platforms available to the core developers,
    if you have a platform which you need supported and have some time
    to contribute please contact us.


o What platforms are currently supported?

    The OSG is currently developed under Windows95, Linux,Irix and MacOS. Platform
    specific makedefs are provided for Linux and Irix, and VisualC++ 6.0
    Workspace files for MS Windows platforms.
    
    The OSG also compiles under Windows98/NT and 2000.


o What further platforms will be supported in the near future?

    We will be developing autoconf makefiles to assist the porting to
    other Unix's as well as improving things on Linux and Irix.  


o I'm wondering when the OSG will be ready for release.

    An alpha version has been available since May 2000.  The current
    version is very much a work in progress will the API still in flux.
    
    Once the design converges to a stable API we will issue it as a beta,
    depending on the various factors one would hope to have the API nailed
    down during early-mid 2001.
    
    A full release with stable API and implementation will be available...
    Can't set any dates but we can be sure it'll be after then beta release :-)
    

o What are the dependencies of the OSG?

    Kept to a minimum by design.  The osg scene graph library simply requires OpenGL/Mesa
    and compiler support for Standard C++.  This means that there is not platform specific
    depedancies, and should allow the OSG to be ported easily to new platforms.
    
    The scene graph viewer sgv depends upon the osg library and GLUT, so should be portable
    to any platform which GLUT can be ported to. The viewer can also be compiled with FLTK
    using its GLUT compatibility code.


o Do you think Open Scene Graph could be a nice replacement for Inventor?

    Depends what your want from your scene graph.  If you primary interest
    is a visual simulation application then the performance emphasis of the
    OSG will be appropriate, if you want to develop a modeling 
    application and wish to take advantage out of the box UI tools then 
    Inventor may be better. 


o What differentiation between the OSG and other OS projects such as OpenRM/
  SGL/OpenSG/DDG Toolkit?
  
    I have briefly looked both the SGL, DDG and the OpenSG. Both the SGL 
    are the OpenSG show some uncanny similarities with the OSG, especially 
    since they all were developed independently. The influence of sgi's Performer,
    Inventor and Cosmo3D more than likely providing the starting place for designing
    each of these scene graphs.  DDG doesn't show quite the same heritage,
    and possibly loses a little cleanness of design with it.  OpenRM is
    an attempt at a Object Orientated scene graph but it C... This is 
    about a close as I got with it, as IMHO C++ really is currently the best
    language for a modern scene graph

    The OSG is also strongly influenced by Performer, this a due to the
    application which the OSG was first developed for : a Hang Gliding
    Flight simulator which can use either Performer or the OSG for its
    scene graph.  The OSG does not try to implement the whole of Performer
    though, just concentrating of the scene graph to keep the scope in
    manageable proportions.  The need for the OSG comes about because
    Performer is only available on Irix with Linux only happening very
    recently, and Performer is closed source of course.  

    The OSG also takes advantage of the features of Standard C++ and Design 
    Patterns to help make the library cleaner and improve its extensibility. 

    Many of the current scene graphs, including Inventor and its clones, don't
    use STL so end up having define their own container and many common 
    algorithms. We're glad to say that Standard C++ compilers are now
    common enough that we don't have to descend the lowest common denominator
    like many older scene graphs.

    The OpenSG design document looks like it describes a very powerful
    scene graph design, taking on almost all what Performer tackles today.
    However, this will mean that it will be big, and like the Inventor clones
    will take *alot* of work to fully implement.  If you need all the features
    then the OpenSG may well be worth the wait.  If you need less features then
    the more humble goals of the OSG may well be right for you. 
    

o Is there a class diagram for the OSG, or white paper on the projects goals?

    The documentation in the distribution has been generated automatically
    using the excellent Open Source tool doc++, which creates class diagrams.
    UML diagrams have been generated and can be found in the documentation
    directory, along with mind maps on design patterns used in the osg,
    and the mission/goals of the osg.
    
    We haven't written an official white paper on projects goals or a design
    overview yet.  Knowledge of Performer will help in understanding some of the basics
    of design, as will a familiarity with Design Patterns.  
    

o Do you need C++ coding support? 

    Yes, indeed! Check out the TODO list which comes with the distribution,
    and email us with what you fancy contributing to.

        
o Any recommendations for useful programming books to read to help understand
  and contribute to the OSG? 

    Good practices are surprisingly hard to come by. C and C++ give you so
    much rope to hang yourself, but there's few books which really give a
    developers the rule book of good coding practices.  I found Effective
    C++ a refreshing contribution to this end.  The Design Patterns book can
    be pretty useful as well.  


o Is there a mailing list?

    Yes indeed, hosted by source forge, so to subscribe head to :
    http://sourceforge.net/projects/openscenegraph and follow the
    'Lists' link and follow the instructions.

o How do I submit my contributions?

    We will eventually be setting up CVS access, possibly with SourceForge.
    Up till then send your changes, to <robert@openscenegraph.org>