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:
Sensor -> TX Group on view change
view moves into a collision area
collision entered triggered - forces view change
collision move triggered - view still in area force view change
.... repeat for some time
collision exit triggered
Now in the middle of this, the sensor is still driving changes into the
scenegraph as well (remember the old Doom slide along the wall trick?).
Also, how many frames have been rendered in the above example? This
single event loop probably takes 5 or 6 frames (or probably longer) that
it is making changes with.
How can you guarantee an order of execution of events? The simple answer
is that you cannot. There are separate threads for all sorts of things
under the covers and synchronising them together is just bad for
performance. What if in the above example the ordered behaviour said to
execute collisions before sensor input? This is a nasty thing to do
because collisions (or sensor) input are bound to execute first before
the other. What if there were no collisions during this evaluation
period? Does the sensor behaviour not get triggered? Also, it could
generate an endless loop. collision says move back and then sensor says
move forward. This can generate a very tightly bound loop that your code
may never be able to break out of. If J3D were to apply some arbitary
set of rules as in "you can't put collisions into an ordered group" then
that is a lot of extra work in their code as well.
Using a similar example, if you said to order collisions and sensors,
you've got two separate threads now running that are bound together at a
common point. If I was lucky enough to have some box with 4 CPUs in it
then I a couple of those CPUs will be stalled while I'm waiting. Since
collisions are also linked to the currently rendered frame, I've
probably also just stalled the rendering thread too. Not a particularly
nice thing to do.
So, all in all, having specifically defined behaviour ordering is a Bad
Thing (TM).
--
Justin Couch Author, Java Hacker
Software Architect [EMAIL PROTECTED]
rbuzz.net http://www.vlc.com.au/~justin/
Java3D FAQ http://www.j3d.org/faq/
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------
===========================================================================
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".
