I have a dynamic ball bouncing on a static surface. The ball overlaps the surface for one frame, before bouncing up. How can this be avoided? I use the Orthographic camera.
Edit: This only seems to happen when the surface is using a built in Box Shape. When a Collision Shape is used I haven’t been able to replicate it.
Are you using 2D or 3D physics? What do you mean collision shape? A collision object can have shapes box/capsule/sphere.
2D physics. I mean a custom collision shape, as defined here:
For some reason I only seem to get this issue with a “built in” box shape.
Having continued my game I get this behaviour on all shapes most of the time. Is there a way to avoid this one frame “tunneling” of dynamic objects?
It’s not a game breaker, but it’s noticeable when the camera follows an object that burrows into solid objects for one frame. Can I force a graphic update at the same time as the physics is updated somehow?
Can you please share a minimal example of this behaviour?
I was just about to! A minimal project (no code!) is attached, showing the issue clearly:
With debug:
Without debug:
PhysicsTunneling.zip (34.6 KB)
I believe, this is how physics works with a such high gravity. Continuous Collision Detection (making ball a bullet) may fix this, but this is not accessible in Defold.
That might be true, although I’ve never seen this before as I’ve never had gravity set to so high. Is there an alternative way to make things move naturally? With the default settings all objects added appear planet sized and move very slowly.
In game.project under Physics you can set the scale of the physics simulation. I think Box2D maps 1 pixel to 1 meter in its simulation, so setting the scale to e.g. 0.02 would map 50 pixels to 1 meter instead.
Regarding the overlap issue, after some googling it seems like a quirk in Box2D unfortunately. Described in better detail in this thread; http://www.box2d.org/forum/viewtopic.php?t=6438#p29192
There is an ongoing feature we are developing to decouple the physics simulation from the game loop, allowing you to run the physics at a higher (or lower) rate. It’s not prioritised in our backlog yet and still early in development: Teaser Fridays and Roadmap talks - #89 by Johan_Beck-Noren
Being able to run physics at a higher rate should make the overlap smaller and not as noticeable.
That would be amazing. Thanks for the reply!
This has turned into a bit of a problem now, as the ball in my game actually gets stuck within the terrain. I’ve spent all morning trying to solve it, without success. Here’s what I’ve tried so far:
Any other ideas?!
If you are trying to “fix” the dynamic physics simulation by modifying linear velocity etc. you might be better off using a kinematic collision object and handle the simulation and collisions yourself instead. That way you get more explicit control of how the collision objects behave.
The manuals on resolving kinematic collisions should be helpful; https://www.defold.com/manuals/physics/#_resolving_kinematic_collisions
That may be what I’ll end up doing actually, I’m banging this ball against a brick wall. 
I’m at this again!
If -10 is “natural gravity”, how do I create a dynamic body football bouncing naturally? No matter what settings I use, I seem to end up with a football that moves much, much too slowly for it to feel “natural”.
Has someone done this and can point me in the right direction?
More reasonable values would be gravity -1000 and physics scale 0.01. Our template projects have been updated with these values btw.
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:
