Good way to get informed about collision (e.g. for sound)

B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Good way to get informed about collision (e.g. for sound)

Post by B_old »

Hi,
I am looking for a good way to generate some (audio-)feedback for colliding objects.
There is an article that talks about collision feedback. Reading it, gContactAddedCallback sounds like just the thing I'm looking for, however the article seems to be a bit discouraging about callbacks if you don't really need them. I suppose I don't really need them, as I don't want to change friction properties or something like that.

I guess I'm looking for a kind of best practice. Suppose I would like to play a sound every time a object collides with another object hard enough. Should I use gContacAddedCallback or manually iterate through all Manifolds? In case of the latter, how do I know that the contact is new?
ola
Posts: 169
Joined: Sun Jan 14, 2007 7:56 pm
Location: Norway

Re: Good way to get informed about collision (e.g. for sound)

Post by ola »

I tried both methods. I found it best to iterate over the contact manifolds. You can also combine it by checking for other things that should happen when two objects collide, like sensor handling, triggering events in a script engine, etc.

You should do this after each internal sub-step Bullet does, there is a callback you can register for this, see btDynamicsWorld::setInternalTickCallback(btInternalTickCallback cb, void* worldUserInfo=0).

Each manifold point inside a manifold has a lifetime member variable (m_lifeTime) which is an integer telling you the age in iteration steps. Right now I play a sound when m_lifeTime is less than 3 and m_appliedImpulse is larger than some threshold.

Less than 3 is because the solver is iterative, and I only want sounds played for the stronger impulses which might need some iterations to build up. But you could check if it is 0 or 1 instead of course, depends what you're after.

Best regards,
Ola
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

Thanks for the answer!
One thing I was wondering, is whether it is not actually slower to iterate through every manifold instead of just reacting to the callback.

What is the impulse threshold you are looking for? This might be a useless question as it is very dependent on other parameters, but I found, that a cube falling on a static plane doesn't "generate" much impulse. If I let another cube fall on the first one I get some impulses that are 10 times higher. This confuses me.

How do you avoid playing a sound several times in very short succession, for example when the cube has 4 contact-points or something.
ola
Posts: 169
Joined: Sun Jan 14, 2007 7:56 pm
Location: Norway

Re: Good way to get informed about collision (e.g. for sound)

Post by ola »

It might be slower but I think it's absolutely negligible. At least in my case there aren't that many contacts at a given moment (most dynamic objects are asleep), and even if there were, it's just a quick for loop. Just try to profile it against all the other stuff that goes on in the game engine.

I think I had some issues with figuring out how to find the data on the accumulated impulses when using the contact callbacks, it rarely happened that the impulse from the first iteration was the one strong enough to trigger a sound. (it's a while ago)

Right now my impulse threshold is at 50, but it will depend on the mass of your objects, I would think. So just experiment with them. To prevent re-triggering a sound, I have some logics built into the sounds being triggered, so that they won't rewind and play again before having reached some time since the last time a play was triggered.

It's not really perfect, I only had a couple of days to implement it. So there might be ways to do it better too... :-)

Best regards,
Ola
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

So I tried looping through all the manifolds. Interestingly enough it gives different impulse-values compared to the ContactAdded Callback. It works better for me, too. Maybe I encountered the same problem as you.
In fact, when I filter out stuff with lifetime > 1 the results are really not bad. I wonder if it really is necessary to keep a separate list of new contacts, as some have suggested in another thread of this board.
Thanks a lot for the help.

Another, only slightly related question: When I have the two objects of the contact manifold, does it mean something, that one is Body0 and the other one Body1? Specifically, I would like to know which body bumped into the other one, if that makes sense.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Good way to get informed about collision (e.g. for sound)

Post by Dragonlord »

It's like in real life. If two cars bump into each other, which one has been the cause? If both objects are moving it's impossible to tell anyways so no real loss there. If one is resting though it's simple. In general just take game logic. Usually you consider objects to bump into the player and not vice versa. If both objects though are equal in importance there's way to tell.
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

But one car could be moving faster than the other one.
In my test, body0 would always be the dynamic body when a dynamic body was colliding with a static one.
When 2 moving bodies were colliding body0 would have the higher velocity most of the time, but I assume that this a coincidence.

I imagine a wooden ball falling on a stone-floor sounds different compared to a stone-ball falling on a wooden floor.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Good way to get informed about collision (e.g. for sound)

Post by Dragonlord »

What I mean with this is simply that I don't care about the ordering. I check body1 and body2 for certain properties ( in my case if it's a terrain object or an AI object ) and then do things accordingly. You can very well say the faster object is the moving one. I would simply not expect the body1 to be the moving body. I'm not sure how Bullet handles this but to my knowledge the order can be anyhow so you need to rely on game logic or rules like the one mentioned by you to figure out what to do. Is also more stable if things change in Bullet for one reason or the other.
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

I just thought it could be interesting to know which object hit the other one (so to speak) with regard to sound.

I'm getting a little off-topic here but I might as well ask while we have the thread going: What does the distance that you can get of the contact point signify? It seems that it can be positive or negative. I believe it was suggested that it could be useful for sound effects but I don't really understand what it stands for. Is there a intuitive description/explanation?

EDIT: I believe I know now. It is the distance between the collisiontpoints on the colliding objects. And it is negative if the objects overlap. Is this correct? Hm, it doesn't really jump at me, what I should/could do with this and sound.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Good way to get informed about collision (e.g. for sound)

Post by Dragonlord »

Regarding sound it doesn't matter if material A hits material B or vice versa. The sound is usually the same. Just take a spanner and a small plastic box. No matter if oyu hit the spanner against the box or the box against the spanner the sound is the same ( if your velocity and hit point is identical, which it won't be :P ). Hence what is only important in a collision is which two materials collide and at which velocity. More parameters can be added but those three ( <materialA,materialB,velocity> ) define usually the sound to use. What goes for the distance I'm not sure now but as far as I know if the absolute distance is larger than an epsilon the objects hit each other ( as they usually slightly penetrate in this case ). If the distance is though close to 0 they rest on each other ( which should not generate a sound ) or are sliding. Obviously hitting and sliding sounds different. But usually the velocity is enough to figure out what kind of sound to play ( sound only if length velocity larger than epsilon, sliding sound if velocity*normal roughly 0 ).
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

I see were you are coming from. But image the situation I was describing earlier: A wooden ball falls on a stone-plate. Now a stone-ball falls on a wooden plate. Certainly they produce different sounds. How would you model that? Maybe it is not so important to have that difference. Just looking for opinions.
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Good way to get informed about collision (e.g. for sound)

Post by Dragonlord »

The problem you describe is though not related to what hits what but the constitution of the two bodies. The ball has a lot smaller volume than the floor. Hence what you have in fact is <volumeA,materialA,volumeB,materialB>. Again what hits what is not important. What is important is the actual mass involved in the collision. So take two balls one of wood and one of stone. Here too it doesn't matter which ball hits the other. Important is the volume of the two balls since this determines which energy clashes in the collision. In fact your system takes the volume or mass of an object into account but the effect you observe stems from this additional parameter not from what hits what.

EDIT:
The reason why it doesn't matter which object moved is due to the relativity of movement. It depends on the inertia system I track two objects with. The physics have to apply in all inertia systems I can pick and this especially means I can pick a system A where the ball A is in motion or a system B where the ball B is in motion ( and the other ball at rest ). Since both situations have to give in the same result ( in terms of motions of the balls ) only the materials and properties at the time of impact can have any influence since the velocities would be different in all systems.
B_old
Posts: 79
Joined: Tue Sep 26, 2006 1:10 pm

Re: Good way to get informed about collision (e.g. for sound)

Post by B_old »

Yes, you are right. Thanks for the explanation, Dragonlord. And thanks for the answers of everyone.