Re: [JAVA3D] Behavior and Render thread synchronization problem

[Shawn Kendall]

This single behavior work-around does not work for us because outside loaders, as well as our own, will still put Java3D behaviors throughout the scene graph.  We could traverse the whole scene and remove them and then create our copies and put them in our system, but then we would have to reimplement every single damn behavior people write out there! Not a very good solution.... David wrote:   Well it does not make me happy to hear the problem with behavior synchronization is not addressed in the upcoming version.  Especially since Kevin posted a huge long article on this very topic a LONG time ago admitting it was an issue.  I think the "resolution" until a fix was to make sure a certain order was followed within the behavior.  Something like update the scene, then update the view transform.  On certain platforms he assured us this would guarentee the two would be sychronized if they were done within a single behavior.  I have found this to be true under the opengl version on windows.  My overlay code, which of course is very sensative to this issue, became rock solid when I did this.  Course I am scrapping the overlay code because its impossible to handle the scope of a true user interface (see my rants on user interfaces in the newsgroup). Dave Yazel ----- Original Message ----- From: Shawn Kendall To: David Sent: Tuesday, September 26, 2000 7:56 PM Subject: Re: [JAVA3D] Behavior and Render thread synchronization problem  Yes we are beta testing - not sure if that is postable common knowledge but anyway... YES, you are describing the same problem. NO! The "bug" is not fixed in the beta - it is much worse.  however, officially this is not a bug.  The Java3D API spec does not guarantee the synching.  This was pointed out to me the last time I posted this question. David wrote: I thought you guys were in the beta program?  And I also thought this was solved in the upcoming release?  In particular I think the documented bug was that updates to the view transform and scene graph where not synched.  Are you describing another problem? I know I used to have jitters of various kinds until started putting messages into a queue, then processing all the scene graph changes in a single wakeuponelapsedframes(0).  Of course you are right, this does not solve behavior issues.  In particlular I was solving the viewtransform/scenegraph change issue. Is this what you are talking about or are you referring to something else, and has Sun agreed its a problem. And... isn't there a dev chat soon? Dave Yazel ----- Original Message ----- From: Shawn Kendall To: [EMAIL PROTECTED] Sent: Tuesday, September 26, 2000 6:58 PM Subject: [JAVA3D] Behavior and Render thread synchronization problem  To start off, I have brought up this topic twice before on this list . A few people supported and a few were very against it. However, our project has reached a point where we MUST have correct sync between the behaviors and render per frame. Now we have completely implemented our own behavior management system already.  However this system currently gets it's update from a Java3D behavior that is trigger by a WakeOnFrameElapsed = 1. So, for our behaviors everything seems to work fine but there are times when we still need or would like to use standard Java3D behaviors, such as Billboard or the utils-KeyNavigator behaviors. Therein lies the problem.  Because these multiple Java3D behaviors throughout the graph are NOT guaranteed to be updated "atomically" before the render, jitter becomes a way of life. Unfortunately, our project has reached a point where we can no longer have jitter in our demos. So we are about to insert our behavior execution into a Canvas3D object that will call our update in the pre-render.  This will make sure our updates get done before the frame.  This does not fix the normal Java3D behaviors - Billboard etc. so we CAN NOT use them.  We are force to rewrite any Java3D behavior we wish to use to work in our update.  Additional, we will be writing our behavior management code to run threaded, so on our multi-processor systems we will get processor utilization.  If you guys are interested I can explain how we are multi-threading AND synching (I'm sure you guys understand this, just other people on the list posted it can't be done). The point of this detail explanation is that it is extremely disappointing that we must do this at all!  It is ridiculous to have to reimplement the Java3D behavior system and behaviors and/or remove then from the graph to get correct execution.  A simple sync option should exist in the View class that guarantees this execution.  And it's not particularly difficult to implement, at least not how we do it. On a side note, we have done this for years using SGI's Performer, and it is a must for many, many 3D apps. Is this the only option.  Any suggestions on a better work around would be greatly appreciated? ___________________________________________________________ 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 ___________________________________________________________     -- ___________________________________________________________ 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 ___________________________________________________________   -- ___________________________________________________________ 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 ___________________________________________________________