Collision callbacks questions

[Erwin Coumans]

The best way is to use a btGhostObject, and then iterate over its overlapping pairs (not ALL pairs in the world), and get the contact manifolds from each overlapping pair. The Bullet/Demos/CharacterDemo shows how to use the btGhostObject. It would be nice to have another demo that shows how to use the btGhostObject.

The second best is to iterate over ALL contact manifolds, as described in Bullet/Demos/CollisionInterfaceDemo.

Using the contact added callback is not designed for triggering (game) logic, but mainly to override internal settings such as friction values or contact normals etc. Such callbacks might not even be available, especially when the collision detection happens on SPU (PlayStation 3) or GPU (upcoming OpenCL version of Bullet 3.x).
The Bullet/Demos/MultiMaterialDemo is an example how to use those callbacks to adjust friction.

My question is still about a collision detect signal. I'm using 2 std::maps in order to store new and old contacts

Each contact point has a m_lifeTime variable, you should be able to use that to determine if the contact is new or not. Searching a map shouldn't be necessary.

but I get some problems with rigid bodys that are within other bodys.

What kind of collision shape are those 'other bodies' using? If an object is entirely embedded inside a hollow concave shape such as a Gimpact, btCompoundShape or btBvhTriangleMeshShape, without touching any of its triangles/children, no collision is reported.

So the main problem is that people refuse to iterate over ALL contact manifolds, because of performance issues?
If so, do you have some profiling info that shows that shows the cost of iterating over ALL contact manifolds one single time?

Thanks,
Erwin

[AlexSilverman]

Such callbacks might not even be available, especially when the collision detection happens on SPU (PlayStation 3) or GPU (upcoming OpenCL version of Bullet 3.x).

Not to take this thread too far off topic, but is that to say that the function won't get called, or simply that the function won't be available to the game in the way that it is now?

Thanks.

- Alex

[Zeal]

The best way is to use a btGhostObject

I can see ghost objects working well for things like power ups, ect, but what if you want a sound effect to be triggered when a spaceship bounces off a wall. Should the wall be a ghost object? I dont have much experience with btGhostObject, I always assumed (due to the name) that such objects are transparent / 'ghosty', and dont really affect other bodies in the scene? The more I look at them, it seems they are simply 'rigid bodies with more features' (specifically, the ability to track overlapping objects).

Am I close?

[sparkprime]

I am also confused by this... Why would we need to add a ghost object when bullet already knows which rigid bodies have collided with which? The contactAddedCallback seems like a good bet... Is there more information in the manifolds than one can get via contactAdded?

[Zeal]

Has anyone figured out the 'official word' on this?

[Erwin Coumans]

Has anyone figured out the 'official word' on this?

The official word is to just iterate over the contact manifolds. You should be able to do iterate over all contact manifolds a single time for each frame, no multiple iterations should be needed.

but what if you want a sound effect to be triggered when a spaceship bounces off a wall. Should the wall be a ghost object?

No, just iterate over the contact manifolds.

Is there more information in the manifolds than one can get via contactAdded?

Yes. The contact manifolds keep track of up to 4 contact points, while a contactAddedCallback only provides info for a single contact point. And it is not good practice to interleave the innerloop of the collision detector with game code.

If iterating over all contact manifolds is really to slow, please create a reproduction case in one of the Bullet demos to show that we need a better solution.
Thanks,
Erwin

[sparkprime]

Interesting, OK I think I have a good picture now.

Here are some things I'd like to implement:

1) Sounds, sparks, dust etc on particularly nasty collisions:

2) Things destroyed / otherwise reacting to being crushed or rammed.

3) Pressure pads, automatic doors, teleporters, powerups

4) Explosions -- check contacts with a huge sphere, shoot rays, if unoccluded apply inverse-r-squared impulses.

5) Having no friction for some components of a compound shape

6) Telefragging (detect if you're going to spawn or teleport into space already occupied by an existing object)

It seems (1) and (2) are text-book applications of the contact manifold iteration technique. By doing the iteration after the internal step (not during it) it is possible to remove bodies from the world, which is useful for implementing destruction.

and (3) is a text-book application of the ghost object -- the ghost object would be an entirely separate shape to whatever object is representing the trigger in the game.

(4) was the subject of a forum post a while ago, it seemed to work well judging by the videos presented. This would also be a ghost object, right? Explosions are not really instantaneous -- they last at least a couple of physics ticks. It ought to be possible to simply insert a big solid sphere and the resultant collision resolution would push things away from the explosion, but I think this would not look good. Big heavy things would be propelled away too fast when they ought to be just knocked slightly. Another option is just to shoot a few hundred regularly spaced rays in an isosphere configuration. But I expect the performance would not be as good. Any comments Erwin?

(5) is a material thing -- it would be the contactAddedCallback that deals with this.

(6) depends whether the destination is static -- if it is static then a ghost object would be perfect here. If the destination is chosen randomly each time then it needs to be an explicit collision query because you can't wait until the next physics tick to put a ghost object into the scene and allow the pairs to accumulate.


In summary:

It seems if you want to detect collisions between 'real' bodies -- do the contact manifold iteration. If you want to know about the amount of intrusion into a given space, then use an explicit collision query, possibly accelerated through use of a ghost object.

[Erwin Coumans]

Here are some things I'd like to implement:

1) Sounds, sparks, dust etc on particularly nasty collisions:
2) Things destroyed / otherwise reacting to being crushed or rammed.
3) Pressure pads, automatic doors, teleporters, powerups
4) Explosions -- check contacts with a huge sphere, shoot rays, if unoccluded apply inverse-r-squared impulses.
5) Having no friction for some components of a compound shape
6) Telefragging (detect if you're going to spawn or teleport into space already occupied by an existing object)

It seems (1) and (2) are text-book applications of the contact manifold iteration technique. By doing the iteration after the internal step (not during it) it is possible to remove bodies from the world, which is useful for implementing destruction.

and (3) is a text-book application of the ghost object -- the ghost object would be an entirely separate shape to whatever object is representing the trigger in the game.

(4) was the subject of a forum post a while ago, it seemed to work well judging by the videos presented. This would also be a ghost object, right? Explosions are not really instantaneous -- they last at least a couple of physics ticks. It ought to be possible to simply insert a big solid sphere and the resultant collision resolution would push things away from the explosion, but I think this would not look good. Big heavy things would be propelled away too fast when they ought to be just knocked slightly. Another option is just to shoot a few hundred regularly spaced rays in an isosphere configuration. But I expect the performance would not be as good. Any comments Erwin?

(5) is a material thing -- it would be the contactAddedCallback that deals with this.

(6) depends whether the destination is static -- if it is static then a ghost object would be perfect here. If the destination is chosen randomly each time then it needs to be an explicit collision query because you can't wait until the next physics tick to put a ghost object into the scene and allow the pairs to accumulate.

In summary:

It seems if you want to detect collisions between 'real' bodies -- do the contact manifold iteration. If you want to know about the amount of intrusion into a given space, then use an explicit collision query, possibly accelerated through use of a ghost object.

Exactly. This info should go into the manual, wiki and into a demo.

Only use btGhost acceleration if the query location is the same for at least a few frames, otherwise its pair caching isn't helping much.
Thanks,
Erwin

[Zeal]

By doing the iteration after the internal step (not during it) it is possible to remove bodies from the world

Wait so WHERE should you be iterating over all manifolds? Are you referring to what is talked about in the manual (using a 'broadphase' callback)...

btOverlapFilterCallback * filterCallback = new YourOwnFilterCallback();
dynamicsWorld->getPairCache()->setOverlapFilterCallback(filterCallback);

??

Only use btGhost acceleration if the query location is the same for at least a few frames, otherwise its pair caching isn't helping much.

So if you wanted to determine what bodies exist within a certain area (say for a explosion effect), you WOULDNT just pop a primitive ghost object into the simulation for one frame, then delete it? That seems like the most efficient way to do it, but youre saying there is a better way to do 'single frame area checks'?

[sparkprime]

By doing the iteration after the internal step (not during it) it is possible to remove bodies from the world

Wait so WHERE should you be iterating over all manifolds? Are you referring to what is talked about in the manual (using a 'broadphase' callback)...

I dunno about that but I was thinking of doing it between internal steps -- looking at the persistant state, essentially. Collisions that have either just begun or are ongoing.

btOverlapFilterCallback * filterCallback = new YourOwnFilterCallback();
dynamicsWorld->getPairCache()->setOverlapFilterCallback(filterCallback);

??

Only use btGhost acceleration if the query location is the same for at least a few frames, otherwise its pair caching isn't helping much.

So if you wanted to determine what bodies exist within a certain area (say for a explosion effect), you WOULDNT just pop a primitive ghost object into the simulation for one frame, then delete it? That seems like the most efficient way to do it, but youre saying there is a better way to do 'single frame area checks'?

You can do a simple "does shape x at transform x' intersect with shape y at transform y'" query. This is fairly fast but not very useful because you typically don't know what is colliding with what. Checking if x collides with every possible y is more useful but is quite slow. The way the broadphase works is it maintains a set of pairs of things that could possibly be colliding. It's designed to avoid having to check with every singly y object. It builds up this pair set over several frames and maintains it, spending only a little time each frame. The ghost object is a way to utilise the broadphase to cut down the number of objects you need to do the collision test against. So it's not useful generally for such 'instantaneous' queries. Whether or not an explosion is 'instantaneous' is debatable.

[Shaul Kedem]

Hi,

The official word is to just iterate over the contact manifolds. You should be able to do iterate over all contact manifolds a single time for each frame, no multiple iterations should be needed

I know Erwin wrote this should be in the wiki/demo/etc, but can anyone give a basic example of how to run through the contact manifolds? I assume the intention is to run through them before calling stepSimulation?

Thanks,
Shaul

[Flix]

can anyone give a basic example of how to run through the contact manifolds? I assume the intention is to run through them before calling stepSimulation?

Well, I posted an example (a modified BasicDemo) some time ago. You should be able to download it here (if this forum allows direct links to files):
http://www.bulletphysics.org/Bullet/php ... php?id=343

It's very easy to integrate my code in every existing application.

I used the "action interface" that it's called once every inner timestep (but in my Ogre implementation I subclassed the physic world instead).

Hope it helps.

P.S. The Bullet Forum page where the file is present is this: http://www.bulletphysics.org/Bullet/php ... 91&start=0

[Shazboots]

Hi I have a question out collision masks...

Say I have two objects types: spaceship and powerup

I would like to have it so that spaceships don't hit powerups, but that powerups do hit spaceships(just triggers a callback).

I can't see any way to do this with the current masking system as it seems to require that both objects hit each other to work at all. If one wishes to hit the other, but the other
does not wish to hit it... no manifold is every generated.

[sparkprime]

Filter the collision in your own callback. At the end of the day it doesn't make sense for the hammer to touch the nail without the nail touching the hammer. If you want only one object to react to the collision then sort everything out in your own code.