initialization method, called once when the behavior becomes "live," and a processStimulus method called whenever appropriate by the Java 3D behavior scheduler. The Behavior node also contains an enable flag, a scheduling region, a scheduling interval, and a wakeup condition. The scheduling region defines a spatial volume that serves to enable the scheduling of Behavior nodes. A Behavior node is active (can receive stimuli) whenever an active ViewPlatform's activation volume intersects a Behavior object's scheduling region. Only active behaviors can receive stimuli.
The scheduling interval defines a partial order of execution for behaviors that wake up in response to the same wakeup condition (that is, those behaviors that are processed at the same "time"). Given a set of behaviors whose wakeup conditions are satisfied at the same time, the behavior scheduler will execute all behaviors in a lower scheduling interval before executing any behavior in a higher scheduling interval. Within a scheduling interval, behaviors can be executed in any order, or in parallel. Note that this partial ordering is only guaranteed for those behaviors that wake up at the same time in response to the same wakeup condition, for example, the set of behaviors that wake up every frame in response to a WakeupOnElapsedFrames(0) wakeup condition.
The initialize method allows a Behavior object to initialize its internal state and specify its initial wakeup condition(s). Java 3D invokes a behavior's initialize code when the behavior's containing BranchGroup node is added to the virtual universe. Java 3D does not invoke the initialize method in a new thread. Thus, for Java 3D to regain control, the initialize method must not execute an infinite loop; it must return. Furthermore, a wakeup condition must be set or else the behavior's processStimulus method is never executed.
The processStimulus method receives and processes a behavior's ongoing messages. The Java 3D behavior scheduler invokes a Behavior node's processStimulus method when an active ViewPlatform's activation volume intersects a Behavior object's scheduling region and all of that behavior's wakeup criteria are satisfied. The processStimulus method performs its computations and actions (possibly including the registration of state change information that could cause Java 3D to wake other Behavior objects), establishes its next wakeup condition, and finally exits. A typical behavior will modify one or more nodes or node components in the scene graph. These modifications can happen in parallel with rendering. In general, applications cannot count on behavior execution being synchronized with rendering. There are two exceptions to this general rule:
processStimulus method of a single behavior instance are guaranteed to take effect in the same rendering frame.processStimulus methods of the set of behaviors that wake up in response to a WakeupOnElapsedFrames(0) wakeup condition are guaranteed to take effect in the same rendering frame.Code Structure
When the Java 3D behavior scheduler invokes a Behavior object's processStimulus method, that method may perform any computation it wishes. Usually, it will change its internal state and specify its new wakeup conditions. Most probably, it will manipulate scene graph elements. However, the behavior code can only change those aspects of a scene graph element permitted by the capabilities associated with that scene graph element. A scene graph's capabilities restrict behavioral manipulation to those manipulations explicitly allowed.
The application must provide the Behavior object with references to those scene graph elements that the Behavior object will manipulate. The application provides those references as arguments to the behavior's constructor when it creates the Behavior object. Alternatively, the Behavior object itself can obtain access to the relevant scene graph elements either when Java 3D invokes its initialize method or each time Java 3D invokes its processStimulus method.
Behavior methods have a very rigid structure. Java 3D assumes that they always run to completion (if needed, they can spawn threads). Each method's basic structure consists of the following:
WakeupCondition Object
A WakeupCondition object is an abstract class specialized to fourteen different WakeupCriterion objects and to four combining objects containing multiple WakeupCriterion objects. A Behavior node provides the Java 3D behavior scheduler with a WakeupCondition object. When that object's WakeupCondition has been satisfied, the behavior scheduler hands that same WakeupCondition back to the Behavior via an enumeration.
WakeupCriterion Object
Java 3D provides a rich set of wakeup criteria that Behavior objects can use in specifying a complex WakeupCondition. These wakeup criteria can cause Java 3D's behavior scheduler to invoke a behavior's processStimulus method whenever
A Behavior object constructs a WakeupCriterion by constructing the appropriate criterion object. The Behavior object must provide the appropriate arguments (usually a reference to some scene graph object and possibly a region of interest). Thus, to specify a WakeupOnViewPlatformEntry, a behavior would specify the region that will cause the behavior to execute if an active ViewPlatform enters it.
Note that a unique WakeupCriterion object must be used with each instance of a Behavior. Sharing wakeup criteria among different instances of a Behavior is illegal.
Additional Information
For more information, see the Introduction to the Java 3D API and Behaviors and Interpolators documents. @see WakeupCondition
You also cannot modify a components model with a behavior.
@see org.apache.wicket.behavior.IBehaviorListener @see org.apache.wicket.markup.html.IHeaderContributor @see org.apache.wicket.behavior.AbstractAjaxBehavior @see org.apache.wicket.AttributeModifier @author Ralf Ebert @author Eelco Hillenius @author Igor Vaynberg (ivaynberg) | |
| |
| |
| |
| |
| |
| |
| |
| |
| |