Provided by: libcoin60-doc_3.1.3-2_all bug

NAME

       SoLevelOfDetail -

       The SoLevelOfDetail class is used to choose a child based on projected size.

       A level-of-detail mechanism is typically used by application programmers to assist the
       library in speeding up the rendering.

SYNOPSIS

       #include <Inventor/nodes/SoLevelOfDetail.h>

       Inherits SoGroup.

   Public Member Functions
       SoLevelOfDetail (void)
       SoLevelOfDetail (int numchildren)
       virtual void doAction (SoAction *action)
       virtual void callback (SoCallbackAction *action)
       virtual void GLRender (SoGLRenderAction *action)
       virtual void rayPick (SoRayPickAction *action)
       virtual void getBoundingBox (SoGetBoundingBoxAction *action)
       virtual void audioRender (SoAudioRenderAction *action)
       virtual void notify (SoNotList *nl)

   Static Public Member Functions
       static void initClass (void)

   Public Attributes
       SoMFFloat screenArea

   Protected Member Functions
       virtual ~SoLevelOfDetail ()

Detailed Description

       The SoLevelOfDetail class is used to choose a child based on projected size.

       A level-of-detail mechanism is typically used by application programmers to assist the
       library in speeding up the rendering.

       The way a level-of-detail mechanism works is basically like this:

       Several versions of varying complexity of the same geometry / shape is provided by the
       application programmer in sorted order from 'most complex' to 'least complex' (where
       'complex' in this context should be taken to mean more or less detailed in the number of
       polygons / shapes used for rendering it).

       The run-time rendering system then, upon scenegraph traversal, will on-the-fly calculate
       either the distance from the camera to the 3D-model in question, or the number of pixels
       in the screen projection of the 3D-model. This value is then used to decide which version
       of the model to actually render: as the model is moved farther away from the camera, a
       less detailed version of the model is used. And vice versa, as the model moves closer to
       the camera, more and more detailed versions of it are rendered.

       This is under many different circumstances a very effective way to let the application
       programmer assist to profoundly optimize the rendering of her 3D-scene.

       There is of course a trade-off with the level-of-detail technique: more versions of the
       same 3D model means the scenegraph will use up more application memory resources. Also,
       generating the set of less and less detailed versions of a 3D model from the original is
       often not a trivial task to do properly. The process is often assisted by software like
       what Kongsberg Oil & Gas Technologies offers in their <a href="http://www.rational-
       reducer.com>Rational Reducer package.

       The SoLevelOfDetail node implements the 'projected size' variety level-of-detail technique
       (as opposed to the 'object distance' technique, as done by the SoLOD node).

       The node works by comparing the current projected size of the smallest rectangle covering
       the bounding box of it's child geometry.

       Along with this set of models of the same shape, a specification of when to switch between
       them is also provided.

       Example scenegraph layout:

         LevelOfDetail {
            screenArea [ 2000, 500, 50 ]

            DEF version-0 Separator {
              # most complex / detailed / heavy version of subgraph
            }
            DEF version-1 Separator {
              # less complex version of subgraph
            }
            DEF version-2 Separator {
              # even less complex version of subgraph
            }
            DEF version-3 Separator {
              # simplest / 'lightest' version of subgraph
            }
         }

       The way the above sub-scenegraph would work would be the following: if the rectangular
       area around the model's projected bounding box covers more than 2000 pixels (meaning it
       will be up pretty close to the camera), the most complex version of the model (version-0)
       would be traversed (and rendered, of course). If the projected area would be between 500
       and 2000 pixels, the version-1 model would be used. Ditto if the projected area was
       between 50 and 500 pixels, the version-2 version of the model would be used. Finally, if
       the projected bounding box area would be less than 50 square pixels, the presumably least
       detailed version of the modeled would be used.

       (A common 'trick' is to let the last of the SoLevelOfDetail node's children be just an
       empty subgraph, so no geometry will be rendered at all if the model is sufficiently far
       away. This will of course have a positive effect on the total rendering time for the
       complete scenegraph.)

       Note that the SoLevelOfDetail::screenArea vector will be influenced by preceding
       SoComplexity nodes in the following way: if SoComplexity::value is set from 0.0 up to 0.5,
       lower detail levels than normal will be selected for traversal. If SoComplexity::value is
       above 0.5, higher level details than normal will be used. An SoComplexity::value equal to
       1.0 will cause the first child of SoLevelOfDetail to always be used.

       As mentioned above, there is one other level-of-detail node in the Coin library: SoLOD.
       The difference between that one and this is just that instead of projected bounding box
       area, SoLOD uses the distance between the camera and the object to find out when to switch
       between the different model versions.

       Using SoLOD is faster, since figuring out the projected bounding box area needs a certain
       amount of calculations. But using SoLevelOfDetail is often 'better', in the sense that
       it's really a model's size and visibility in the viewport that determines whether we could
       switch to a less complex version without losing enough detail that it gives a noticable
       visual degradation.

       FILE FORMAT/DEFAULTS:

           LevelOfDetail {
               screenArea 0
           }

       See also:
           SoLOD

Constructor & Destructor Documentation

   SoLevelOfDetail::SoLevelOfDetail (void) Default constructor.
   SoLevelOfDetail::SoLevelOfDetail (intnumchildren) Constructor.
       The argument should be the approximate number of children which is expected to be inserted
       below this node. The number need not be exact, as it is only used as a hint for better
       memory resource allocation.

   SoLevelOfDetail::~SoLevelOfDetail () [protected, virtual] Destructor.

Member Function Documentation

   void SoLevelOfDetail::initClass (void) [static] Sets up initialization for data common to all
       instances of this class, like submitting necessary information to the Coin type system.
       Reimplemented from SoGroup.

   void SoLevelOfDetail::doAction (SoAction *action) [virtual] This function performs the typical
       operation of a node for any action.
       Reimplemented from SoGroup.

   void SoLevelOfDetail::callback (SoCallbackAction *action) [virtual] Action method for
       SoCallbackAction.
       Simply updates the state according to how the node behaves for the render action, so the
       application programmer can use the SoCallbackAction for extracting information about the
       scene graph.

       Reimplemented from SoGroup.

   void SoLevelOfDetail::GLRender (SoGLRenderAction *action) [virtual] Action method for the
       SoGLRenderAction.
       This is called during rendering traversals. Nodes influencing the rendering state in any
       way or who wants to throw geometry primitives at OpenGL overrides this method.

       Reimplemented from SoGroup.

   void SoLevelOfDetail::rayPick (SoRayPickAction *action) [virtual] Action method for
       SoRayPickAction.
       Checks the ray specification of the action and tests for intersection with the data of the
       node.

       Nodes influencing relevant state variables for how picking is done also overrides this
       method.

       Reimplemented from SoNode.

   void SoLevelOfDetail::getBoundingBox (SoGetBoundingBoxAction *action) [virtual] Action method
       for the SoGetBoundingBoxAction.
       Calculates bounding box and center coordinates for node and modifies the values of the
       action to encompass the bounding box for this node and to shift the center point for the
       scene more towards the one for this node.

       Nodes influencing how geometry nodes calculates their bounding box also overrides this
       method to change the relevant state variables.

       Reimplemented from SoGroup.

   void SoLevelOfDetail::audioRender (SoAudioRenderAction *action) [virtual] Action method for
       SoAudioRenderAction.
       Does common processing for SoAudioRenderAction action instances.

       Reimplemented from SoGroup.

   void SoLevelOfDetail::notify (SoNotList *l) [virtual] Notifies all auditors for this instance
       when changes are made.
       Reimplemented from SoNode.

Member Data Documentation

   SoMFFloat SoLevelOfDetail::screenArea The screen area limits for the children. See usage
       example in main class documentation of SoLevelOfDetail for an explanation of how this
       vector should be set up correctly.
       By default this vector just contains a single value 0.0f.

Author

       Generated automatically by Doxygen for Coin from the source code.