Hi Sunny,
There are no new collision API's in 1.2 alpha1. The implementation is
completely new, but the API is the same. If you think you found a bug,
please submit the test case to [EMAIL PROTECTED]
Thanks,
Doug Twilleager
Java 3D Team
> MIME-Version: 1.0
> Subject: Re: [JAVA3D] Type of collision detection
> To: [EMAIL PROTECTED]
>
> Are there any collision detection documentation available for the Java 3D
> 1.2 Alpha? I have been using the 1.2 Alpha collision detection, the
> USE_GEOMETRY sometimes seems to produce unpredictable results. (I am using
> the USE_GEOMETRY collision detection to detect collision between a 2000
> faces and 1000 faces VRML model).
>
> Any thoughts?
>
> Regards,
> Sunny Leung
>
> > -----Original Message-----
> > From: Doug Twilleager [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, October 15, 1999 10:02 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JAVA3D] Type of collision detection
> >
> > This is a good summary of the 1.1.2 implementation. It is
> > completely different in 1.2. There is no longer any collision
> > thread.
> >
> > Doug Twilleager
> > Java 3D Team
> >
> > > MIME-Version: 1.0
> > > Content-Transfer-Encoding: 7bit
> > > X-Priority: 3 (Normal)
> > > X-MSMail-Priority: Normal
> > > X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
> > > Importance: Normal
> > > X-MDaemon-Deliver-To: [EMAIL PROTECTED]
> > > X-Return-Path: [EMAIL PROTECTED]
> > > Subject: Re: [JAVA3D] Type of collision detection
> > > To: [EMAIL PROTECTED]
> > >
> > > Sunny,
> > >
> > > I'm covering Java 3D collision detection in my book "Java 3D
> > Programming".
> > > The last chapter is titled "Java 3D System Architecture" and covers
> > these
> > > kind of topics. Here are some initial thoughts.
> > >
> > > Collision detection is implemented in a Thread called
> > > "J3D-Collision-#instance".
> > >
> > > The Collision thread is created by the BehaviorScheduler. The
> > > BehaviorScheduler is created in the VirtualUniverse constructor, so
> > there is
> > > one CollisionThread per VirtualUniverse.
> > >
> > > The CollisionThread is much like the other threads that Java 3D creates,
> > > they are switched between waiting and notified using Object.wait() and
> > > Object.notify() (to switch the threads on and off, so they are not free
> > > running and chewing up resources).
> > >
> > > When the CollisionThread is notified (started) it iterates through the
> > > Locales in the VirtualUniverse and traverses each of the top-level
> > > BranchGroups in each Locale.
> > >
> > > Basically the Collision detection itself just walks down the scene tree
> > > checking the bounds on each Group until it finds a Group that does not
> > > intersect with the object it is currently checking (quick exit).
> > Recursive
> > > calls will be generated depending on the kinds of Nodes it hits (e.g. it
> > > will follow Links etc.)
> > >
> > > The objects that it checks come from the Arming paths from all the
> > WakeupOn*
> > > behaviors that have been added to the scenegraph.
> > >
> > > If it hits a leaf node (e.g. Shape3D) it does this:
> > >
> > > [...]
> > > if(shape3dretained.collisionBound == null)
> > > renderobject.vwcBounds.getWithLock(targetBoundsBox);
> > > else
> > > renderobject.collBoundsVwc.getWithLock(targetBoundsBox);
> > > if(targetBoundsBox == null || collidableobject.compareBounds
> > ==
> > > null)
> > > return false;
> > > boolean flag9 =
> > > targetBoundsBox.intersect(collidableobject.compareBounds);
> > > if(flag9)
> > > {
> > > if(collidableobject.boundsOrGeometry == 1)
> > > if(collidableobject.geometry == null)
> > > flag9 =
> > >
> > ((GeometryArrayRetained)shape3dretained.geometry.mirrorGeometry).intersect
> > (r
> > > enderobject.localToVWorld, collidableobject.compareBounds);
> > >
> > > [...]
> > >
> > > Which basically gets the bounds to the object, or generates bounds from
> > > geometry (converted so they can be compared), and calls "intersect" on
> > the
> > > bounds of the collision object we are testing.
> > >
> > > When the traverse is done, the thread goes back to sleep with a call to
> > > Object.wait()... maybe!.
> > >
> > > I'm no expert on collision detection, but this seems like a pretty
> > "basic"
> > > implementation from an algorithm point-of-view. I may also have missed
> > some
> > > complexity in the Java 3D code (I need to examine it some more), so
> > > apologize all round if I have mis-stated anything. Please note that all
> > this
> > > is based on the current implementation of Java 3D.
> > >
> > > I hope this gives some insights, if not much help!
> > >
> > > Sincerely,
> > >
> > > Daniel Selman
> > >
> > > [EMAIL PROTECTED]
> > > http://www.tornadolabs.com
> > >
> > >
> > > -----Original Message-----
> > > From: Discussion list for Java 3D API
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Burrows
> > > Sent: 14 October 1999 15:34
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Type of collision detection
> > >
> > >
> > > At 11:52 11/10/99 +1000, you wrote:
> > > >Hi,
> > > >
> > > >Does anybody know what kind of collision detection routines are being
> > > >implemented in the Java 3D collision detection behavior (i.e.,
> > > >WakeupOnCollisionEntry(), WakeupOnCollisionExit() and
> > > >WakeupOnCollisionMovement()).
> > > >
> > > >Many thanks,
> > > >regards,
> > > >Sunny Leung
> > > >
> > >
> > >=========================================================================
> > ==
> > > >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".
> > > >
> > > >
> > > I've seen nothing about it generally Sunny. There was a report some
> > time
> > > ago that it is running in a seperate, inaccessible, thread - but that's
> > > been the only comment I've seen on it. There have been a lot of
> > criticisms
> > > about where it fails to work, so it wouldn't seem to be one of the
> > standard
> > > ones.
> > >
> > > I've heard, via the team who brought us VCollide, a rumour that there
> > are
> > > supposed to be teams in Japan and Australia working on a Java version of
> > > this and another that a team is working on a Java version of VClip.
> > >
> > > Tony
> > > Microsoft is not the answer.
> > > Microsoft is the question.
> > >
> > > Avoid the Gates of Hell. Use Linux
> > >
> > >
> > ==========================================================================
> > =
> > > 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".
> > >
> > >
> > ==========================================================================
> > =
> > > 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".
> >
> > ==========================================================================
> > =
> > 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".
>
> ===========================================================================
> 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".
===========================================================================
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".
