physics shapes of small sizes are returning errors in build 2014.2332

Solar2D Daily Builds and Public Releases
#1

After having installed build 2332 I am getting the below errors from many my physics shapes where in all previous builds they worked fine.

physics.addBody() of a “shape” with no area, or nearly no area, has been rejected.

Whether this is due to maintenance on physics from corona’s side or tweaks in box2D I don’t know but it’s realy weird that all of a sudden very small shapes that previously had no issue are now considered  too small and therefor don’t even get created. 

This is a huge issue for me as many of my physics shapes need to be the size they are and can’t be bigger or it would mess up the whole game.

Is anyone else coming across this physics shape size error? I’m testing previous build versions to see exactly when these errors start appearing for small physics shapes.

 

 

 

 

 

#2

Hi @jacques1,

This is due to both physics maintenance and tweaks/changes in Box2D. Shapes with nearly no area were found to be causing other issues, i.e. being generated as large boxes offset from the intended location, so they were invalid in that form too. I’m not sure what shapes you’ve created that are being rejected, but the “nearly no area” flag should only be triggered for shapes extremely minuscule in size, such that they may not have even resulted in collision detection with other smaller shapes (or they would “dig in” to larger shapes before the frame-rate collision detection would “catch up”, which wouldn’t be accurate).

Can you show a screenshot (in “hybrid” or “debug” mode) of what kind of physics bodies you’re building in versions previous to #2332?

Brent

#3

Hi Brent,

thanks for the reply. I’ve attached a debug screen of physics objects from one of my game’s missions.

The smallest physics shapes I have at any time are of the below size for fences.

shape = {-1,-16,0,-16,0,16,-1,16}

In the attached image, you can see the fences are the very thin rectangles. All the really small dots are objects moving around the screen that need to be blocked by the fences if colliding.

Granted the fences are rather tiny but work perfectly fine in builds up to 2277 (i believe as of build 2281 box2d started acting weird due to box2d updates).

It wouldn’t make sense to have bigger physics shapes for the fences otherwise objects would appear to be blocked by the fences when they were no where near them. If there is now no way to do very small physics objects I guess I will be forced to remain using 2277 for my game.

#4

Hi @jacques1,

Yes, I see now. I don’t know the exact “threshold” of what is now considered “too small of an area” by Box2D, but you might be able to increase them by just 1-2 more pixels and get a generated fence shape without any noticeable oddness in the collisions. This would be my first suggestion to try. I have another possible idea, but I’m currently testing it, so let me know if the above option doesn’t work and I’ll see if there’s another method.

Brent

#5

Hi Brent,

I was working on an update for “Freeze!” and it was pure luck that I tested a level with laser rays in the simulator and I saw this error.

It was caused by my very thin lasers rays that until now worked just fine. But now they didn’t work at all anymore, it made the lasers kind of user-friendly & not deadly at all.

Of course, it was an easy fix, I just made the laser rays physics bodies a bit thicker.

But if I had not seen this, and if - when testing some levels - I would not have collided with an laser (and I normally don’t, and you do not test for every possible user clumsiness) I would have pushed and update for iOS / Amazon / Google for my user base of still about one million installed games with all the lasers not working.

So, please give more information about your changes in the daily build notes. I know from my own experience that writing down things about code you changed is something almost no programmer likes, but it would be immensely helpful. Especially if you change something with the physics code.

No harm done, but please more info in the future.

Thanks & best,

Andreas

#6

The root issue is this change made in b2PolygonShape.cpp:

https://code.google.com/p/box2d/source/detail?r=258

Note that “erincatto” is the author of Box2D.

We catch this rejection as a convenience to our users. We recommend you modify your code.

#7

Oh, we all know Erin Catto and love him for creating this great physics engine and for still maintaining it.

And it is perfect that you stay on top of this, make updates and catch new errors like this!

But you have to TELL us about it.

This is a game breaking change, suddenly some physics bodies might not be created anymore, our games or certain levels might not work anymore as intended - and you know about this, because you’re catching the error. So just tell us. 1-2 Sentences would be enough.

Thanks!

#8

Hi @jacques1,

This is due to both physics maintenance and tweaks/changes in Box2D. Shapes with nearly no area were found to be causing other issues, i.e. being generated as large boxes offset from the intended location, so they were invalid in that form too. I’m not sure what shapes you’ve created that are being rejected, but the “nearly no area” flag should only be triggered for shapes extremely minuscule in size, such that they may not have even resulted in collision detection with other smaller shapes (or they would “dig in” to larger shapes before the frame-rate collision detection would “catch up”, which wouldn’t be accurate).

Can you show a screenshot (in “hybrid” or “debug” mode) of what kind of physics bodies you’re building in versions previous to #2332?

Brent

#9

Hi Brent,

thanks for the reply. I’ve attached a debug screen of physics objects from one of my game’s missions.

The smallest physics shapes I have at any time are of the below size for fences.

shape = {-1,-16,0,-16,0,16,-1,16}

In the attached image, you can see the fences are the very thin rectangles. All the really small dots are objects moving around the screen that need to be blocked by the fences if colliding.

Granted the fences are rather tiny but work perfectly fine in builds up to 2277 (i believe as of build 2281 box2d started acting weird due to box2d updates).

It wouldn’t make sense to have bigger physics shapes for the fences otherwise objects would appear to be blocked by the fences when they were no where near them. If there is now no way to do very small physics objects I guess I will be forced to remain using 2277 for my game.

#10

Hi @jacques1,

Yes, I see now. I don’t know the exact “threshold” of what is now considered “too small of an area” by Box2D, but you might be able to increase them by just 1-2 more pixels and get a generated fence shape without any noticeable oddness in the collisions. This would be my first suggestion to try. I have another possible idea, but I’m currently testing it, so let me know if the above option doesn’t work and I’ll see if there’s another method.

Brent

#11

This was an issue for us as well. Changing from a 1px wide collision to a 2px wide collision fixed the issue. Really we were just using them as sensors and not actual colliding objects, so it was working fine. It would have been nice to have this in the release notes so that we could have easily just typed “Box2D” or “Collision” and see hey… this now does this, ok i’ll fix that. 

But nevertheless, got collision working in the new build again. Thanks!

#12

Hi Brent,

I was working on an update for “Freeze!” and it was pure luck that I tested a level with laser rays in the simulator and I saw this error.

It was caused by my very thin lasers rays that until now worked just fine. But now they didn’t work at all anymore, it made the lasers kind of user-friendly & not deadly at all.

Of course, it was an easy fix, I just made the laser rays physics bodies a bit thicker.

But if I had not seen this, and if - when testing some levels - I would not have collided with an laser (and I normally don’t, and you do not test for every possible user clumsiness) I would have pushed and update for iOS / Amazon / Google for my user base of still about one million installed games with all the lasers not working.

So, please give more information about your changes in the daily build notes. I know from my own experience that writing down things about code you changed is something almost no programmer likes, but it would be immensely helpful. Especially if you change something with the physics code.

No harm done, but please more info in the future.

Thanks & best,

Andreas

#13

The root issue is this change made in b2PolygonShape.cpp:

https://code.google.com/p/box2d/source/detail?r=258

Note that “erincatto” is the author of Box2D.

We catch this rejection as a convenience to our users. We recommend you modify your code.

#14

Oh, we all know Erin Catto and love him for creating this great physics engine and for still maintaining it.

And it is perfect that you stay on top of this, make updates and catch new errors like this!

But you have to TELL us about it.

This is a game breaking change, suddenly some physics bodies might not be created anymore, our games or certain levels might not work anymore as intended - and you know about this, because you’re catching the error. So just tell us. 1-2 Sentences would be enough.

Thanks!

#15

This was an issue for us as well. Changing from a 1px wide collision to a 2px wide collision fixed the issue. Really we were just using them as sensors and not actual colliding objects, so it was working fine. It would have been nice to have this in the release notes so that we could have easily just typed “Box2D” or “Collision” and see hey… this now does this, ok i’ll fix that. 

But nevertheless, got collision working in the new build again. Thanks!