Shawn Kendall wrote:
> This is a serious core problem with Java3D IMHO. For many applications there
> must be a way to guarantee that all behaviors in a scene are updated before the
> scene is drawn.
As an option, it would be useful, but not necessary. The problem is
dealing with SMP machines and also the multi-threaded architecture (two
separate problem areas).
In SMP machines, the behaviour evaluation would be running on one CPU
while the rendering runs on another. Depending on the calculation times
in behaviours, you need to sync threads across the multiple CPUs, a
relatively difficult task in Java as it is (don't know if J3D uses java
threads or native OS threads) considering you don't know whether you are
dealing with a multi-CPU box or not. Some behaviours you want to run in
background mode without updating the scene every time it renders. If you
forced every behaviour to do that, then you might as well forgo the
multi-threaded implementation because behaviours couldn't start
calculations before the previous rendering pass has completed, and then
rendering couldn't start before behaviours have completed etc etc.
For single CPUs the problem then becomes one of thread scheduling. What
if the OS decided to pre-empt the behaviour thread to run the renderer.
The renderer has to know about how behaviour execution is going and
immediately yield if no complete. You loose a lot in context swapping
and extra overheads for this. It is much simpler to just assume they run
separately. Why do you think it took until Quake 3 before the engine
became multi-threaded (even then it only has 2 threads of execution)?
> For certain animations, camera motion, etc., the playback must
> be on a per frame basis. At ANY frame rate, the savvy user will detect it if it
> is not. The only solution I can see is nothing short of replacing the entire
> Java3D behavior framework with our own!
Correct. If you need guaranteed execution order, don't use a scenegraph
based API, or use one that does immediate mode rendering and do your own
implementation. Java 3D has immediate mode capabilities.
As for importance - for my applications (Walkthroughs and dynamic VR,
but not game playing) it isn't very important at all. So long as the
input movements are processed exactly for each frame, most of the rest
of the behaviours can act with one or two frames delay without adverse
effects. Also, as rendering speeds get higher the delay between frames
and behaviour execution becomes less and so is less noticable.
--
Justin Couch Author, Java Hacker
Snr Software Engineer [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".
