Author Topic: Collision detection  (Read 3816 times)

Offline doc.ios

  • byte
  • *
  • Posts: 4
    • View Profile
Collision detection
« on: October 27, 2010, 12:53:55 pm »
I've been trying out jPCT today, and I can't figure out collision detection.

I started with the hello world for Android example.

I added another shape then moved one shape to collide with the other, and listened for collision.  At least I think so.  I haven't seen any examples or tutorials to do with collision (Can anyone point me to something?).  And I'm just picking out methods from the javaDocs that look like they'll do the trick.

With my two shapes, I do the following:-

Code: [Select]
cube.setCollisionMode(Object3D.COLLISION_CHECK_SELF);
cube.setCollisionOptimization(true);
cube.addCollisionListener(this);

sphere.translate(20, 0, 0);
sphere.setCollisionMode(Object3D.COLLISION_CHECK_OTHERS);
sphere.setCollisionOptimization(true);
sphere.addCollisionListener(this);

Alright, I suspect I don't need to set BOTH shapes up, but I was trying to get it working.

I've implemented CollisionListener, and written:-

Code: [Select]
public void collision(CollisionEvent arg0) {
    Logger.log("collision");
}

@Override
public boolean requiresPolygonIDs() {
// TODO Auto-generated method stub
return false;
}

Then within the game loop, I just move the sphere towards the cube...

Code: [Select]
  sphere.translate(-0.5f,0,0);

And also tried moving the camera with checkCameraCollisionSpherical/Ellipsoid, but it didn't stop at the obstacle.

I don't understand the way slideMode id described anyway.  Does this mean it will stop at the obstacle, and slide no further?  Or not move (slide) if there is an obstacle in the way?

I know there's a similar scheme for moving an object (instead of using translate).  To stop at an obstacle.  Can anyone point me at an example?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11777
    • View Profile
    • http://www.jpct.net
Re: Collision detection
« Reply #1 on: October 27, 2010, 08:55:01 pm »
It seems to me that the collision modes are reversed in your example code. If the sphere moves towards the cube, the cube should be ....OTHERS and the sphere should be ...SELF. You can also combine both modes by using the | operator.

Anyway, translate() itself doesn't trigger any collision checks. It simply translates. What you actually need is either checkForCollision... in Object3D or checkCollision...in World. All (except for the ray-polygon approach, which i don't cover here) will return a corrected move vector in case of a collision, but they don't do any translation. It's up to you to use this vector to translate an object or destroy it or whatever.
Also make sure that World.collisionOffset isn't set too low for your geometry.

I've also added a simple example derived from one of my older test case classes and added it to the wiki here: http://www.jpct.net/wiki/index.php/Collision_detection. It's not using jPCT-AE, but the actual code should be pretty similar.

One last word about the CollisionEvent: If you can avoid to use it on Android, then do it. It's creates event objects and the more object creations you can avoid, the better. There's a method to query an object if it was part of a collision. That's not very OOish nor very elegant, but faster on Android.


Offline doc.ios

  • byte
  • *
  • Posts: 4
    • View Profile
Re: Collision detection
« Reply #2 on: October 28, 2010, 09:48:07 am »
That was very helpful.  Thank you.

One more question.  I see I can check if the cube was the target of the collision, using cube.wasTargetOfLastCollision();  How do I check if the sphere has collided with something/anything ?  Without checking every potential target?  Or is this not something that can be polled?  An acceptable use of CollisionEvent perhaps?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11777
    • View Profile
    • http://www.jpct.net
Re: Collision detection
« Reply #3 on: October 28, 2010, 04:03:43 pm »
I would say that an object collided with something if the returned translation vector doesn't equal the initial one. That may not be 100% true, but it should cover 99.99% of all cases. Or just go with the CollisionEvent. If it proves to be a bottleneck because of too much garbage being produced, we can still look for an improved solution.