Overlapping sensors - Box2D order / behavior

[dusoft]

I have two overlapping sensors using love.physics module.
Let's call them speed 10 and speed 20.

It seems that Box2D model will not properly test for collisions when sensors are overlapping. E.g. body going from speed 10 to speed 20 (while speed 20 overlaps speed 10 sensor) will not report collision for speed 20. Entering of speed 10 and then leaving of speed 10 is reported, but no entering of speed 20 (as the body is already in the overlapping speed 20...). When entering from outside to speed 20, it is correctly reported.

Is sensor overlapping a no-go or should I be using different callback than begin/end contact? (e.g. pre/post-solve)

Another option would be to build a stack of sensors and remove them on leaving each. If stack contains a sensor, then it still applies.

Any ideas?

[dusoft]

OK, so now I have created touching sensors (e.g. not overlapping, but having one pixel (one line) in common) and I am getting the same results. I will have to experiment with pre/post-solve callbacks. I'll be glad to accept any suggestions regarding this.

[Ross]

Sensor shapes will not cause preSolve and postSolve callbacks, only beginContact and endContact. Also one of the bodies must be dynamic to get any events at all. Other than that, overlapping sensors should work fine.

I don't quite understand what you are trying to do from your description, maybe you could post a screenshot or diagram or a love file example? If you create a body inside a sensor, you should get a beginContact call as soon as it is added, perhaps you are missing that?

[dusoft]

Indeed, a screenshot should help explaining it.
1 = speed 10
2 = speed 20
3 = speed 30

Arrows show how sensor overlap from the yellow border. Now, when going from outside through 3 to 1, I am getting correct collisions detected (e.g. 30,20,10). However, when starting in 1, I get all three collisions initially (on world creation), but then when moving from 1 to 3, I get no collisions, only collision end (contact end), because body was already in three overlapping regions / polygons.

But I am trying to change my approach via using touching trapezoids (polygons) instead. I'll need to investigate more how to make that work.

[Ross]

Aha, I think I see. So it's something like, if you had concentric circles, where the largest overlaps all smaller circles, and you want to know which "ring" a certain object is in. In that scenario it would simply be the smallest circle that the object is still overlapping.

You just need to use the begin- and end-contact events to keep a list of which areas your object is currently overlapping, and then the smallest one in that list will be the one you want.

screenshot_2024-03-14_15-01-28.png (9.5 KiB) Viewed 1477 times

(Attached main.lua is just for this visualization, not using Box2D.)

[Ross]

Here's another demo that actually uses physics bodies.

[togFox]

This might help. It checks which fixtures are colliding right now.

Code: Select all

local allcontacts = world:getContacts( )
	for k, contact in pairs(allcontacts) do
		if contact:isTouching() then
			local fixtureA, fixtureB = contact:getFixtures( )

[dusoft]

Thank you to you both.

I have changed my approach now to use non-overlapping trapezoids / polygons (that are touching as seen on the screenshot). This make it easier, but one thing is still tricky.

It seems that collision end callback for first sensor is called a second later than collision start for the second sensor. It makes sense as the body is actually larger than a one pixel border between sensors, so at one time it's over both sensors.

As I had speed enforcement removal on collision end of this sensor type, it would create this log:
(body in sensor 1)
maximum speed 10
(body enters sensor 2)
maximum speed 20
(body leaves sensor 1)
no maximum speed

I have fixed this by comparing last maximum speed (20 in this case, sensor 2) on collision end (10, sensor 1). If the speeds differ, I keep maximum speed without change. If the speeds are the same, I remove maximum speed enforcement.

Thanks again. Maybe this will help someone else as I think there are not many tutorials digging into depths of physics modules. Maybe I'll even write a tutorial myself :-)

[togFox]

My current project (see signature) uses box2d. Some of that code might be useful - or simply confusing.