More reasonable values would be gravity -1000 and physics scale 0.01. Our template projects have been updated with these values btw.
1 Like
Yes, those values appear more natural. BUT they have the issue of tunneling, which I’m trying to avoid by being a good boy and following all the rules. 
I noticed that! But it still says -10 is “natural”, but I think that may be natural only on a small comet.
Where does it say this?
See screenshot above. It’s in the tooltip when you hover over the textbox.
I guess the comment refers to our common constant of gravity (~9.82) here on earth.
So, to recap:
- Gravity appears earth-like at -1000 and physics scale 0.01.
- With this level of gravity dynamic objects burrow into each other for one frame on collision.
- There is no solution, aside from manually dealing with physics using kinematic objects.
Box2D has an isBullet property that can be set on dynamite dynamic bodies to perform continuous collision detection. We do not expose this property.
Can you share an example project where this problem is very obvious and I’ll play around with the property? If it solves your problem we’ll look into adding it in the API.
Sure! This example (from above, but with the debug flag unchecked) displays the issue clearly:
PhysicsTunneling.zip (52.6 KB)
I’m not sure bullet is the answer, though, since apparently it’s more resource intensive:
I was curious that I hadn’t seen this behaviour in other engines I’ve used (Flash and Gideros), so I created a minimal example in Gideros with just a ball bouncing. It doesn’t display any tunneling, even with very high gravity (100000). In Gideros, a gravity of 100 feels earth-like.
In case it has any value, here is the Gideros project:
GiderosPhysicsTunneling.zip (8.5 KB)
Any idea why the Defold engine behaves so differently? Could it be that in Defold collisions are resolved a frame later, resulting in the overlap?
A few more observations playing with the PhysicsTunneling.zip Defold project:
- A dynamic collision object with restitution 1 that bounces on a static body with restitution 0 increases each bounce a little. A value of 1 should only retain the bounce height, not increase it.
- When setting frame cap to 20 the issue becomes much more pronounced, to the point at which the ball tunnels through the other side and disappears.
It seems to me this must be related to how Defold updates the physics?
Yes, I’ve created Issue- 4152 to investigate.
2 Likes
After a delightful GUI only project I’m thinking of driving back into the world of physics again. Has there been any progress on the physics front, especially to do with tunneling?
Relevant threads:
Updating the version of Box2D Defold uses:
Chain shape feature request:
An interesting recent development is the native Box2D extension by @sergey.lerg:
This extension also seems to suffer from tunneling, which may or may not be related (screenshot from the video in the post above):
To me it’s preferable to use the built in physics in Defold, so that collision shapes can be added easily right in the editor without third party tools. That said, maybe Sergey’s native extension is the way forward when it comes to a more accurate physics simulation?
To prevent tunneling Box2D has bullet mode for dynamic objects, which is easy to set in my extension.
Bullets
Game simulation usually generates a sequence of images that are played at some frame rate. This is
called discrete simulation. In discrete simulation, rigid bodies can move by a large amount in one time
step. If a physics engine doesn’t account for the large motion, you may see some objects incorrectly pass
through each other. This effect is called tunneling.
By default, Box2D uses continuous collision detection (CCD) to prevent dynamic bodies from tunneling
through static bodies. This is done by sweeping shapes from their old position to their new positions.
The engine looks for new collisions during the sweep and computes the time of impact (TOI) for these
collisions. Bodies are moved to their first TOI and then the solver performs a sub-step to complete the
full time step. There may be additional TOI events within a sub-step.
Normally CCD is not used between dynamic bodies. This is done to keep performance reasonable. In
some game scenarios you need dynamic bodies to use CCD. For example, you may want to shoot a high
speed bullet at a stack of dynamic bricks. Without CCD, the bullet might tunnel through the bricks.
Fast moving objects in Box2D can be labeled as bullets. Bullets will perform CCD with both static and
dynamic bodies. You should decide what bodies should be bullets based on your game design. If you
decide a body should be treated as a bullet, use the following setting.
bodyDef.bullet = true;
The bullet flag only affects dynamic bodies.
2 Likes
Does bullet solve the problem with your extension? The tunneling in Defold’s built in physics is likely to do with the way Defold works, rather than Box2D itself. See example video above I made in Gideros, which uses a more “pure” version of Box2D.
I don’t know what Box2d settings gideros uses, but if known, it’s possible to recreate in Defold with my extension. There are several values in Box2D for fine tuning.
Ah and you are probably using static body type for the platform in Gideros, where as in my video you see tunnelling between dynamic objects.
It would be interesting to see if the overlap in the extension is because of Defold, or if it’s expected Box2D behaviour. Does a dynamic bouncing ball tunnel through a static box using the extension? I wasn’t able to get any tunneling in Gideros with that setup.
Can’t test at the moment, but I am pretty sure dynamic bodies don’t overlap with static bodies in my extension.
1 Like
New game, same issue! This time I’m using joints, so the body has to be dynamic.
My new theory is that the game object is moved before all collisions have been resolved, so it appears stuck in the terrain for one frame.
I have been trying to move the body back when overlapping using the hack of firing a blind raycast and picking up its “ray_cast_missed” message mentioned in these threads:
The issue is clearly visible in this project: PhysicsTunneling.zip (52.6 KB)
Video of the issue:
Does anyone have any idea of how this issue could be fixed or mitigated?
3 Likes
For some reason this issue is still there when using the new and fancy fixed_update.
With fixed_update, would it be possible, with Lua or otherwise, to move the game object to follow the physics immediately, to avoid a one frame delay?