Class SoCallback
- java.lang.Object
-
- com.openinventor.inventor.Inventor
-
- com.openinventor.inventor.misc.SoBase
-
- com.openinventor.inventor.fields.SoFieldContainer
-
- com.openinventor.inventor.nodes.SoNode
-
- com.openinventor.inventor.nodes.SoCallback
-
- All Implemented Interfaces:
SafeDisposable
- Direct Known Subclasses:
SoGLCallback
public class SoCallback extends SoNode
Provides custom behavior during actions. This node provides a general mechanism for executing some code during an Open Inventor scene graph traversal, i.e. when an action is applied to the scene graph.In some cases, implementing a new node class (a so-called custom node) derived from one of the existing classes is the best and cleanest solution. But for simple cases, and for prototyping, an
SoCallback
node may solve the problem.You can use this node to get values from the traversal state list using the
SoElement
classes and, conversely, to modify values in the traversal state list. For example,SoLineWidthElement
contains the current line width and is normally set by anSoDrawStyle
node.This node cannot be used to make OpenGL calls. OpenGL calls can only be made using an
SoGLCallback
node. (This is a change starting with Open Inventor 10.0)This node cannot be used to modify the structure of the scene graph. This may cause a crash. This node should not be used to modify fields in other nodes. The same effect can usually be obtained by setting the corresponding 'element'. See the Cautions section below for more details.
Create the node:
SoCallback callbackNode = new SoCallback(); callbackNode.setCallback( new myCallback() ); root.addChild( callbackNode ); SoGLRenderAction
,SoHandleEventAction
,SoRayPickAction
,SoGetBoundingBoxAction
,SoSearchAction
andSoCallbackAction
. You should consider which actions the function should, or should not, be executed for. In the callback you can check the action type, for example:class myCallback implements SoCallback.CB { @Override public void invoke( SoAction action ) { // Only handle specific actions if (action instanceof SoGLRenderAction) { // Call to OpenInventor functions } } } SoCallback callbackNode = new SoCallback(); callbackNode.setCallback( new SoCallback.CB() { @Override public void invoke( SoAction action ) { // Only handle specific actions if (action instanceof SoGLRenderAction) { // Call to OpenInventor functions } } } ); SoLineWidthElement
, generally should do that for all actions.Getting a value from the traversal state list requires access to the
SoState
object for the current traversal. This information (and more) is available from theSoAction
object passed to the callback. Modifying a value in the traversal state list requires theSoState
object and, in most cases, a reference to the node setting the element. This information is also available from theSoAction
object as the "tail" node of the action's current path, which is updated for each node visited as the action traverses the scene graph. Getting and modifying the traversal state is shown in the next example. The goal is to highlight some line geometry by making the lines 3X wider than whatever the current line width is. We get the current line width from the traversal state, multiply by three, then set the new line width in the state.class myCallback implements SoCallback.CB { @Override public void invoke( SoAction action ) { // Traversal state SoState state = action.getState(); // Get line width from traversal state float lineWidth = SoLineWidthElement.get( state ); // Scale up line width (may be zero) lineWidth = (lineWidth > 0) ? (3 * lineWidth) : 3; // Set new value in state SoLineWidthElement.set( state, action.getCurPath().getTail(), lineWidth ); } } Most actions do a straightforward 'depth first' traversal of the scene graph. In other words, nodes are visited exactly as organized in the scene graph. But
SoGLRenderAction
's traversal of the scene graph for rendering is much more complex. The 'behavior' implied by the structure of the scene graph is always respected. For example nodes inherit traversal state from above/left andSoSeparator
nodes save and restore traversal state. However you cannot assume that there is a single traversal that exactly follows the structure of the scene graph. For example, some parts of the scene graph may be traversed 'out of order' to simulate transparency correctly and the scene graph may be traversed multiple times to implement rendering effects like shadows. Because of this, there are some limitations on what can be done in the callback function.- Do NOT change the "structure" of the scene graph (insert or remove nodes).
This may cause Open Inventor to crash. If such a change is required, schedule anSoOneShotSensor
and do the work in the sensor's callback function. This function will be called at a safe time when no traversal is being done and the change will take effect on the next traversal. - Avoid changing fields of other nodes.
This causes notification, which is inefficient during traversal and may cause sensors to trigger with undesired results. Also, some fields, if changed, invalidate information that is cached during traversal and may result in incorrect rendering.
Think about whether it is really necessary to make this change during the render traversal. If your callback is responding to a change in the traversal state, then it may be possible (and generally is safer) to use the "Observer" pattern and attach anSoNodeSensor
orSoFieldSensor
to the node or field of interest. For example, attach anSoFieldSensor
to the position field of the camera (see the viewer's getCamera() method) to make decisions based on the distance from the camera to some geometry.
Whenever possible, make changes to attributes and properties by setting elements in the traversal state list instead of changing field values. For example, line width can (and should) be changed by setting theSoLineWidthElement
. You can even control which child of anSoSwitch
node is traversed, using theSoSwitchElement
. See the "Action Behavior" section of each property node's documentation to see which elements it uses.
If it is necessary to change a field based on information obtained during traversal, the best solution is to use anSoOneShotSensor
as described in the previous point. The next best solution is to temporarily disable notification on the node that contains the field (seeSoNode.enableNotify()
). - In general you should not use an
SoCallback
node to count the number of "frames" rendered. You're really counting the number of render traversals and the scene graph may be traversed multiple times to render a single frame. During a render traversal you can get the actual frame count by calling theSoGLRenderAction
method getFrameCounter(). See the example code for how to determine if the current action is a render action.
Render caching:
One of the most important and most effective optimizations in Open Inventor is automatic building of 'render caches' (mainly at
SoSeparator
nodes) for 'static' parts of the scene graph. A render cache encapsulates geometry and state (attributes and properties) that can be rendered without scene graph traversal. One advantage is that geometry in a render cache can be optimized for best performance. Another important advantage is that when anSoSeparator
has a valid render cache, Open Inventor does not need to traverse its children, avoiding the CPU time to traverse those nodes. In general you should try to ensure that yourSoCallback
node can be render cached. In most casesSoCallback
nodes can be cached even if they access/set traversal state.If the callback modifies the Open Inventor traversal state based on information from other nodes in the scene graph, then you may be able to get that information from the
SoElement
object(s) set by those nodes. See the line width example above. In that case theSoCallback
node can be part of a render cache, because Open Inventor remembers that the render cache has a dependency on the specific value of the element(s) whose 'get' method was called. On subsequent traversals, if the element's value matches the saved value, then the render cache is still valid and be used. If the element's value has changed, then the render cache is automatically discarded and theSoSeparator
's children are traversed, so theSoCallback
node's callback will be called again. On later traversals, if the value of the element is no longer changing, Open Inventor will eventually rebuild the render cache. The line width example above can be safely render cached.In a few cases, the callback node may not be cacheable, depending on what it does. If a callback node relies on any information outside of Inventor that may change (such as a global application variable), it should not be cached, because the callback function will not be executed when the render cache is valid (
SoCallback
will not be traversed). We can imagine other cases where the callback function must be executed on every traversal. For example a temporary callback that prints a debug message on every traversal. To prevent Inventor from automatically creating a cache, call theSoCacheElement
's invalidate() method in the callback function. But keep in mind that when you do this, it prevents caching by the callback node's parent and that node's parent and everySoSeparator
up to the top of the scene graph. To minimize the performance hit, try to only put non-cacheable nodes near the top of the scene graph. Here is a non-cacheable callback:class myCallback implements SoCallback.CB { @Override public void invoke( SoAction action ) { // Only handle specific actions if (action instanceof SoGLRenderAction) { // Traversal state SoState state = action.getState(); // This node must not be render cached (must be executed). SoCacheElement.invalidate( state ); System.out.printf( "Render traversal: %d%n", m_counter++ ); } } } File format/default:
Callback {
Action behavior:
SoGLRenderAction
,SoGetBoundingBoxAction
,SoPickAction
Calls the specified callback for all actions.- See Also:
SoAction
,SoCallbackAction
,SoEventCallback
,SoGLCallback
-
-
Nested Class Summary
Nested Classes Modifier and Type Class Description static interface
SoCallback.CB
-
Nested classes/interfaces inherited from class com.openinventor.inventor.nodes.SoNode
SoNode.RenderModes
-
Nested classes/interfaces inherited from class com.openinventor.inventor.Inventor
Inventor.ConstructorCommand
-
-
Field Summary
-
Fields inherited from class com.openinventor.inventor.Inventor
VERBOSE_LEVEL, ZeroHandle
-
-
Constructor Summary
Constructors Constructor Description SoCallback()
Creates a callback node with default settings.
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description void
setCallback(SoCallback.CB cb)
Defines the CB object that will be invoked each time this nodes is traversed by an action.-
Methods inherited from class com.openinventor.inventor.nodes.SoNode
affectsState, callback, copy, copy, distribute, doAction, getAlternateRep, getBoundingBox, getByName, getMatrix, getPrimitiveCount, getRenderEngineMode, getRenderUnitID, GLRender, GLRenderBelowPath, GLRenderInPath, GLRenderOffPath, grabEventsCleanup, grabEventsSetup, handleEvent, isBoundingBoxIgnoring, isOverride, pick, rayPick, search, setOverride, touch, write
-
Methods inherited from class com.openinventor.inventor.fields.SoFieldContainer
copyFieldValues, copyFieldValues, enableNotify, fieldsAreEqual, get, getAllFields, getEventIn, getEventOut, getField, getFieldName, hasDefaultValues, isNotifyEnabled, set, setToDefaults
-
Methods inherited from class com.openinventor.inventor.misc.SoBase
dispose, getName, isDisposable, isSynchronizable, setName, setSynchronizable
-
Methods inherited from class com.openinventor.inventor.Inventor
getNativeResourceHandle
-
-
-
-
Method Detail
-
setCallback
public void setCallback(SoCallback.CB cb)
Defines the CB object that will be invoked each time this nodes is traversed by an action.
-
-