How to determine current substep inside internal callback?

[mreuvers]

Hi,

We use the internal callback to play SFX at collision impact etc. However the internal callback will be called multiple times if substep > 1. Is there any way to determine inside the internal callback, which substep Bullet is currently processing?

Then I can do stuff like:

if (substep == 1 && impulse > 10.0f)
{
playSFX("bla");
}

If I don't do that, the sfx will be triggered multiple times. I noticed that in my test project as well: the generated impulses seem to survive all substeps. So if one object collides with impulse 100, the next substep, that same object still reports an impulse of 100, causing multiple sfx to be triggered.

Or am I missing something here and is something fundamentally wrong with this design?

Cheers,


Martijn

[pico]

Hi Martijn,

in our game (like yours also wii) we do it differently. Instead of reporting contacts directly to the engine we do this after the physics is done. We collect each frame the generated contacts for each object and filter similiar contacts out. Similiar contacts are those with same or almost same normals. For each different normal we only keep the contact with the biggest impact. So you dont have to think about substeps in your game. This works very fine for our game.

regards

[chunky]

If I don't do that, the sfx will be triggered multiple times. I noticed that in my test project as well: the generated impulses seem to survive all substeps. So if one object collides with impulse 100, the next substep, that same object still reports an impulse of 100, causing multiple sfx to be triggered.

Or am I missing something here and is something fundamentally wrong with this design?

Mh. Fundamentally wrong here is that your sound will be framerate-dependant. Your code would effectively be starting the sound every graphical frame [assuming the typical canonical game loop].

I would suggest doing something like pico suggests. Put in a collision callback that maintains a list of all collision pairs, that you reset at the end of each frame/period of time/game clock tick. Each time you go to reset it, check to see what's in there, and spawn sound objects to reflect unique collisions.

Gary (-;

[mreuvers]

Thanks for the replies. So if I understand correctly, basically you're saying: don't use the internal tick callback. Fetch the contact manifolds after you updated the physics world and process everything from there?

In that case, why would one need the internal tick callback? Because I was under the assumption that the whole purpose of the callback and the CollisionInterfaceDemo was exactly this.

Thanks again!

[pico]

Thanks for the replies. So if I understand correctly, basically you're saying: don't use the internal tick callback. Fetch the contact manifolds after you updated the physics world and process everything from there?

In that case, why would one need the internal tick callback? Because I was under the assumption that the whole purpose of the callback and the CollisionInterfaceDemo was exactly this.

Thanks again!

Hi,

the tick callback is needed because the substeps will eventually clear out the results you are looking for.
So gather your information in the substeps, filter out unwanted information, supply those data to your gamecode when physics is done.

regards