I have posted may times on similiar problems.
The short of it is that in the current versions 1.2.x, the only work
around for MOST sync problems is to guarantee execution in the same
behavior. We use a custom behavior manager to get around this.
Unfortunately, it means we have to "adopt" any community behaviors we
would like to use to our system.
However, I do not think this will work for your project because the
problem happens AT render. I do believe the following technique should
fix it.
Make sure that ALL of the updates to anything effecting the splitting
geometry are in the geometry's GeometryUpdater. If you are not using a
GeometryUpdater, that is definitely going to cause render problems.
This is a little round-about but it should work. Please post your progress.
BTW, behavior sync-ing is one of the features planned for version 1.3
Joe Kiniry wrote:
> Hi again all,
>
> As I have mentioned in the past, we have a rendering engine that supports
> skinned articulated rigid bodies. We have used indexed geometry for the
> inter-joint polygons and by-copy geometries everywhere else (with judicious
> use of our own data caching &c).
>
> Our current problem is due to the asynchronous nature of Java3D. An
> example will suffice:
>
> Say a joint in a skeleton moves to a new position. This means that we have
> to (a) update both the position of the fixed skin attached to the limb(s)
> that just moved and (b) update the inter-joint polygons which have now
> stretched/shrunk to fill the "gap" between fixed geometries appropriately.
> (a) is simple since the geometry is in the transform of the joint, thus we
> don't have to do anything there. (b) is implemented with some math applied
> to our indexed geometry datastructure, updating vertex positions, normals,
> etc.
>
> The problem is that, while these two events happen each and every frame,
> the visual updates that we witness are *not* synchronized. In other words,
> sometimes we see the fixed and indexed geometries moving in a regular, but
> *unsynchronized* fashion. E.g. Gaps appear between the fixed and mutable
> geometries. These gaps are not pixel-peek or similar, they are real
> discontinuities that are visible, but do not exist mathematically.
>
> We assume this is due to the asychrononous nature of Java3D. Calling a
> setCoordinate method (just a random example) doesn't mean "set this data
> value and, when you are completely done with this operation, return to me".
> It actually (likely) means "set this value at some point in the future, so
> long as you don't invalidate any future calls that I might make that
> references this data". It is a standard enough temporal logic-based
> specification - something I've done countless times in my research work at
> Caltech (its just a leads-to, aka eventually, specification). The problem
> is that I have no (obvious) way to enforce synchronization between such
> calls.
>
> Has anyone struggled with this problem and found a solution? Would anyone
> from Sun like to comment on this use of their product?
>
> P.S. So far no one has publically commented on my previous post about
> setCoordinate() semantics and computational complexity. I have received
> some private email on the subject though. Does no one from Sun have a
> comment? Has no one experienced these significant differences?
>
> Best,
> Joe
> --
> Joseph R. Kiniry
> Chief Scientist
> 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".
