Hi Fred,
WakeupOnElapsedFrames(0) will always (by design) cause the Java3D system
to render frames as quickly as possible and therefore consume all the CPU
resource available. Use WakeupOnElapsedFrames( 0, true) to cause a passive
wakeup which will only wakeup when another behavior in the scenegraph causes
a new frame to be drawn.
Now to the harder question.......
The problems you are having with WakeupOnElapsedTime are rooted in the VM not
necessarly Java3D. The Thread sleep(ms) and Object wait(ms) calls have very
different results depending on the platform. I've included the output of
some tests below which show the actual resolution of the sleep and wait
events on NT and Solaris.
NT
1000 calls to sleep(1) in 2125 msec : 2.125 msec/sleep
1000 calls to sleep(5) in 6328 msec : 6.328 msec/sleep
715 calls to sleep(7) in 5859 msec : 8.194405594405595 msec/sleep
501 calls to sleep(10) in 7828 msec : 15.624750499001996 msec/sleep
334 calls to sleep(15) in 5219 msec : 15.625748502994012 msec/sleep
295 calls to sleep(17) in 5312 msec : 18.00677966101695 msec/sleep
251 calls to sleep(20) in 7844 msec : 31.250996015936256 msec/sleep
201 calls to sleep(25) in 5188 msec : 25.81094527363184 msec/sleep
143 calls to sleep(35) in 5047 msec : 35.29370629370629 msec/sleep
1000 calls to wait(1) in 15609 msec : 15.609 msec/sleep
1000 calls to wait(5) in 15625 msec : 15.625 msec/sleep
715 calls to wait(7) in 11172 msec : 15.625174825174826 msec/sleep
501 calls to wait(10) in 7828 msec : 15.624750499001996 msec/sleep
334 calls to wait(15) in 5219 msec : 15.625748502994012 msec/sleep
295 calls to wait(17) in 9218 msec : 31.247457627118646 msec/sleep
251 calls to wait(20) in 7844 msec : 31.250996015936256 msec/sleep
201 calls to wait(25) in 6281 msec : 31.248756218905474 msec/sleep
143 calls to wait(35) in 6704 msec : 46.88111888111888 msec/sleep
Solaris
1000 calls to sleep(1) in 10029 msec : 10.029 msec/sleep
1000 calls to sleep(5) in 9991 msec : 9.991 msec/sleep
715 calls to sleep(7) in 7143 msec : 9.990209790209791 msec/sleep
501 calls to sleep(10) in 5018 msec : 10.015968063872256 msec/sleep
334 calls to sleep(15) in 6679 msec : 19.99700598802395 msec/sleep
295 calls to sleep(17) in 5899 msec : 19.996610169491525 msec/sleep
251 calls to sleep(20) in 5019 msec : 19.99601593625498 msec/sleep
201 calls to sleep(25) in 6029 msec : 29.99502487562189 msec/sleep
143 calls to sleep(35) in 5719 msec : 39.99300699300699 msec/sleep
1000 calls to wait(1) in 19969 msec : 19.969 msec/sleep
1000 calls to wait(5) in 19999 msec : 19.999 msec/sleep
715 calls to wait(7) in 14299 msec : 19.998601398601398 msec/sleep
501 calls to wait(10) in 10020 msec : 20.0 msec/sleep
334 calls to wait(15) in 6679 msec : 19.99700598802395 msec/sleep
295 calls to wait(17) in 5899 msec : 19.996610169491525 msec/sleep
251 calls to wait(20) in 7569 msec : 30.155378486055778 msec/sleep
201 calls to wait(25) in 6059 msec : 30.144278606965173 msec/sleep
143 calls to wait(35) in 5779 msec : 40.41258741258741 msec/sleep
You will notice that on NT the sleep resolution is around 2.2ms but is
extremely unreliable sleep(20) returns in 31ms, sleep(25) returns in 26ms. The
wait call on the other hand has a resolution of 15ms.
On Solaris sleep resolution is 10ms and wait resolution is 10ms but with a
minimum of 20ms.
Another issue is the resolution of the System.currentTimeMillis() call
which you might want to use to determine the accuracy of the sleep/wait.
On NT the resolution of the timer is 15ms, on Solaris 1ms.
So, we will continue to investigate this issue in terms of Java3D implementation
and the wider issue of accurate time in Java. In the meantime I suggest
you use a seperate thread to perform your regular calculations and use
a behavior post to render the results.
For accurate current time results you may want to look at the
javax.media.TimeBase in JMF, again accuracy will vary with platform.
Rgds
Paul
----------------------------------------------------------
Paul Byrne Email : [EMAIL PROTECTED]
Sun Microsystems Phone : (650) 786 9926
Visualization Software Group Fax : (650) 786 5852
----------------------------------------------------------
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>Date: Thu, 28 Sep 2000 10:21:03 -0400
>From: Fred Klingener <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Simulation clocks - continued
>To: [EMAIL PROTECTED]
>
>Remember that in the last episode, Freddie had replaced the standard
>Interpolators with a set of Behaviors that maintained a separate simulation
>clock using a wakeupOnElapsedTime(time_step) criterion, rather than the
>wakeupOnElapsedFrame(0) used by the standard ones. As we left him, Freddie
>was puzzling over the odd results: 1.) the introduction of Behaviors that
>use the wakeupOnElapsedTime(time_step) criterion evidently stopped the
>rendering thread's characteristic free-wheeling behavior as evidenced by the
>recovery of a significant portion of the CPU capacity, and 2.) there was an
>odd relationship between the specified time_step and the actual elapsed time
>(as measured by the System clock) that the Behavior's processStimulus() got
>executed.
>
>As we look in on him now, he's laboriously stepping through values of the
>scheduled time_step and logging the observed difference in System clock
>readings between processStimulus() calls. [Zoom in on the scrap of paper in
>his lap. Toward the bottom is the graph:]
>
>(sorry about the graph, if you don't have exactly the font I used to
>construct it)
>
> 46 + *******
> |
> Delta Time |
> on the 31 + ********
> System |
> Clock |
> (milliseconds) 15 +*******
> |
> |
> +-------+--------+--------+--------+
> 15 31 46
> time_step
>
>"Hah!" says Freddie as he slaps his forehead. "It's as though the Behaviors
>post their wake up times to a queue, and the scheduler only checks the queue
>every 15 or 16 milliseconds." He turns to Margo, his incredibly beautiful
>ash blonde Chief Technology Officer, and says, "This means that if we don't
>pick the right time_step, we won't be able to synch our simulation clock to
>the System clock. If we pick 31 milliseconds, we'll be almost exactly in
>synch, and at 32 milliseconds, we'll slip by 33%"
>
>Margo sniffed and said, "Well, that's an interesting little cosmetic tidbit
>you've stumbled on there, but the real crux is the effect on the adaptive
>time stepping routines in our IK iterators and the numerical integrators.
>If we don't tiptoe around that 15 milllisecond strobe, our solutions and the
>display will look like garbage, even if they're correct."
>
>"I know you would have figured that out by yourself eventually, but we have
>to get a strategy for dealing with this NOW. Get on JAVA3D-INTEREST and see
>if anyone knows whether this is documented anywhere. Can we count on this
>across platforms? Across versions? Will we have to test each system on the
>fly before we can begin our simulation?"
>
>Margo began to leave but turned and leaned over the cubicle wall. "And
>another thing. You just got the averages over 100 frames. Redo it and get
>the distributions. We have to know how regular this is. Don't worry about
>the delays for garbage collection and system services. They'll probably
>take much longer than 15 milliseconds. They'll be outliers."
>
>"Yes'm."
>
>The closing credits roll as Margo turns and walks back to the daycare center
>adjoining her window office, and Freddie hunches over his keyboard to
>compose...
>
>
>Freddie Klingener
>Brock Engineering
------------- End Forwarded Message -------------
----------------------------------------------------------
Paul Byrne Email : [EMAIL PROTECTED]
Sun Microsystems Phone : (650) 786 9926
Visualization Software Group Fax : (650) 786 5852
----------------------------------------------------------
===========================================================================
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".
