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 (int numchildren) 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.