New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3d Kinematic body not sliding properly with Bullet physics #16459

Closed
fracteed opened this Issue Feb 7, 2018 · 25 comments

Comments

Projects
None yet
7 participants
@fracteed

fracteed commented Feb 7, 2018

Godot version:

Godot 3.0 stable

OS/device including version:

Win10

Issue description:

When a kinematic body moves forward on the z axis, it will come to a stop when a certain amount of force is also applied in the negative y - axis (note: this problem also exists on other axis, but for the sake of this example I will use these axes)

Under the native Godot physics, when the kinematic cube moves across a static body, it is not stopped when a y-axis vector is also applied. This is the correct movement as can be seen here:

godot_physics

However, if the same scene has changed to Bullet physics, the kinematic body stops when the move_and_slide y-vector is about -20. As can be seen here:

bullet_physics

I have been noticing these sorts of issues in my game, so hoping that this can be fixed, as Bullet is in general a bit more stable than the native Godot physics. This is one the few remaining quirks that I have seen.

Steps to reproduce:

  • Move a kinematic body using move_and_slide along one axis, when simultaneously moving it in another axis towards a static body. It will come to an abrupt halt very abruptly.

Minimal reproduction project:

kinematic_sliding_bug.zip

@ghost ghost added bug topic:physics labels Feb 7, 2018

@ghost ghost added this to the 3.1 milestone Feb 7, 2018

@pegasusearl

This comment has been minimized.

pegasusearl commented Feb 12, 2018

I'm not sure if it's similiar, but ~here...

I can't move Kinematic body to x and z axis after it reach the ground using move_and_slide with default physics (is it bullet? It works fine after I changed it to godot physics). is_on_floor() is always false.

When on that state i also tried to move by (1,0,1) but still cannot move. On that state, it can move up (1,1,1) just fine.

source.zip

It only happened when I used plane as collision shape of my static body. Using box worked well, I'm not sure about the other but it doesn't look buggy.

@akien-mga

This comment has been minimized.

Member

akien-mga commented Feb 13, 2018

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 13, 2018

@fracteed I've tested it, and it works if you increase the safe margin to 0.005 or 0.01 can you please confirm it?

@fracteed

This comment has been minimized.

fracteed commented Feb 14, 2018

Aha, yes that works. Thanks Andrea! Can't believe I didn't try that, I guess I was so used to it working on the default Godot physics that I forgot to try it when changing to Bullet. I upped the value to 0.1 and it seems to have solved the sticking problems in my actual game.

Just wondering if there are any downsides to the accuracy of physics when you crank the value this high? I have also been having an issue when lots of kinematic body enemies cluster in a group. They will sometimes swap positions. It is a very hard issue to replicate into a test scene. Is this also likely to be a safe margin issue?

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 14, 2018

The only downside could be that the body vibrate, but you don't need to set so high safe margin 0.005 is enough and I recommend to use this value.

0.1 == 10cm

To debug the other problem is mandatory to have a test project, also a video that show the problem can help to understand a bit the cause

@fracteed

This comment has been minimized.

fracteed commented Feb 16, 2018

@AndreaCatania thanks for the info. For this section of my game, I had to put it this high or I would still get some random sticking to floors, but my kinematic bodies are moving very fast, which is most likely a factor. Anyway, bullet is mostly working well for me now, so thanks for your work on this :)

@fracteed fracteed closed this Feb 16, 2018

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 16, 2018

Can you please send me a reproducible sample project? So I can test and improve it

@akien-mga akien-mga added archived and removed bug labels Feb 16, 2018

@fracteed

This comment has been minimized.

fracteed commented Feb 17, 2018

The problem has gone away by putting in a high safe margin, so I am happy with that. The sample project in the first post is the best way that I could reproduce the problem. The difference is that the kinematic body in my game is player controlled so the movement would be more erratic as the player can force the body into walls and floor. But this problem is now eliminated (as far as I can currently tell) with the high margin.

Other parts of my game are fine with the default margin. I did mention that there was some other occasional glitches, but they are like trying to capture lightning in a bottle, as they are rare! If I manage to replicate any into a test scene, I will certainly add as an issue on here. Btw, the kinematic bodies swapping positions problem I mentioned seems to be gone in the v3 stable build. It was happening a lot with the beta builds but seems a lot more stable now (I hope so anyway!). Overall, kinematics are definitely more stable now in Bullet, than with the native physics, so nice work!

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 17, 2018

Thanks you, another thing that I noticed in the project that you gave me is that you keep adding gravity even if the body is on the ground. You easily get too hight gravity and this could be a problem after some time. Is better if you handle the gravity correctly.

@fracteed

This comment has been minimized.

fracteed commented Feb 18, 2018

The whole idea of that test project was to test how much velocity in the y vector would cause the body to stop, so this was intentional. As shown in the gifs above, the native Godot physics will not cause the body to stop regardless of the downward velocity, whereas Bullet was stopping at about -20. This is a very stripped down issue of what was happening in the flying section of my game, as the player can fly toward the floor and have them suddenly get stuck if they keep press down.

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 18, 2018

So you want that the body when lands it keep going, Probably I think that I can fix it but as I told you I need an example project

@pgruenbacher

This comment has been minimized.

pgruenbacher commented Feb 25, 2018

This conversation ^ solved my problem after about 3 hours of headache. My sphere of 1 standard radius kept getting stuck on hilly terrain mesh. What happens when it gets stuck is that it reports no collisions, the leftover velocity returned form move_and_slide matches the input velocity, and the gravity -y value will reach the max downward velocity. -20 in my case. Trying to limit the gravity wasn't the issue, it kept getting stuck no matter what.

Bad Collisions. Sphere gets stuck after about 5 secs. default safe margin.

badcollisions

Good Collisions. Sphere keeps going. Set higher safe margin of 0.05.

goodcollisoins

@fracteed

This comment has been minimized.

fracteed commented Feb 25, 2018

@pgruenbacher good to hear that you solved your problem. A -20 in the y axis was also my sticking threshold. As noted above, the old physics system was not as fussy about the safe margin as Bullet. But then again, the old 3d physics was way more buggy!

@reduz

This comment has been minimized.

Member

reduz commented Feb 25, 2018

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 25, 2018

I don't exclude it, @pgruenbacher can you please give me a sample project where I can reproduce it?

@pgruenbacher

This comment has been minimized.

pgruenbacher commented Feb 25, 2018

@pgruenbacher

This comment has been minimized.

pgruenbacher commented Feb 25, 2018

@AndreaCatania you can clone and default scene should replicate the error for you.
https://github.com/pgruenbacher/godot-desert/tree/physics_collision_error

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 25, 2018

@fracteed and @pegasusearl can you please confirm me if that #17021 fix all your problems ?

@pgruenbacher

This comment has been minimized.

pgruenbacher commented Feb 25, 2018

I'll test as well.

@fracteed

This comment has been minimized.

fracteed commented Feb 26, 2018

@AndreaCatania I won't have time to test this for a few more days. If the test project I attached in the opening post works, then it should be solved.
On a related note, I have a reproducible bug in the native godot 3d physics system. I was going to post an issue, but it doesn't occur with Bullet, so not sure if the Godot 3d physics is being deprecated? @reduz is it worth adding this issue?

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Feb 26, 2018

@fracteed I checked it for you, with the fix #17021 your project works correctly with default margin of 0.001
If @pgruenbacher confirm it, we can merge it

@akien-mga

This comment has been minimized.

Member

akien-mga commented Feb 26, 2018

@fracteed

This comment has been minimized.

fracteed commented Feb 26, 2018

@AndreaCatania ok, great that is good to hear!
@akien-mga , that is what I thought, thanks for the clarification.

@darkhog

This comment has been minimized.

darkhog commented Apr 29, 2018

I think if setting the margin to 0.005 or higher works, it should be the lowest collision margin one could set, at least until we can make a proper fix, then we can get it back to 0 quietly.

I think it may be a problem with Bullet itself anyway as I had a similar problem with a JMonkeyEngine (a Java game engine) which also uses Bullet in the past and it also disappeared after setting the collision margin to 0.005 or higher. Thought it was fixed (as it was in 2011 or earlier, not really sure, maybe 2012 at most), but apparently it wasn't.

@AndreaCatania

This comment has been minimized.

Member

AndreaCatania commented Apr 29, 2018

As I said in the comment above the issue was fixed and the default margin can be used. Also a margin of 0 can't be used because a little margin is mandatory for the algorithm to work properly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment