sensors reporting begin collision repeatedly

[David Kalina]

Hi Scott!

Just upgraded to 5.3.1 and noticed an apparent issue with the way sensors are handled.

I use sensors fairly liberally in my game: the player uses sensor shapes to detect collisions with other physically relevant game objects, but is not simulated by Chipmunk because I need to move him around manually.

Also, objects that are in some dormant-waiting-for-collision type state are typically sensors. (e.g., a stalactite that plays an animation and then becomes physical when another physical object bumps into it).

Anyway, I occasionally use player vs physics-object collisions to apply impulse to the physics-object on the Begin collision event, but Begin is getting called for every frame of collision between my player character's sensor shape and any physics shape it collides with.

Certainly I can code around this, but it sounds like unexpected behavior?

Thanks,
David

[slembcke]

Yeah, that's definitely a bug.

I'm a bit pressed for time at the moment with some contract work. It would be tremendously helpful if you can modify or overwrite one of the demos to replicate the behavior as simply as possible.

[David Kalina]

Hi Scott,

I modified the Sensors demo (see attached -- I tagged the modifications with 'dkalina') so that it spawns one body into a space with no gravity overlapping the sensor shape.

You can put a breakpoint in blockerBegin and it will hit repeatedly when you run the demo.

Now .. maybe I'm not understanding how this is supposed to work, because initially you were returning cpFalse in that function, which hid the problem (and may in fact be an acceptable solution for my use of sensors). From the docs on collision-begin callbacks:

"Return true from the callback to process the collision normally or false to cause Chipmunk to ignore the collision entirely."

So .. by returning false, we ignore the collision entirely, which means we won't get future collision events for this pair.

But even if the return value is true, as it is in the version I'm posting, we still should only receive the begin callback one-time per collision pair, right?

Thanks for taking a look,
David

[slembcke]

Yes, you should only get one begin callback per pair even if you return false from the begin callback. This is definitely a bug.

I ran the code you posted and I think I see what the issue is. It's because of the new object sleeping code, so it might be tricky to fix. No promises, but I'll try to look at it tonight. Otherwise it will be a week or so until the contract I'm working on is done.

[slembcke]

I think I have a solution, but I didn't have time to test it thoroughly and didn't want to commit it to trunk. Add the following line to the very end of queryFunc() in cpSpace.c.

Code: Select all

if(sensor && arb->state = cpArbiterStateFirstColl) arb->state = cpArbiterStateNormal;

Not the cleanest workaround, but it seems to work. If you run into new issues from it let me know.

[David Kalina]

I'm guessing that's supposed to be a == in the conditional
Gonna plug it in and test it out now. Thanks, Scott!

[David Kalina]

Now, if I have the collision-begin callback return 0 (to ignore this collision), the object will continue to receive collision-begin events (and continue returning 0).

But if I have the callback return 1 (to accept the collision), I no longer receive collision-begin events between a sensor and the static geometry it's resting on. So that's good.

Not sure if the first part is as designed...?

[slembcke]

Ugh. Nope. Looks like it needs more special cases.

I'm hoping to find a more general solution to this, but so far I haven't had time to think about it much.

[slembcke]

I found another related bug today and found a slightly nicer solution that fixes both. \o/ The fix is now in trunk.

Now, if I have the collision-begin callback return 0 (to ignore this collision), the object will continue to receive collision-begin events (and continue returning 0).

I was never able to reproduce this. Is the bug still there and I just didn't understand?