Detected Collision Pipeline

Member
Posts: 215
Joined: 2008.06
Post: #1
Despite the responses from my last thread here, I have run out of places to turn for advice, so here's the deal: How would you recommend interfacing game logic with a physics engine to signal "This object was hit by this object at this velocity"? This approach would ideally be able to allow for scripted interaction of the two objects based on the type of objects and the velocity of impact. I have tried a few different approaches, and the best one I have figured out is an Obj-C 'pipeline' that game logic can register with that collisions are added to when detected. Any thoughts?

Mac users swear by their computers, PC users swear at their computers. ~Unknown

iSayz
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
I guess the important question is what physics engine you are using? It's most certainly going to matter most what the interface of that engine is.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 215
Joined: 2008.06
Post: #3
Skorche Wrote:I guess the important question is what physics engine you are using? It's most certainly going to matter most what the interface of that engine is.

I'm actually writing my own. I currently have a completed mass-aggregate system and I would like to do some game prototypes with it, but I need a game logic interface. It's all done in obj-c, any advice?

Mac users swear by their computers, PC users swear at their computers. ~Unknown

iSayz
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #4
You might have to explain what this "mass aggregate" is referring to. A google search turns up a lot of stuff about paving roads and one paper about particle and stick constraint physics.

What I do in Chipmunk Physics is to give each collision shape a type. When two objects collide, I make a key from their two collision types and use that to lookup a callback from a hash table. The callback is passed the collision data (collision points, normals, depth, etc) and returns a boolean indication whether or not to continue processing the collision.

If the key is not found, I call a default callback (which can be changed by the user). By default the default collision callback simply returns true,.

At first I was nervous about doing an "expensive" hash lookup for every single collision, but the cost was something smallish like a 1% slowdown. Definitely worth it. You might have to be semi-careful if you are calling ObjC methods. At least with the Ruby extension, you can easy kill performance simply by calling an empty block for every collision.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #5
I suppose I should clarify a little bit more.

Chipmunk doesn't process collisions using these callbacks. They only allow you to hook into the collision event and give you an extra bit of control over which collisions to cull.

The full thing goes something like this:
  1. Potetially colliding pair of shapes returned by spatial index. (broad-phase)
  2. Bounding box check. (mid-phase)
  3. Cheap collision filter check (layer bitmask, logical grouping)
  4. Shape to shape collision check (narrow-phase)
  5. Collision callback called, collision discarded if return value is false.
  6. Pair of colliding objects stored in a big list if it makes it this far.


Only after the full list of colliding objects has been generated, do I start resolving any collisions. As a rigid body physics library, Chipmunk works exclusively by modifying velocities so I don't need to worry about any new collisions until after the positions are updated.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 215
Joined: 2008.06
Post: #6
Skorche Wrote:I suppose I should clarify a little bit more.

Chipmunk doesn't process collisions using these callbacks. They only allow you to hook into the collision event and give you an extra bit of control over which collisions to cull.

The full thing goes something like this:
  1. Potetially colliding pair of shapes returned by spatial index. (broad-phase)
  2. Bounding box check. (mid-phase)
  3. Cheap collision filter check (layer bitmask, logical grouping)
  4. Shape to shape collision check (narrow-phase)
  5. Collision callback called, collision discarded if return value is false.
  6. Pair of colliding objects stored in a big list if it makes it this far.


Only after the full list of colliding objects has been generated, do I start resolving any collisions. As a rigid body physics library, Chipmunk works exclusively by modifying velocities so I don't need to worry about any new collisions until after the positions are updated.

Thanks! That answers some things: You recommend that I apply the interface BEFORE adding collision events to my collision registry, that way the interface can specify whether collision resolution is necessary or not. Are these callbacks you mentioned simply C callback functions, or are they something specific to Chipmunk? How are specific objects handled using this architecture (ie, if one object is a bullet and the other objects is a gas can, how does Chipmunk know how to respond when these objects collide)?

P.S. Don't worry about the mass aggregate terminology. It simply means that I'm not dealing in rigid body physics right now, instead objects are made of collections of point masses held together by rods, cables, and springs.

Mac users swear by their computers, PC users swear at their computers. ~Unknown

iSayz
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #7
Chipmunk is pure C, so yes callbacks are just functions. Yeah, doing it before adding it to the collision list was handy as another option for collision culling.

Well, collision types are just integers. Say gas can = 123 and bullet = 456. If you wanted to blow up the gas can when hit by a bullet, you can register a collision callback for (123, 456). When the callback is called, Chipmunk will pass it the shapes in the order their types were registered. So you will always get the gas can first, then the bullet. Chipmunk shapes have a user definable pointer that you can use to get to the game object that it's connected to.

How does chipmunk know what to do? It doesn't, all it knows is that you have two solid objects in contact at a certain point and that they have a certain mass, etc. If you want the gas can to explode in some fancy way, you have to do so using the callback.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Post Reply