Collisions on occasion seem to be missed using latest Build (2393)

[norman.rozental]

Hi all,

I’m relatively new to the Corona SDK and I’ve really *really* enjoyed using it so far.

I have been developing a game using build 2189 and the collision detection using this build was very accurate for my fast moving object.

I downloaded the latest build (2393) and with the *exact* same codebase I’ve noticed that on occasion collisions are not detected on the same fast moving object.  And I’ve also noticed that collision detections seem to be ever slightly more delayed than in build 2189.

I have had to slow down the fast moving object for every collision to be detected.  As you can imagine, this isn’t ideal as it effects the goal of the overall game play.  When I say ‘slow down’ I mean moving the object  less pixels (y value) every frame.  The game is set at 60 fps.

I guess my questions are:

1. Has anybody else noticed this behaviour in the latest build?

2. If yes, what did you do to overcome this behaviour?

3. Has there been any changes to the default settings of the physics engine regarding collisions and that maybe I should now be explicitly calling / setting some value to what is was in build 2189.

Any info would be greatly appreciated.

Norman.

[bjsorrentino]

Hi Norman,

Good to hear you’re enjoying Corona so far.

As the Box2D physics engine is updated internally, sometimes there are subtle nuances/changes in behavior. Can you provide some code showing your physics bodies, how you’re creating them, moving them, etc.? I can help assist you when I have more details on the scenario.

Best regards,

Brent

[norman.rozental]

Hi Brent,

Thanks for the response.

The following is how I’m creating my physics bodies:

physics.addBody(objectA,“dynamic”, {isSensor=true,density=0, bounce=0, friction=0})

physics.addBody(objectB, “dynamic”, {isSensor=true, density=0, bounce=0, friction=0})

There is only one objectB in the game and lots of objectA’s which are created every second moving across the screen.  I want to detect the collisions but don’t want any of the physics behaviour, hence isSensor = true.

Once there is a collision between objectA and objectB I move objectA out of the screen.  That’s about it really.

objectB is being moved 35 pixels every key frame when touching the device.   If I reduce this amount (say to about 15 pixels every key frame, objectB moves slower and so *all* collisions seem to be detected with objectA.  However this reduced speed effects the game play and not something I’d want to do.

So my problem is when viewing the app using setDrawMode(“debug”) I can actually see objectB and objectA colliding, however there on occasion there is no collision detected (call back isn’t called).  This never happened in the build 2189.

One thing to note is that objectA is part of a displayGroup but again, with the same bit of code, collisions were never missed in build 2189.  I need to it to be part of the displayGroup as I need to know about other objects in the displayGroup when there is a collision so I’d rather not remove it from the displayGroup etc.

The above might not be enough info to help.  Can I send you the code to an e-mail perhaps?  Or a video of what I’m experiencing?

[bjsorrentino]

Hi Norman,

Are you, by chance, moving the display group containing these "objectA"s independently of the display group that contains “objectB”?

What are the general sizes of these objects? Are any of them extremely small/thin, as in just a few pixels in either direction?

Brent

[norman.rozental]

G’day Brent,

Yes, the objectA display group is moving independently of objectB (objectB is NOT a display group).

The size of the objectA display group is about 800 pixels high x 100 pixels wide.  objectB is 2000 pixels high x 100 pixels wide.

Norm.

[bjsorrentino]

Hi Norm,

Just to confirm, you’re actually moving/shifting/transitioning the entire display group that contains the objectAs? Or are you simply moving those objects, but the group itself remains intact (in its original position)?

Brent

[norman.rozental]

Hi Brent,

I am moving each of the objects that make up the display group individually.  So in the method that is called every frame (“enterFrame”) I am iterating over these display groups and getting each display groups children and moving them across the screen by updating each of their ‘x’ property.

So I am not moving the group at all.  Only adding objects to each group and moving each child that makes up the group.

Each display group is created every second and I’m adding 3 objects to this display group.  These 3 objects are stacked vertically (a bit like 3 crates on top of each other).  When I was referring to ‘objectA’, I was actually talking about the top most object (the top most crate for example) which can collide with ‘objectB’.  My apologies for not being clearer.

Each crate is added to the physics world as:

physics.addBody(topCrate , “dynamic”, {isSensor=true,density=0, bounce=0, friction=0})

In addition, the top most crate is a sprite because I change the sprite sequence / frame to a different image when there is a collision which works great (when a collision is detected).

There is only one objectB in the whole game (which is also a sprite because when there is a collision I want to change objectB’s image accordingly)

objectB is added to the physics world as:

physics.addBody(objectB, “dynamic”, {isSensor=true, density=0, bounce=0, friction=0})

So what I’m experiencing is that in most cases the collision between objectB and objectA (top most crate) is being reported but sometimes even when objectB overlaps objectA (top most crate) by about 30 pixels, NO collision is reported.  objectB is moving pretty quickly (~ 35 pixels per frame).  If I slow the speed down of how fast objectB is moving (say 10 pixels per frame) it seems ALL collisions are reported.

In the previous build of the SDK, collisions were detected as soon as an overlap occurred even when objectB moved 35 pixels per frame using the exact same code as I have now.

I hope that is a little clearer of what I’m actually doing and trying to achieve.   And I truly appreciate your help thus far.

Norm.

[bjsorrentino]

Hi Norm,

Thanks for the very detailed description… this is especially helpful when trying to isolate physics behavior. Out of curiosity, have you done the “typical” things that can may help when dealing with fast-moving physics objects? For example, setting the “objectB” as a bullet type?

http://docs.coronalabs.com/api/type/Body/isBullet.html

Also, how about increasing the collision detection position/velocity iterations? These things can have a performance impact if you set them too high, but for one main object (objectB) it should be fine to increase them.

http://docs.coronalabs.com/api/library/physics/setPositionIterations.html

http://docs.coronalabs.com/api/library/physics/setVelocityIterations.html

Give these things a try and see how it works for you.

Also, I don’t think you mentioned: exactly how big is the top-most piece of “objectA” and “objectB” in this scenario? Meaning, their actual body sizes (not the display group)?

Brent

[norman.rozental]

G’day Brent,

I tried isBullet which I didn’t know about so thanks for that bit of great info!  It seemed to improve the ‘snappiness’ of the collisions a little.  I’m pretty sure that it did something which was a good starting point.  However there was the occasional missed collision when I knew there was one.

I tried the setPositionIterations when I first encountered the problem last week however this didn’t really help either.

I then read another an article published by another great staff member at Corona SDK talking about physics issues with high speed objects and it touched upon the physics.setScale() and that one should play around with this value with largish objects.  Since my objectB was very long (2000 pixels high) I thought this might be worth looking into further.  Note, I did not include this method in my code previously.

So I added physics.setScale(60) which didn’t help much (instead of the default value of 30).  Then I tried a value of 260 just mucking around and BANG!  I’m finally getting the behaviour I was getting a few releases ago.  No more ‘missed’ collisions.  The collisions are snappy.  As soon as there is a tiny collision overlap a collision is detected which is fantastic!

I removed the isBullet=true code to make sure it was or wasn’t needed and it looks like it isn’t needed.

So with the setScale(260) call it’s now behaving as expected.  So I thank your for you time and patience understanding my problem.  I’m pretty sure that it’s been solved so now I can continue finishing my game!

[bjsorrentino]

Hi Norman,

Good to hear you’re enjoying Corona so far.

As the Box2D physics engine is updated internally, sometimes there are subtle nuances/changes in behavior. Can you provide some code showing your physics bodies, how you’re creating them, moving them, etc.? I can help assist you when I have more details on the scenario.

Best regards,

Brent

[norman.rozental]

Hi Brent,

Thanks for the response.

The following is how I’m creating my physics bodies:

physics.addBody(objectA,“dynamic”, {isSensor=true,density=0, bounce=0, friction=0})

physics.addBody(objectB, “dynamic”, {isSensor=true, density=0, bounce=0, friction=0})

There is only one objectB in the game and lots of objectA’s which are created every second moving across the screen.  I want to detect the collisions but don’t want any of the physics behaviour, hence isSensor = true.

Once there is a collision between objectA and objectB I move objectA out of the screen.  That’s about it really.

objectB is being moved 35 pixels every key frame when touching the device.   If I reduce this amount (say to about 15 pixels every key frame, objectB moves slower and so *all* collisions seem to be detected with objectA.  However this reduced speed effects the game play and not something I’d want to do.

So my problem is when viewing the app using setDrawMode(“debug”) I can actually see objectB and objectA colliding, however there on occasion there is no collision detected (call back isn’t called).  This never happened in the build 2189.

One thing to note is that objectA is part of a displayGroup but again, with the same bit of code, collisions were never missed in build 2189.  I need to it to be part of the displayGroup as I need to know about other objects in the displayGroup when there is a collision so I’d rather not remove it from the displayGroup etc.

The above might not be enough info to help.  Can I send you the code to an e-mail perhaps?  Or a video of what I’m experiencing?

[bjsorrentino]

Hi Norman,

Are you, by chance, moving the display group containing these "objectA"s independently of the display group that contains “objectB”?

What are the general sizes of these objects? Are any of them extremely small/thin, as in just a few pixels in either direction?

Brent

[norman.rozental]

G’day Brent,

Yes, the objectA display group is moving independently of objectB (objectB is NOT a display group).

The size of the objectA display group is about 800 pixels high x 100 pixels wide.  objectB is 2000 pixels high x 100 pixels wide.

Norm.

[bjsorrentino]

Hi Norm,

Just to confirm, you’re actually moving/shifting/transitioning the entire display group that contains the objectAs? Or are you simply moving those objects, but the group itself remains intact (in its original position)?

Brent

[norman.rozental]

Hi Brent,

I am moving each of the objects that make up the display group individually.  So in the method that is called every frame (“enterFrame”) I am iterating over these display groups and getting each display groups children and moving them across the screen by updating each of their ‘x’ property.

So I am not moving the group at all.  Only adding objects to each group and moving each child that makes up the group.

Each display group is created every second and I’m adding 3 objects to this display group.  These 3 objects are stacked vertically (a bit like 3 crates on top of each other).  When I was referring to ‘objectA’, I was actually talking about the top most object (the top most crate for example) which can collide with ‘objectB’.  My apologies for not being clearer.

Each crate is added to the physics world as:

physics.addBody(topCrate , “dynamic”, {isSensor=true,density=0, bounce=0, friction=0})

In addition, the top most crate is a sprite because I change the sprite sequence / frame to a different image when there is a collision which works great (when a collision is detected).

There is only one objectB in the whole game (which is also a sprite because when there is a collision I want to change objectB’s image accordingly)

objectB is added to the physics world as:

physics.addBody(objectB, “dynamic”, {isSensor=true, density=0, bounce=0, friction=0})

So what I’m experiencing is that in most cases the collision between objectB and objectA (top most crate) is being reported but sometimes even when objectB overlaps objectA (top most crate) by about 30 pixels, NO collision is reported.  objectB is moving pretty quickly (~ 35 pixels per frame).  If I slow the speed down of how fast objectB is moving (say 10 pixels per frame) it seems ALL collisions are reported.

In the previous build of the SDK, collisions were detected as soon as an overlap occurred even when objectB moved 35 pixels per frame using the exact same code as I have now.

I hope that is a little clearer of what I’m actually doing and trying to achieve.   And I truly appreciate your help thus far.

Norm.

[bjsorrentino]

Hi Norm,

Thanks for the very detailed description… this is especially helpful when trying to isolate physics behavior. Out of curiosity, have you done the “typical” things that can may help when dealing with fast-moving physics objects? For example, setting the “objectB” as a bullet type?

http://docs.coronalabs.com/api/type/Body/isBullet.html

Also, how about increasing the collision detection position/velocity iterations? These things can have a performance impact if you set them too high, but for one main object (objectB) it should be fine to increase them.

http://docs.coronalabs.com/api/library/physics/setPositionIterations.html

http://docs.coronalabs.com/api/library/physics/setVelocityIterations.html

Give these things a try and see how it works for you.

Also, I don’t think you mentioned: exactly how big is the top-most piece of “objectA” and “objectB” in this scenario? Meaning, their actual body sizes (not the display group)?

Brent

[norman.rozental]

G’day Brent,

I tried isBullet which I didn’t know about so thanks for that bit of great info!  It seemed to improve the ‘snappiness’ of the collisions a little.  I’m pretty sure that it did something which was a good starting point.  However there was the occasional missed collision when I knew there was one.

I tried the setPositionIterations when I first encountered the problem last week however this didn’t really help either.

I then read another an article published by another great staff member at Corona SDK talking about physics issues with high speed objects and it touched upon the physics.setScale() and that one should play around with this value with largish objects.  Since my objectB was very long (2000 pixels high) I thought this might be worth looking into further.  Note, I did not include this method in my code previously.

So I added physics.setScale(60) which didn’t help much (instead of the default value of 30).  Then I tried a value of 260 just mucking around and BANG!  I’m finally getting the behaviour I was getting a few releases ago.  No more ‘missed’ collisions.  The collisions are snappy.  As soon as there is a tiny collision overlap a collision is detected which is fantastic!

I removed the isBullet=true code to make sure it was or wasn’t needed and it looks like it isn’t needed.

So with the setScale(260) call it’s now behaving as expected.  So I thank your for you time and patience understanding my problem.  I’m pretty sure that it’s been solved so now I can continue finishing my game!