From: "Michael P. McCutcheon" <[EMAIL PROTECTED]>
Sent: Thursday, March 08, 2001 10:33 AM
> Cool...I see...the WakeupOnElapsedFrame sounds most like what I was doing
> with VRML (i.e. after each frame, update all objects, etc.)
>
> So this processStimulus method is called by Java3D...does this mean that I
> should make an object than extends javax.media.j3d.Behavior pass a
> wakeupOnElapsedFrame to it's wakeupOn method, and then do all my updates
to
> all my objects in the processStimulus method, and then Java3D will
> automatically re-draw the screen after the processStimulus method is done?
You extend Behavior, declare a WakeupOnElapsedFrames criterion
private WakeupOnElapsedFrames yawn;
override the initialize() method to set its bounds (make certain that its
bounds intersect the viewer bounds), and instantiate the WakeUp... criterion
yawn = new WakeupOnElapsedFrames(0);
with an argument of 0, this triggers every frame and is probably the most
common form of animation around here, do the setup that you need like arming
the Wakeup...
wakeupOn(yawn);
then override the processStimulus(...) method to make the changes that you
want to do every frame. If you had an motion in progress, here's where you
would increment the TG for those parts. The apparent motion you get this
way is subtly different from that imparted by the Interpolators. In yours,
there will be no obvious jumps after garbage collection or windows services
because the frame cycle itself is interrupted. The Interpolators, on the
other hand, run on the system clock, and when they get back from GC, they
read the advanced system clock and advance their state accordingly. On the
screen, this can make the parts look like they are lurching or jumping
around. Whether either approach is good or bad depends on what it is you're
trying to do.
Notice that the argument sent to the processStimulus() method is a
_enumeration_ of the triggered Wakeup events, so if you have a complicated
set of alarms, you can dissect them in processStimulus() and respond
accordingly. Don't forget that you'll have to have set the capability bits
on any scene graph objects that you plan to set... or get... here. Don't
forget, too, that the Wakeup... criterion is reset when it's triggered, so
you have to set it (arm it) again, probably in your processStimulus(...)
wakeupOn(yawn);
If I understand Sun's responses on this list, you're guaranteed that
processStimulus(..) will run to completion before the completed frame is
rendered.
You'll get better advice from someone else about how to handle the AWT
events. If I had a running animation of the type described above, my first
try would be to set some sort of event flag in the normal AWT event handler
and then check its state in the WakeupOnElapsedFrames Behavior's
processStimulus() method. You do have a j3d WakeupOnAWTEvent criterion to
play with, but personally, I'd shy away from it mostly out of ignorance of
the way that it relates to the frame rendering. I think that it would be
practical to use it to make minor changes (register an event on a dashboard,
e.g), but I wouldn't try to make any changes to the main scene. Just by
preference, driven by hunch, ignorance, and half-understood messages on this
list, I'd try to cram all the scene graph changes into one Behavior's
processStimulus() with the WakeupOnElapsedFrames criterion. If it got
complicated, I'd try to define some sort of system state vector for the AWT
event handlers to set... and the processStimulus() to set... and get...
Advice is usually worth what you pay for it.
Fred Klingener
Brock Engineering
===========================================================================
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".
