Making sense of cpContact

[mcc]

So I have a game with something that is like a bouncy ball in it-- it's just a single circle shape and it has a high elasticity. And I want to do something that seems pretty simple, which is that I want it to make a noise whenever it bounces. So, I have a collisionpairfunc set up for the "ball" collision type, and what I am trying to do is make it so that the collisionpairfunc looks at all the contacts and if it finds that any one collision is sufficiently "strong", it signals the sound to start playing (such that the sound only triggers when it's bouncing, not when the ball is just sitting on the ground). The problem is that, as per the documentation and also the case for me about half the time experimentally, the fields I might use to determine how "strong' the bounce are-- the jnAcc and jtAcc fields-- apparently are not readable until after cpSpaceStep returns. The way I've been getting around this is that when my collisionpairfunc triggers, it adds a pointer to the contact to a queue, and then after cpSpaceStep returns I run through all the collisions in the queue and check whether any are strong enough to trigger a noise.

Anyway, what I was wanting to ask was:

1. Is this thing I'm doing with the queue safe-- I.E. to preserve pointers to contacts and assume they will still be valid after cpSpaceStep has been called?

2. Is there a better way to get the effect I want (I.E. collision handling that has access to the post-cpSpaceStep information)?

3. I'm not sure 100% how to interpret the data in cpContact. What exactly is the relationship between the "tangential" and "normal" collision impulse? Looking on Google they're apparently common terms, and the names seem to imply certain things, but I'm having trouble finding a specific definition...

4. I notice there are several fields in cpContact which are not listed in the documentation, for example "bounce" and "bias". Are these usable for any purpose?

Thanks!

I am using revision 222 of Chipmunk from the aerosol SVN.

[slembcke]

1) Yes. The contact struct will get freed no sooner than the next call to cpSpaceStep(). Because of the way the solver in Chipmunk works, this won't be changing any time soon.

2) I'd just use the relative velocity of the objects actually. That can be processed immediately during the callback and is closely related to the final impulse that gets applied.

3) In the case of chipmunk contacts, the normal impulse is what stops the objects from moving into each other while the tangential impulse keeps the objects from sliding across each other (friction).

4) They are cached values used by the solver, I'm not sure how they would be useful for anything else.

[mcc]

Thanks!

[digicide]

Sorry to bring up an old topic--

This is almost exactly the same thing I am trying to do: I want my objects to make noise when they collide with each other, but only if they're actually bouncing off each other. I'm experimenting with the objects' relative velocities as suggested, but I can't quite think of the kind of equation I should be after. Right now I'm using something like:

Code: Select all

cpVect relativeV = cpvsub(a->body->v, b->body->v);

if(hypot(relativeV.x, relativeV.y) > 50)
{
   //play sound
}

Actually I've got no idea if the hypot thing is even the right idea, but the problem with this approach is that it sees one object rolling on top of another as having a large relative velocity, even though it's not the kind of velocity that would result in a bouncing sound effect.

Does anybody know enough about this to point me in a better direction?

[digicide]

Um... sorry to bump, but... please? Anybody?

[slembcke]

Oh sorry. Looks like your post fell between the cushions on the couch and was forgotten like so much pocket change...

The dot product of the relative velocity with the collision normal will give you the speed that the objects are moving towards each other. Because the collision detection might have the normal pointing in the wrong direction for the order defined by the callback, so you'll also need to multiply by the normal_coef parameter passed to your callback.

Does that make sense?

[digicide]

Amazingly, yes... well, almost. I don't quite understand multiplying by the normal coefficient. I had thought that doing so would make all my speeds positive, but I was still getting some negative ones. That may be due to the biased way I'm figuring the relative velocity (which I'm doing with the cpvsub below):

Code: Select all

for(int i=0; i<numContacts; i++)
{
   cpFloat result = abs(normal_coef * cpvdot(cpvsub(a->body->v, b->body->v), contacts[i].n));
   printf("%f, ", result); 
   if(result > 50.0)
   {
      SoundEngine_StartEffect(_sounds[bounceSound]);
   }
}

I figured that for my application (playing a bounce sound) that just taking the absolute value would be good enough. Am I correct?
Thanks for the help-- you are really really smart.

[slembcke]

Well, Chipmunk returns the shapes in the order that the collision types were defined when the function was added. If that order is different than the order returned by the collision detection system, then the normal will point in an unpredictable direction. The normal coefficient is meant to help keep the direction consistent. If the relative velocity is negative even after multiplying by the normal coefficient then either something is wrong, or the objects are separating at the time the collision is detected (which is possible though less likely).

It should be pretty safe just to use the absolute value and ignore the normal coefficient altogether. I doubt that edge cases will happen often enough for people to notice really. You can also just use the normal from the first collision point. Currently the collision primitives in Chipmunk can only collide with a single normal. If I ever add concave collisions in the future that could change, but hopefully by then I'll have some extra API bits in place to help do what you're doing.

[shafijami]

Hi

Is there any version of PointInRect like in chipmunk. How do we know if a ball is inside a rectangle or another shape?

Shafi

[ker]

If you want to check for any shapes at some cpVect coordinates there is an undocumented point-query function. in the 4.1.x release you can find an example of it's usage in Demo/main.c:324

http://www.slembcke.net/forums/viewtopi ... ouse#p1070 << they also talk about it here


If you want to check shapes vs shapes you can look at the source of cpMouse (http://www.slembcke.net/forums/viewtopic.php?f=6&t=196).

Also: try to use the search function of the board first