.TH "SoLevelOfDetail" 3 "Sat Oct 12 2013" "Version 4.0.0a" "Coin" \" -*- nroff -*-
.ad l
.nh
.SH NAME
SoLevelOfDetail \- 
.PP
The \fBSoLevelOfDetail\fP class is used to choose a child based on projected size\&.
.PP
A level-of-detail mechanism is typically used by application programmers to assist the library in speeding up the rendering\&.  

.SH SYNOPSIS
.br
.PP
.PP
\fC#include <Inventor/nodes/SoLevelOfDetail\&.h>\fP
.PP
Inherits \fBSoGroup\fP\&.
.SS "Public Member Functions"

.in +1c
.ti -1c
.RI "virtual \fBSoType\fP \fBgetTypeId\fP (void) const "
.br
.RI "\fIReturns the type identification of an object derived from a class inheriting \fBSoBase\fP\&. This is used for run-time type checking and 'downward' casting\&. \fP"
.ti -1c
.RI "\fBSoLevelOfDetail\fP (void)"
.br
.ti -1c
.RI "\fBSoLevelOfDetail\fP (int numchildren)"
.br
.ti -1c
.RI "virtual void \fBdoAction\fP (\fBSoAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBcallback\fP (\fBSoCallbackAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBGLRender\fP (\fBSoGLRenderAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBrayPick\fP (\fBSoRayPickAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBgetBoundingBox\fP (\fBSoGetBoundingBoxAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBaudioRender\fP (\fBSoAudioRenderAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBnotify\fP (\fBSoNotList\fP *nl)"
.br
.in -1c
.SS "Static Public Member Functions"

.in +1c
.ti -1c
.RI "static \fBSoType\fP \fBgetClassTypeId\fP (void)"
.br
.RI "\fIThis static method returns the \fBSoType\fP object associated with objects of this class\&. \fP"
.ti -1c
.RI "static void \fBinitClass\fP (void)"
.br
.RI "\fISets up initialization for data common to all instances of this class, like submitting necessary information to the Coin type system\&. \fP"
.in -1c
.SS "Public Attributes"

.in +1c
.ti -1c
.RI "\fBSoMFFloat\fP \fBscreenArea\fP"
.br
.in -1c
.SS "Protected Member Functions"

.in +1c
.ti -1c
.RI "virtual const \fBSoFieldData\fP * \fBgetFieldData\fP (void) const "
.br
.ti -1c
.RI "virtual \fB~SoLevelOfDetail\fP ()"
.br
.in -1c
.SS "Static Protected Member Functions"

.in +1c
.ti -1c
.RI "static const \fBSoFieldData\fP ** \fBgetFieldDataPtr\fP (void)"
.br
.in -1c
.SS "Additional Inherited Members"
.SH "Detailed Description"
.PP 
The \fBSoLevelOfDetail\fP class is used to choose a child based on projected size\&.
.PP
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:
.PP
Several versions of varying complexity of \fIthe\fP \fIsame\fP 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)\&.
.PP
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\&.
.PP
This is under many different circumstances a very effective way to let the application programmer assist to \fIprofoundly\fP optimize the rendering of her 3D-scene\&.
.PP
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\&.
.PP
The \fBSoLevelOfDetail\fP node implements the 'projected size' variety level-of-detail technique (as opposed to the 'object distance' technique, as done by the \fBSoLOD\fP node)\&.
.PP
The node works by comparing the current projected size of the smallest rectangle covering the bounding box of it's child geometry\&.
.PP
Along with this set of models of the same shape, a specification of when to switch between them is also provided\&.
.PP
Example scenegraph layout:
.PP
.PP
.nf
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
   }
}
.fi
.PP
.PP
The way the above sub-scenegraph would work would be the following: if the rectangular area around the model's projected bounding box covers \fImore\fP than 2000 pixels (meaning it will be up pretty close to the camera), the most complex version of the model (\fCversion-0\fP) would be traversed (and rendered, of course)\&. If the projected area would be \fIbetween\fP 500 and 2000 pixels, the \fCversion-1\fP model would be used\&. Ditto if the projected area was between 50 and 500 pixels, the \fCversion-2\fP version of the model would be used\&. Finally, if the projected bounding box area would be \fIless\fP than 50 square pixels, the presumably least detailed version of the modeled would be used\&.
.PP
(A common 'trick' is to let the last of the \fBSoLevelOfDetail\fP 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\&.)
.PP
Note that the \fBSoLevelOfDetail::screenArea\fP vector will be influenced by preceding \fBSoComplexity\fP nodes in the following way: if \fBSoComplexity::value\fP is set from 0\&.0 up to 0\&.5, lower detail levels than normal will be selected for traversal\&. If \fBSoComplexity::value\fP is above 0\&.5, higher level details than normal will be used\&. An \fBSoComplexity::value\fP equal to 1\&.0 will cause the first child of \fBSoLevelOfDetail\fP to always be used\&.
.PP
As mentioned above, there is one other level-of-detail node in the Coin library: \fBSoLOD\fP\&. The difference between that one and this is just that instead of projected bounding box area, \fBSoLOD\fP uses the distance between the camera and the object to find out when to switch between the different model versions\&.
.PP
Using \fBSoLOD\fP is faster, since figuring out the projected bounding box area needs a certain amount of calculations\&. But using \fBSoLevelOfDetail\fP 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\&.
.PP
\fBFILE FORMAT/DEFAULTS:\fP 
.PP
.nf
LevelOfDetail {
    screenArea 0
}

.fi
.PP
.PP
\fBSee Also:\fP
.RS 4
\fBSoLOD\fP 
.RE
.PP

.SH "Constructor & Destructor Documentation"
.PP 
.SS "SoLevelOfDetail::SoLevelOfDetail (void)"
Default constructor\&. 
.SS "SoLevelOfDetail::SoLevelOfDetail (intnumchildren)"
Constructor\&.
.PP
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\&. 
.SS "SoLevelOfDetail::~SoLevelOfDetail ()\fC [protected]\fP, \fC [virtual]\fP"
Destructor\&. 
.SH "Member Function Documentation"
.PP 
.SS "\fBSoType\fP SoLevelOfDetail::getTypeId (void) const\fC [virtual]\fP"

.PP
Returns the type identification of an object derived from a class inheriting \fBSoBase\fP\&. This is used for run-time type checking and 'downward' casting\&. Usage example:
.PP
.PP
.nf
void foo(SoNode * node)
{
  if (node->getTypeId() == SoFile::getClassTypeId()) {
    SoFile * filenode = (SoFile *)node;  // safe downward cast, knows the type
  }
}
.fi
.PP
.PP
For application programmers wanting to extend the library with new nodes, engines, nodekits, draggers or others: this method needs to be overridden in \fIall\fP subclasses\&. This is typically done as part of setting up the full type system for extension classes, which is usually accomplished by using the pre-defined macros available through for instance \fBInventor/nodes/SoSubNode\&.h\fP (SO_NODE_INIT_CLASS and SO_NODE_CONSTRUCTOR for node classes), Inventor/engines/SoSubEngine\&.h (for engine classes) and so on\&.
.PP
For more information on writing Coin extensions, see the class documentation of the toplevel superclasses for the various class groups\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "const \fBSoFieldData\fP ** SoLevelOfDetail::getFieldDataPtr (void)\fC [static]\fP, \fC [protected]\fP"
\fIThis API member is considered internal to the library, as it is not likely to be of interest to the application programmer\&.\fP 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "const \fBSoFieldData\fP * SoLevelOfDetail::getFieldData (void) const\fC [protected]\fP, \fC [virtual]\fP"
Returns a pointer to the class-wide field data storage object for this instance\&. If no fields are present, returns \fCNULL\fP\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::doAction (\fBSoAction\fP *action)\fC [virtual]\fP"
This function performs the typical operation of a node for any action\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::callback (\fBSoCallbackAction\fP *action)\fC [virtual]\fP"
Action method for \fBSoCallbackAction\fP\&.
.PP
Simply updates the state according to how the node behaves for the render action, so the application programmer can use the \fBSoCallbackAction\fP for extracting information about the scene graph\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::GLRender (\fBSoGLRenderAction\fP *action)\fC [virtual]\fP"
Action method for the \fBSoGLRenderAction\fP\&.
.PP
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\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::rayPick (\fBSoRayPickAction\fP *action)\fC [virtual]\fP"
Action method for \fBSoRayPickAction\fP\&.
.PP
Checks the ray specification of the \fIaction\fP and tests for intersection with the data of the node\&.
.PP
Nodes influencing relevant state variables for how picking is done also overrides this method\&. 
.PP
Reimplemented from \fBSoNode\fP\&.
.SS "void SoLevelOfDetail::getBoundingBox (\fBSoGetBoundingBoxAction\fP *action)\fC [virtual]\fP"
Action method for the \fBSoGetBoundingBoxAction\fP\&.
.PP
Calculates bounding box and center coordinates for node and modifies the values of the \fIaction\fP to encompass the bounding box for this node and to shift the center point for the scene more towards the one for this node\&.
.PP
Nodes influencing how geometry nodes calculates their bounding box also overrides this method to change the relevant state variables\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::audioRender (\fBSoAudioRenderAction\fP *action)\fC [virtual]\fP"
Action method for \fBSoAudioRenderAction\fP\&.
.PP
Does common processing for \fBSoAudioRenderAction\fP \fIaction\fP instances\&. 
.PP
Reimplemented from \fBSoGroup\fP\&.
.SS "void SoLevelOfDetail::notify (\fBSoNotList\fP *l)\fC [virtual]\fP"
Notifies all auditors for this instance when changes are made\&. 
.PP
Reimplemented from \fBSoNode\fP\&.
.SH "Member Data Documentation"
.PP 
.SS "\fBSoMFFloat\fP SoLevelOfDetail::screenArea"
The screen area limits for the children\&. See usage example in main class documentation of \fBSoLevelOfDetail\fP for an explanation of how this vector should be set up correctly\&.
.PP
By default this vector just contains a single value 0\&.0f\&. 

.SH "Author"
.PP 
Generated automatically by Doxygen for Coin from the source code\&.