-----Original Message-----
From: Doug Twilleager <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, March 02, 2001 4:59 PM
Subject: Re: [JAVA3D] Collision Arch Doc up
>This is a pretty good synopsis of the overall features of the different
>collision alternatives. I have a couple of comments on this. I'm sending
>this to the interest list because some of the comments relate to behaviors
>in general.
> ...
>This description is sort of correct, but let me be a bit more specific.
>Collisions are "triggered" as a part of the Behavior system. Each
ViewPlatform
>has an activation radius. Each behavior has a scheduling region (bounds).
>When a behaviors scheduling region intersects with any ViewPlatform's
>activation radius, it may be scheduled. Note that all of this is generic
>to the behaviors system, and has nothing to do with collisions. I believe
>this is what is alluded to in the Figure 1 section above.
>
>Once a behavior is schedulable, its wakeup conditions become active.
>Once the behaviors wakeup conditions have been met, while it is
schedulable,
>it is actually scheduled for execution by the behavior scheduler. So, for
>collision, the armed collision (via WakeupOnCollisionXXX()) is only looked
>for when its behavior is schedulable. Once the collision is armed and
>active, it is tested for collision against all of the geometry in the
>scene graph. It is at this stage where we need our spatial hierarchy of
>all the geometry in the scene graph. This spatial hierarchy is currently
>an axis aligned bounding box tree.
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."
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")
(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 following section briefly describes how this screening works for
different kinds of Wakeup... conditions:
WakeupOnElapsedFrame()...
WakeupOnElapsedTime()...
WakeupOnCollisionEntry()...
...
I know. I'm getting greedy.
(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?),
-----------------
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.
TIA,
Fred Klingener
Brock Engineering
Roxbury CT
===========================================================================
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".
