The only way to be sure that you get totally synchronized behaviors execution
in Java3D is to write your own behavior management (which it sounds like you
have) and to call it's update somewhere in a derived Canvas3D class, mostly
likely in pretender(). We had to do this BUT the main problem is that if you
also wish to use regular web available off-the-shelf Java3D behaviors you may
have worse sync problems. If all the behaviors are your own for your own
behavior management system, it should work fine.
A problem with this technique is if you have more than one Canvas3D. We gave
up for now and have accepted an out of sync system because of this.
Joe Kiniry wrote:
> Hello folks,
>
> I have an application that has a large amount of computation (real-time
> physics + much more) before correct information is available to render a
> new frame. All of our subsystems are multi-resolution, that is to say, we
> can tune their detail level such that per-step execution times are bounded
> and the results are still correct and consistent. Thus, we suspect that
> the best solution for rendering is to lock-step render. That is to say,
> we'd like to loop { compute -> render a frame }.
>
> I'm certain this must be a common problem when using Java3D as a rendering
> engine, especially given the unreliability and under-specification of Java
> thread behavior.
>
> On investigation, I haven't found any specific information in the mailing
> list or online for solutions to this problem. I have seen that other folks
> are doing work that is similar in nature and even in similar domain, given
> the AI Robots game to which I saw reference and everyone's interest in
> massive multi-player online experiences, so I'm sure there are some good
> solutions out there.
>
> Me, I'm just a computer scientist, so my solution is just to use two
> mutexes to lock-step the rendering engine via a behavior that wakes on
> every frame. Is this a reasonable thing to do? I don't have any
> information about what other threads in the Java3D framework might be up
> to, but I do get the impression from previous posts that I'm guaranteed
> that rendering will not continue until a behavior's trigger has returned.
>
> I have seen the discussions about postId, but this doesn't help given you
> have no guarantees about thread scheduling behavior, even with tuning
> Java3D's priorities.
>
> If more details are necessary, please ask. Suggestions are welcome.
>
> Best,
> Joe Kiniry
> --
> Joseph R. Kiniry
> DALi, Inc.
>
> ===========================================================================
> 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".
--
___________________________________________________________
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
___________________________________________________________
===========================================================================
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".
