[Bullet] 3D: long (+300 m) collision shapes for static bodies resulting in strange behaviour

[Saitodepaula]

Godot version:
3.2 stable official

OS/device including version:
Windows 10 Home

Issue description:
In 3D, when making large or long collision shapes for static bodies, strange behaviour occurs, if a rigid body rolls or pass on it.
Setting the collision shape for a static body, and setting the collision shape extent (using the 3D gizmo or setting the EXTENT property in the editor) to 150 or more (resulting in a collision shape with 300 m length), rotating it to make an inclined plane, and placing a rigid body with a collision shape like a sphere on it, and letting it roll, results in the sphere bouncing or stopping abruptly at some point.
Sometimes the sphere just doesn't move anymore, sometimes it rotates in other directions, like it was deflecting something.
Another aspect, is that if the static body is placed in another place, the rigid body movement changes.

The example I've attached uses a sphere, but I've noticed it with a car I'm making, using cylinders (rigid bodies) as wheels. The car stopped or deflected, like the sphere in this example does. So it is not restricted to one collision shape.

EDIT: It looks like the problem is the ratio between at least two of the axis. If extent in X is set to 150 and, Y and Z are 1, the strange behaviour occurs. If the extent in Z is set to 10, no problem occurs.

Also, it looks like the ratio is not fixed, it depends on size. Changing to 300 in one axis, and 10 in another, still resulted in problems. Changing to 300 and 30, evertything was fine.

Steps to reproduce:

1. Add a static body
2. Add a collision shape to it, and set shape to BOX
3. Set extents to 150, in X for example
4. Rotate it, to make it an inclined plane, so that you can drop a rigid body, like a sphere on it
5. Add a rigid body, add a collision shape to it, set shape to SPHERE
6. Place the sphere rigid body on the static body
7. Run the game
8. Change the location of the static body, to see different rigid body behaviours
9. Change extent in Z axis to 10, to see no problem occurring

Minimal reproduction project:
StaticBodyBug.zip
I have also attached 2 videos showing the behaviour
StaticBodyBug_video.zip

Video10001-1178.mp4

Video10001-1382.mp4

[eyeEmotion]

I think mine is related. I've got a recent version of Godot and get "wobbly" physics when using the VehicleBody/Wheels setup, when driving on any kind of slope/angle, downhill or uphill.
Sometimes there are points where the car just flies of for no reason.

I checked my collision mesh and everything is fine. I've enabeld the "Smooth Trimesh Collision" option in the project settings, but that only helped slightly.
Already seeing lots of examples people having this problem, I hope this is an issue that gets the attention that it needs, car games rely on it (and thus the VehicleBody node)

Unwanted launch at : 6:21, 1:37
Noticeable wobbly physics at : 0:25, 0:39, 2:03, 5:26, 6:01, 6:43 (all more noticeable in real than on video.
https://youtu.be/suT_heUgWig

[Calinou]

I hope this is an issue that gets the attention that it needs, car games rely on it (and thus the VehicleBody node)

The VehicleBody node may be removed from core entirely to be replaced by an (officially-supported) plugin. This is partly because it can grow to be a very complex node, but also because it's relatively specific to a game genre.

Likewise, the same thing may happen to nodes such as VideoPlayer due to their complexity.

[eyeEmotion]

I hope this is an issue that gets the attention that it needs, car games rely on it (and thus the VehicleBody node)

The VehicleBody node may be removed from core entirely to be replaced by an (officially-supported) plugin. This is partly because it can grow to be a very complex node, but also because it's relatively specific to a game genre.

Likewise, the same thing may happen to nodes such as VideoPlayer due to their complexity.

A better one or??? And would that render the code I have up 'till know, obsolete?

There is many things to like about the Vehiclebody. Start setup is easy. But other things with it are hard to set up, like drifting for example. Or removing the drag/friction of some of the things.
Like in my video, going uphill or turning brings the speed down way too much. And driving down builds up too much speed. And I've still not figured out how to eliminate that, or just reduce it a bit. My hills aren't that steep, yet I need to already have a certain speed if I want to get up that hill.

And I haven't been able to get a drifting setup either. I try to adjust the friction slip as suggested in Godot, but it doesn't work. It slides after I have come to a standstill and then the car is uncontrollable.
I thought arcade racing physics were easier to set up, but apparently you constantly have to "fight" against the physics.

And ok, so no video's can be played in Godot? Because that was one of things I wanted to bring in the game aswel, for some animated screens in-game.

[Calinou]

I thought arcade racing physics were easier to set up, but apparently you constantly have to "fight" against the physics.

Vehicle physics are a difficult thing to get right. We're probably putting too much on VehicleBody's plate at this point, see godotengine/godot-docs#3206.

Some game developers sidestep vehicle physics entirely and use spheres for cars. This may be a viable enough solution for some arcade racing games.

And ok, so no video's can be played in Godot? Because that was one of things I wanted to bring in the game aswel, for some animated screens in-game.

The goal is to implement VideoPlayer as plugins, so libraries like FFmpeg can be integrated on-demand. This would provide support for a lot of formats, but since FFmpeg is a large library with relatively restrictive licensing (typically LGPL), not all projects can afford to include it. Hence making it a plugin 🙂

We could also provide a built-in implementation of the MPEG1 format using pl_mpeg. It's an inefficient format by today's standards, but is very cheap to decode and encode. This means it should be decodable smoothly even on mobile.

[eyeEmotion]

Vehicle physics are a difficult thing to get right. We're probably putting too much on VehicleBody's plate at this point, see godotengine/godot-docs#3206.

Some game developers sidestep vehicle physics entirely and use spheres for cars. This may be a viable enough solution for some arcade racing games.

I should investigate that more. But I'm so new to game-development and not used to this sort of coding. Over here, in my college days, they only thought typical programming for getting/setting information from and to databases. So this is a challenge :) . Although I have done programming in Flash (ActionScript 2 and 3)
I also read a message about 6dof joints or something like that.

I see what an open-source community has done for Blender, so I'm glad Godot is getting there but for game-development. Gives people like me, with 0 budget, the opportunity to make stuff like this and see if they can make something out of it.
Growing pains, right?! But then I can grow with it :).

[Gaffen]

I'm also encountering this issue in Godot 3.1.2.stable.official, on MacOS 10.15.4

I'm appreciative of a bundled, fairly accurate, car physics implementation, but respect the fact that it might be a bit overkill for a core package. Let me know if there's any other info I can provide to help!

[Tooniis]

I have a trimesh as the collision shape for the ground in my scene, and this is happening:

The player is a rigid body, and after it moves then stops (all forces stop acting on it), it continues to either move slowly in circles or slide or jerk in some random direction.

The ground trimesh is 1000x1000 (xz).

[pouleyKetchoupp]

For info, this looks like a Bullet specific issue.

I've tested the MRP on 3.2.3 stable:
Still happens with Bullet, but doesn't occur when switching 3D physics to Godot Physics.

[Zireael07]

I am seeing this (or something extremely similar) on 3.3. (and now that I know what it looks like, I know I have seen it on 3.2.3 too).

On the longest straight of my game, which is 370m along Z, around 6m along X and with negligible height (0.02 Y iirc) the car jitters up and down. The collision is an autogenerated convex shape. It doesn't jitter on any other straight, which have the same Y and X parameters and only differ in Z length.

This applies to both RigidBody (VehicleBody is a descendant of this) and KinematicBody (I have spent the last three days implementing Kidscancode's kinematic car since it neatly fixes 90% of little problems with vehicle behavior I had).

[Calinou]

On the longest straight of my game, which is 370m along Z, around 6m along X and with negligible height (0.02 Y iirc) the car jitters up and down.

As a workaround, you can subdivide the road into smaller parts if an individual block gets too long.

[Saitodepaula]

On the longest straight of my game, which is 370m along Z, around 6m along X and with negligible height (0.02 Y iirc) the car jitters up and down.

Have you tried Godot Physics? Like @pouleyKetchoupp have said, the same project I've uploaded in the first post, when using Godot Physics, runs fine.

Some more info: after experimenting with the original project of this issue, I'm coming to the conclusion that it's a matter more about the proportion of the collision shape that makes the ground, than it's absolute size. So try making your ground bigger in the Y and Z axis.

It's not related but I've seen the same concept applies to masses of rigid bodies interacting with joints, the masses can't be too different (like 1 or 2 orders of magnitude). So it looks like Bullet doesn't deal well with any physical quantity (size, mass etc) that has values too different by an order or 2 of magnitude.

[rydergaming]

I've had the same issue with a VehicleBody + VehicleWheels:

Check the video

On the longest straight of my game, which is 370m along Z, around 6m along X and with negligible height (0.02 Y iirc) the car jitters up and down. The collision is an autogenerated convex shape. It doesn't jitter on any other straight, which have the same Y and X parameters and only differ in Z length.

This applies to both RigidBody (VehicleBody is a descendant of this) and KinematicBody (I have spent the last three days implementing Kidscancode's kinematic car since it neatly fixes 90% of little problems with vehicle behavior I had).

What fixed for me is to generate a trimesh sibling instead of something simple. Granted this will make the game slower, but at least I can now start working on the game.