The problem is deeper and perhaps more fundamental than just assuring
the order of behavior execution. In systems that rely on detecting
changes in the general scenegraph (e.g. view movement, object
movement, object collision, object visibility, window size and scale
changes, etc.) to perform actions and perhaps to trigger other
changes, the matter can not be easily boiled down into a simple
deterministic order of execution. Instead, there are event chains
that can spread out and possibly loop back on them selves (which need
to be blocked). The whole concept of event chaining, update
sychronization, and event loop prevention was a topic dealt with by
VRML routing (and much discussed at the conferences). Although most
VRML players got a lot of it right, our testing revealed that only
Cosmo got it all right (or at least all of the tortures we were
subjecting it to), and so would be a good place to start for
investigating such matters.
In summary, event chaining and sychronization are very important
subjects for applications that dare to go beyond the simple examples
provided with the Java 3D JDK. It seems that VRML has a much more
mature and robust event model than that of Java 3D (or putting it
another way, that Java 3D has a very immature event model in
comparison to VRML), and that much could be learned from how VRML
players approached the subject. That's not to say there wasn't room
for improvement to the VRML update/sychronization model, which means
that Java 3D has that much further to go in this regards.
--jon
> Date: Tue, 27 Jun 2000 15:31:50 -0400
> Date: Tue, 27 Jun 2000 12:20:30 -0400
> From: Shawn Kendall <[EMAIL PROTECTED]>
> Subject: Java3D's Behavior's weaknesses - was Re: View and Scene
> synchronization bug
>
> Since this is not considered a bug because the API does not specify order importance,
> I
> believe that the below explanation or other should be inserted into the API
> documentation in
> the appropriate place.
>
> Realize, of course, that this is a VERY significant issue, because a large set of
> apps will
> move the view based on some other objects motion, for example, practically every game
> developer
> that tries to use Java3D! Not every 3D app uses head-tracking...in fact almost none
> do.
>
> If Java3D cannot guarantee some kind of execution order then this effectively means
> that many
> Java3D apps should NOT use the Java3D behavior system at all, which is exactly what
> we had to
> do for our apps.
>
------------------
> From: "Kasparian, Raffi J." <[EMAIL PROTECTED]>
> Subject: OrderedBehavior
>
> I, too think that an important feature missing in java3D is the ability to
> guarantee the execution order of behaviors -- something analogous to
> OrderedGroup. For what it's worth, I discovered that I can affect the order
> in
> which behaviors are executed by the order in which I add them to the scene
> graph. I have created a couple of classes that automate this process. I
> haven't
> tested them for behaviors that have wakeupConditions other than
> wakeupOnElapsedFrames( 0 ) but they work for me and could be expanded to be
> more
> general purpose. This is definitely not an ideal solution and it relies on a
> perhaps undependable quirk in the Java3D engine.
>
--
__________________ JMB and Associates, Inc. ___________________
Jon Barrilleaux 3800 Lake Shore Ave. Consulting for 3D
[EMAIL PROTECTED] Oakland, CA 94610 Web Applications
510.444.4370 voc & Tech Industry
510.444.0231 fax www.jmbaai.com Management
===========================================================================
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".
