Yes, but let's not lose sight of why this topic came up. The Java 3D
event/synchronization model is significantly deficient in comparison
to VRML. If it could at least do as well as a 5 year old technology
in this department, then we would have the luxury of worry about
trying to solve the NP complete version. I'm sure Justin can comment
on this further, but as I recall the VRML folks were not trying to go
for the home run, just a triple play. Bottom line, there are some
rather simple things that Java 3D currently doesn't allow because of
its simplistic approach to event handling and synchronization. Justin
pointed out a few. I have a few more in the 3D GUI realm.
A notion that was introduced on this list a long long time ago, I
think, has potential and applicability in this area. I'll elaborate
on it further: Define interface hooks in the API into the
event/update/render system so that if a developer or third party
doesn't like the default action, they can tap in and implement a more
industrial strength or custom version of the API's collision
detection, event chaining, picking system, etc. Note that this does
not let the API off the hook -- it still has to provide these
fundamental services. Instead, developers could choose to roll their
own if the default version is inadequate for their needs.
--jon
> Date: Wed, 28 Jun 2000 23:09:01 -0400
> From: Fred Klingener <[EMAIL PROTECTED]>
> Subject: Re: change/update sychronization
>
> From: Justin Couch <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 28, 2000 9:20 PM
> Subject: Re: [JAVA3D] change/update sychronization
>
>
> > Jon Barrilleaux wrote:
> >
> > > 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.
> >
> > As someone who was *deeply* involved in all of this (I chaired the event
> > model group, java scripting group and the external interface group) I
> > have to add a lot of extra exclamation marks to the above statement.
> > Deterministic event scheduling is an extremely hard problem. Actually
> > I'd go as far as saying NP Complete. Sure you can put in an ordered set
> > of behaviours that kick of the first round of events, but you soon end
> > up with loopback problems. Consider the following:
>
> < snip >
>
> Feeding "parallel simulation" or "time warp" into Altavista will get you a
> couple thousand hits that document the struggles the parallel simulation
> people have with synchronization and scheduling and the cascading rollbacks
> they have to use to avoid lockups and to obtain a 'correct' result that is
> faithful to the spec. I don't think that any of that stuff runs in real or
> proportional time. I think that it has to be solved and then played back or
> buffered pretty deeply before the result is displayed.
>
> Personally, I'm too old to start trying to solve NP complete problems.
>
> Cheers,
> Fred Klingener
--
__________________ 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".
