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?
Overlapping sensors - Box2D order / behavior
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Overlapping sensors - Box2D order / behavior
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.
Re: Overlapping sensors - Box2D order / behavior
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?
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?
Re: Overlapping sensors - Box2D order / behavior
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.
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.
Re: Overlapping sensors - Box2D order / behavior
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.
(Attached main.lua is just for this visualization, not using Box2D.)
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.
(Attached main.lua is just for this visualization, not using Box2D.)
- Attachments
-
- main.lua
- (871 Bytes) Downloaded 30 times
Re: Overlapping sensors - Box2D order / behavior
Here's another demo that actually uses physics bodies.
- Attachments
-
- main.lua
- (2.97 KiB) Downloaded 30 times
Re: Overlapping sensors - Box2D order / behavior
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( )
Current project:
https://togfox.itch.io/hwarang
A card game that brings sword fighting to life. Simple to learn, hard to master. Learn when to advance, dodge, strike and counter. Learn how to strike without being struck.
https://discord.gg/HeHgwE5nsZ
https://togfox.itch.io/hwarang
A card game that brings sword fighting to life. Simple to learn, hard to master. Learn when to advance, dodge, strike and counter. Learn how to strike without being struck.
https://discord.gg/HeHgwE5nsZ
Re: Overlapping sensors - Box2D order / behavior
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 :-)
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 :-)
Re: Overlapping sensors - Box2D order / behavior
My current project (see signature) uses box2d. Some of that code might be useful - or simply confusing.
Current project:
https://togfox.itch.io/hwarang
A card game that brings sword fighting to life. Simple to learn, hard to master. Learn when to advance, dodge, strike and counter. Learn how to strike without being struck.
https://discord.gg/HeHgwE5nsZ
https://togfox.itch.io/hwarang
A card game that brings sword fighting to life. Simple to learn, hard to master. Learn when to advance, dodge, strike and counter. Learn how to strike without being struck.
https://discord.gg/HeHgwE5nsZ
Who is online
Users browsing this forum: No registered users and 6 guests