>
>This is great stuff, but I need more help on your terminology:
>
>A Behavior is instantiated, initialized (with Bounds set here?), attached to
>a scene graph, and the scene graph made live.
>
>When viewer "activation radius" and Behavior "scheduling region (bounds)"
>intersect, the Behavior is "schedulable."
>
The scheduling region is set via Behavor.setScheduling[Bounds/BoundingLeaf]().
>When one or more Wakeup criteria are instantiated on the Behavior, the
>Behavior is (something else, "active"?, "armed"? Do you say individual
>criteria are "active" or "armed")
>
Armed is a good way to think about it. When the criteria is met, it has
triggered. Active is a term that is too overloaded for this semantic.
>(Some thread? on some priority and in some time relationship with renderer
>and system clock) notices that one or more of the "active" Wakeup criteria
>have come true since it last checked, and the Behavior is ("triggered" and
>then?) "scheduled" (Placed on a queue somewhere? with some priority? along
>with other tasks of the following type?) I think that I understand that all
>of the Wakeup criteria that are true at the time of this strobe are
>enumerated and attached to the Behavior for later dissection.
>
The BehaviorScheduler is currently allowed to complete one iteration during
the rendering of a frame. This makes view based behaviors work smoothly.
During that iteration, the BehaviorScheduler will:
- Look for newly scheduleable behaviors
- Check to see which behaviors have had their criteria met/tiggered
- Execute the processStimulus() methods for all behaviors that are
scheduleable and have had their criteria met/triggered.
And, since all of our threads are executed on an as-needed basis from a
scheduling point of view, the BehaviorScheduler will need to perform some
of the above operations when it runs.
Also, Java 3D threads inherit their priority from the thread which started
Java 3D - effectively the thread which loads the first Java 3D class.
Behaviors currently have no priority. We are going to add the ability
to do a very course prioritization of behaviors in 1.3.
>The following section briefly describes how this screening works for
>different kinds of Wakeup... conditions:
>WakeupOnElapsedFrame()...
>WakeupOnElapsedTime()...
>WakeupOnCollisionEntry()...
>...
>I know. I'm getting greedy.
>
I'll punt on this one. Check the javadoc for each class. If you are still
unclear on a specific one, the ask again.
>(Some other thread? on some priority and in some time relationship with
>renderer and system clock) picks the Behavior off the queue, executes
>(spawns a thread that executes?) its processStimulus, passing it
>(enumeration WakeupCriteriaThatWereTrueWhenTheBehaviorWasTriggered), and by
>the way, turns off (all of?) its Wakeup alarm(s). A particular
>processStimulus() runs (in some relationship (priority?, interrupts?) with
>renderer and other processStimulus()s?), and scene graph changes made by
>processStimulus() are reflected (in the following way?),
>
The BehaviorScheduler currently does this. We have left the specification
slightly vague in this area, because we may change it in the future. For
instance, there is no reason that given enough CPU resources, we coudn't
execute behaviors in parallel. But the execution semantic will be the same -
behaviors are executed asynchronously from the rendering of the scene graph.
We currently use a messege based system for communicating all changes to the
scene graph to the processing structures.
Yes, when a processStimulus is called, all previous wakeup criteria are
removed. This gives the behavior a clean slate and provides more room
for us in parallel emvironments.
>-----------------
>I understand that the above really is a lot more than a request for a
>fill-in-the-blanks, because it reflects a lot of suppositions on my part,
>and the real structure might be quite different. Understand that I'm not
>loooking for tutorial or code documentation but some functional description
>that lines up developer expectations with virtual reality.
>
Hope this helps. Let me know if you need anything clarified.
Doug.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
