Hi, there!
Quick question: I tried messing around with Physics 2.0 and no matter what I did, even the simplest dynamic object which falls (and then remains stationary) onto a static object seems to have this weird gap between the 2 objects. Sort of like the dynamic object would float/levitate on top of the static one. Why is that?
At first I thought I’m not doing something right (I’m like 2h into using GDevelop 
), but then I opened the example projects and the same artifact. Why is this happening and is this normal? Is it a bug or a feature? 
Thanks a lot!!!
I don’t have any experience with the Physics behavior, but in order for people to help you, you’ll need to post screenshots (not phone images) of your objects behavior tabs that you’re seeing this on, and probably your events, too.
1 Like
Hi!
Ah, but that’s why I initially said, to make it more simple, it’s not about something I’m doing in particular, you can actually open the resources/examples/physics/physics.json file that comes with GDevelop and the problem is there also. So anyone can investigate it. That’s why in the beginning I thought I was doing something wrong, but I see this is the default behavior and I don’t understand why it’s acting like this. And also how come nobody noticed/complained about it so far?
Thanks!!!
Sorry, you’re going to need to provide examples what you’re experiencing, as I’m not seeing it.
I just tried the Car Physics demo on the example page, and I’m not seeing any gap between the wheels and the platforms even after a jump/falling.
Ah, sure:
Feel free to zoom-in on all the objects. They are “insulated” by this strange “invisible bubble air”, they’re just unusually cushioned by quite a few pixels, compared to being rock-solid touching the ground and interacting with the world around, other objects, etc.
Yeah, that isn’t there on the car physics example. I’m betting that has to do with resized objects impacting Physics 2.0 hitboxes as reported here: Physics custom hitbox not rescaled · Issue #1812 · 4ian/GDevelop · GitHub
As in the car physics demo, since the main objects aren’t resized, I’m not seeing a gap.
hmm it’s weird, cause for example I made my own example project, with nothing resized, just some 16x16 blocks with Physics 2.0 enabled, hit boxes the same size as the blocks (16x16) and the problem is also there, about 2-3 pixels separation between the elements. I definitely think it’s a bug 
No update about this? i have this gap in box shapes too if i zoom with my camera
Since you still have this problem 3 years later, then it seems nobody ever looked at it properly for a fix 
I gave up trying to use GDevelop precisely because of this bug which I encountered not even 2 days into my learning experience. I hope one day it’ll get fixed, so I can return to using it, since I really liked the whole concept of the engine and what the founder was trying to do with it, but having such gross visual bugs was an instant turn off for me. It reminded me of my teenage years trying to build massive games around 2005-2007 era and discovering that an engine bug was preventing me from polishing the game nicely. It instantly brought back all that frustration, so I decided to no longer bother with it. I can wait indefinitely at this point…
Just an update since this was revived. For gaps between stacked physics objects, there is a 1 pixel gap when stationary, but it is from the physics engine (box2d) itself rather than something GDevelop can fix. I only learned of this recently.
https://www.iforce2d.net/b2dtut/gotchas#smallgap
https://box2d.org/documentation/md__d_1__git_hub_box2d_docs_collision.html
My understanding is that Box2D intends to fix this with their next big release (3.0), but there’s no ETA.
Unfortunately this will be true of any game engine using Box2D for 2D Physics behaviors/code until that restructure happens.
This is separate than gaps from rotation/scaling, those are being investigated currently on the github.
The recommendations from Box2D is to shrink your physics shapes by about 1 pixel on all sides, to allow for overlap.
Edit: I just did a test where I zoomed in 3x on a static body meeting kinetic bodies, the static body (the platform) had 1 pixel less on the sides than the image. Note, this gap is only for stacked objects (bottom to top), so you don’t necessarily have to reduce sides of static objects if you don’t want to (although probably good if you’re going to rotate them)
Here’s the default behavior:
You can see the gap between the two dynamic objects (the balls) and the static object (the floor). (Ignore the objects on the sides, they’re also static and I just have their placement bad). There is no gap between the two dynamic objects.
Here’s the same project with 1 pixel reduction:
If you zoom in, both balls are touching the platform directly.
1 Like
Very nice find you had there, not to mention returning and replying so fast to this 3 year-old thread as soon as it reactivated 
Hmm… good to know this patch works, I kind of did this myself if I remember correctly, but it’s still something that must be fixed in my opinion. And what’s strange is that after all this time, nobody saw it with the exception of us few… I mean, how come? Not to mention it’s a Box2D bug, so for sure it affects hundreds of other engines, platforms or projects that rely on it as a library.
I actually think it’s probably related to the latter statement:
Because it’s box2D, people may be used to it from other engines. Or they have background images that make it less apparent, or they don’t zoom in as much, etc.
