3d Kinematic body not sliding properly with Bullet physics

[fracteed]

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:

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:

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

[pegasusearl]

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]

CC @AndreaCatania

[AndreaCatania]

@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]

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]

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]

@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 :)

[AndreaCatania]

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

[fracteed]

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]

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]

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]

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 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.

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

[fracteed]

@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]

Is it ok to just increase the safe margin? I would think this is a bug if it does not work like in Godot physics...

On Feb 24, 2018 21:52, "James Redmond" notifications@github.com wrote:

@pgruenbacher https://github.com/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!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/16459#issuecomment-368273050, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z238z1c6rKO7nkgZ3VHoUvr8LGrHnks5tYK7agaJpZM4R8DrL .

[AndreaCatania]

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

[pgruenbacher]

I will today yes

On Sunday, February 25, 2018, Andrea Catania notifications@github.com wrote:

I don't exclude it, @pgruenbacher https://github.com/pgruenbacher can you please give me a sample project where I can reproduce it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/16459#issuecomment-368298315, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLZ9lhxuEPGb21SfJIfF07x4Lf9-iF8ks5tYTSqgaJpZM4R8DrL .

[pgruenbacher]

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

[AndreaCatania]

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

[pgruenbacher]

I'll test as well.

[fracteed]

@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]

@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]

The Godot 3D physics engine is deprecated, will likely be removed in 3.1 or 3.2 (if we want to mark it as deprecated in 3.1 before completely removing it).

2018-02-26 1:02 GMT+01:00 James Redmond notifications@github.com:

@AndreaCatania https://github.com/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 https://github.com/reduz is it worth adding this issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/16459#issuecomment-368357809, or mute the thread https://github.com/notifications/unsubscribe-auth/AEe8mtU2JnQLcoa-VMvjL2bZs4oRMAlfks5tYfSCgaJpZM4R8DrL .

[fracteed]

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

[darkhog]

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]

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