From: Michael Fernandes
Sent: Thursday, April 26, 2001 8:19 PM
> I'm new to Java3D and I'm trying to get a wakeup behavior to give me
> a constant maximum frame rate. When I use WakeupOnElapsedTime
> the best I seem to be able to do is about 20 FPS.
WakeupOnElapsedTime would seem to be the way to control the frame rate, and
in fact, it seems to work quite well on some OSs. If I set the Wakeup
period to be slightly smaller than the OS time grain size, then I can keep
my simulation clock pretty well lined up with the meat clock. This works
well and consistently on WinNT and W2k, and though I haven't tested it, I
expect it should work with Solaris as well. WinNT and W2k have an OS time
grain (the resolution of getCurrentTimeMillis()) of a little more than 15
milliseconds, so a Wakeup parameter of 15 milliseconds (67 frames per
second), 30 (33 fps) or 45 ms (22 fps) gives reasonable control over the
simulation clock, depending on the compute load.
As far as I can tell, WakeupOnElapsedTime is broken for arguments less than
a few hundred milliseconds on W95, W98, and Wme, because of the
unpredictable interaction with the system clock. At least I haven't been
able to figure out a pattern if one exists. Before I build my model, I
measure the OS time grain size with a wait() routine, and W95, W98, and Wme
seem to have a time grain of something like 60 ms, but the individual
response time steps relative to the getCurrentTimeMillis() clock can range
from 0 to several multiples of the 60 ms. A pretty unworkable situation.
> But when I use
> WakeupOnNextFrame(0) the FPS is almost 200, but that is very
> dependent on the speed of the machine and the contents of the scene
> graph.
Too, the WakeupOnElapsedFrame hogs all of the system compute power, and it
makes it impossible to control the relationship between the simulation clock
and the meat clock.
> Does anyone know of a good way to get a behavior that will
> max out around 30 FPS regardless of the speed of the machine and
> the content of scene graph?
I think that the 'real' way to do it is to use WakeupOnElapsedTime. It is
probably too much to ask for higher resolution on the strobe that checks the
behavior queue or that these behaviors have a more direct interrupt-driven
design, but I'd settle for reduced OS-dependency.
I think that this is a huge hole in the 'run anywhere' claim, because right
from the gitgo, it makes my simulation clock operation platform-dependent,
and I can't even begin to discuss verification of a simulation. It puts a
limit on the seriousness of the problems you can address with j3d. This
isn't to say that there's anything wrong with j3d - Sun never said that it
was intended to do that sort of thing - but it is otherwise SO COOL I'm
trying to see how far it can be stretched.
Right now, I'm developing on W2k and denying there is a problem. I suppose
I'll have to come up with a separate scheme for W95 et seq. and state that
those results can't be taken seriously.
I'd love to have someone show me a work around for this.
Cheers,
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".
