Hi Kelvin,
Thanks for your comprehensive replies, I think this has helped me understand
a difference that I have been seeing between Java3D v 1.1.x and 1.2beta2.
I've been using my program to do some experiments, this involves smashing
TransformGroups into each other, and seeing which ones generate collisions,
here are the results:
Test1 - arm and Target nodes are Shape3d
-------------------------------------------
This is the scene graph that I'm using:
BranchGroup scene_branch
+-- TransformGroup blue_transform <-- transform3D changed every frame
to move blue
| +-- Shape3d blue_shape <-- armNode for blue_behavior
| +-- Behavior blue_behavior
+-- TransformGroup red_transform <-- transform3D changed every frame to
move red
| +-- Shape3d red_shape <-- armNode for red_behavior
| +-- Behavior red_behavior
This works well in v1.2 and is a LOT faster than 1.1.x
Test2 - arm nodes are TransformGroups
----------------------------------------
This is the scene graph that I'm using:
BranchGroup scene_branch
+-- TransformGroup blue_transform <-- used to move blue and as armNode
for blue_behavior
| +-- Shape3d blue_shape
| +-- Behavior blue_behavior
+-- TransformGroup red_transform <-- used to move red and as armNode
for red_behavior
| +-- Shape3d red_shape
| +-- Behavior red_behavior
In v 1.2 collision only occurs when the OTHER shape passes through (0,0,0)
In v 1.1 it works as in test 1.
I know there is an issue about the implicit conversion of bounds to sphere
in transformGroups, but its not that, it is that the world coordinates of a
TransformGroup are not affected by its own Transform.
I was hoping to use the TransformGroups as the arm and Target nodes, but it
looks like I'll have to use the Shape3D nodes?
Martin
http://www.martinb.com/
----- Original Message -----
From: Kelvin Chung <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 25, 2000 10:17 PM
Subject: Re: [JAVA3D] Collision Behaviors
> Hi Martin,
>
> >MIME-Version: 1.0
> >Content-Transfer-Encoding: 7bit
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
> >Date: Tue, 25 Apr 2000 20:58:24 +0100
> >From: Martin Baker <[EMAIL PROTECTED]>
> >Subject: [JAVA3D] Collision Behaviors
> >To: [EMAIL PROTECTED]
> >
> >Could anyone help me confirm my understanding of Collision Behaviors as
> >below, or could you tell me about any tutorials that cover these issues)?
> >
> >* By default the bounds used in collision testing are internally computed
> >each frame (unless overridden by Shape3D.setCollisionBound() or
> >Node.setBounds()) ?
>
> Yes, setCollisonBounds() will overwrite setBounds() which in
> turn overwrite the internally computed bounds.
>
> > even if the Transform3D is modified?
>
> The bounds is relative to the local coordinate system that the Shape
> is defined. As long as user set setCollisonBounds() or setBounds()
> enclosed the entire Shape (it is the user responsibility to gaurantee
> that if they choose to set their own bounds),
> it should work fine. Java3D will transform the bounds user provided
> (if any) to world coordinate and use it for collision/picking.
>
> >
> >* These bounds are in global coordinates. (does Node.getBounds() or
> >Node.setBounds() get/set global coordinates as opposed to local
> >coordinates?)
>
> No, bounds coordinates are local to the Shape. Node.getBounds()/setBounds
> use local coordinates.
>
> >
> >* If Group.setCollidable(true) is set then all its children will be
liable
> >to generate a collision so
>
> Yes, on the other hand if Group.setCollidable(false) then all of its
> children will not consider as a collision target.
>
> By default Group node is not consider as collision target
> (only leaf node does)
> However, if Group.setAlternateCollisionTarget(true) then this Group
> node will consider as a collision target. This behavior
> is implement correctly in v1.2.
>
> (if I want to get the triggering group I will
> >have to set Group.ENABLE_COLLISION_REPORTING and find it in the returned
> >path)?
> >
> Yes, this capability bit determine whether a specific group node
> along the path from the collision target leaf to the root need to
> report or not.
>
> >* WakeupOnCollisionEntry.getTriggeringBounds() returns the global
> >coordinates with the values set as they are at the time of the collision,
or
> >at the time when new WakeupOnCollisionEntry(armingPath,speedHint) was
> >called?
>
> The triggering bounds return is the Shape's local bounds
> (again it is either setCollisionBounds() or setBounds() or
> internally computed bounds if user did not define one)
> that trigger this collision (i.e. at the time of the collision).
>
> >
> >* does speedHint flag make any difference at release 1.2beta2?
>
> Yes, it makes a big different in speed since USE_BOUNDS
> only use the bound (from setCollisionBounds() or setBounds() or
> internally computed bounds) for collision which is much faster
> than USE_GEOMETRY which need to compute triangle/triangle
> intersection for every triangles in the shape using a naive method
> in both v1.1 and v1.2.
>
> Using USE_BOUNDS is much faster because in v1.2 we maintain a special
> tree structure internally using Bounds of Shape for
> quick view culling/picking/collision detection.
>
> >* does it make any difference where the Behavior node is in the
sceneGraph,
> >relative to either armingPath or triggeringPath?
>
> No, but the position of Behavior node determine the transform matrix
> above it. So in the case like
>
> public WakeupOnCollisionEntry(Bounds armingBounds)
>
> The armingBounds is local to the Behavior node and it will be transformed
> by the transformation matrix above it for collision.
>
> >
> >* If wakeupOn(WakeupOnCollisionEntry) is called when the armingPath is
> >already overlapping another node (setCollidable(true)) will this mask any
> >further collisions with a third node?
> >
>
> Yes, only after the shape( or bounds/boundingLeaf/Group/Morph)
> in WakeupOnCollisionEntry() did not collide with any other shape will
> this condition be triggered again. i.e. If you also defined
> WakeupOnCollisionExit(), you would expect to see them triggered
> alternatively.
>
> >* Does the above apply if the already overlapping nodes are parent/child?
> >
> Yes.
>
> >* If wakeupOn(WakeupOnCollisionMovement) is called when the armingPath is
> >not already overlapping another node will it get called on collision
entry?
> >
>
> The expected sequence Java3D invoke Collision wakeupCondition is (
> if you ORed together WakeupOnCollisionEntry/Exit/Movement)
>
> entry
> movement
> movement
> ..
> exit
> entry
> movement
> ...
> exit
>
>
> As a result if WakeupOnCollisionMovement is invoked, it means
> wakeupOnCollisionEntry is already invoked before. As mention
> above in this case wakeupOnCollisionEntry will not invoke
> if a third object collide with it.
>
> Note that collision detection is rewritten in v1.2 to provide
> faster and more consistent behaviors.
>
> >Thanks for any help,
> >
> You're welcome.
>
> - Kelvin
>
> --------------------
> Java 3D Team
> Sun Microsystems 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".
>
===========================================================================
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".
