First, thanks for the more detail explanation.
Because Java3D guarantees that rendering is halted during execution of a
behavior's processStimulus() method we can guarantee that (a) the
computation thread gets put in the run queue next and (b) that the
rendering thread waits until it is signalled that computation has completed
before rendering a new frame.
Second, what is your source for; " Java3D guarantees that rendering is halted during execution of a
behavior's processStimulus() method"?  Is it in the API docs somewhere?

Several developers, including myself, have posted about this many times before.  The official response from the Java3D team was that Java3D does NOT synchronize the render and behavior threads and will not because the API spec does not specify that it should.  I myself was just posting code to the Java3D team yesterday that showed more problems with this.

The only ways I know of to make sure that your updates are atomic and the not concurrent with the render thread is in the GeometryUpdater interface for GeometryArrays or stop the thread yourself.
Perhaps, I have missed this.

Can someone on the Java3D team please address this as soon as they can, and perhaps post the thread organization once and for all?

--
___________________________________________________________

Shawn Kendall               Full Sail Real World Education
Course Director             3300 University BLVD
Real Time 3D for Gaming     Winter Park FL 32792
[EMAIL PROTECTED]       http://www.fullsail.com
___________________________________________________________
 

Reply via email to