[Bullet] Fast RigidBody always go through walls and Godot Crash because of Collision

[ghost]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version:
Godot 3 RC3

Issue description:
Fast moving Rigidbody3D always go through walls
the collision is not always detected .. even if i make the wall thick and add more invisible walls to it .. still go through them

problem number 2 is : when i added a collision to Rigidbody .. everything works fine
select player mesh and : Create Convex collision sibling .. works fine

but when i close the project and i open it again Godot Crash or Close it self

and the way to reopen the project is to open the scene that contain that Collision in a Text editor and remove the line of Collision from there
and in this case , this is the line you must remove from "Level.tscn" to open the project

[node name="PlayerCollisionShape" type="CollisionShape" parent="Player" index="1"]

Steps to reproduce:
use : apply_impulse with higher value inside rigid body
if you set a lower value it will collide well but not for higher value

and this is the project .. if it didn't open for you .. remove the line from Level.tscn in Text editor

Minimal reproduction project:
FastRigidBody.zip

[AndreaCatania]

This is normal, Did you use Constant Collision Detection on rigid body?

[eon-s]

CCD or not, tunneling happens at speeds of ~150+ in the OP example project.
I could not test with Godot physics, throws many errors.

[Calinou]

@eon-s See #9071. As far as I know, this is not fixed in Bullet physics.

[eon-s]

That was for 2D, this is 3D, @Calinou

[AndreaCatania]

If CCD is on, tunneling should not be happen, with CCD off tunneling is normal. So I've to check why it happens when CCD is on

[Zireael07]

IIRC ccd is currently broke

[paul-dosenbrot]

I ran into this problem yesterday. The CCD did not work for my fast objects.

I did some testing, and it seems like the collision detection is working if I increase the object size. For a simple RigidBody Sphere I made the following observations:
At a radius of 1.5 and a rigid body speed of 214 it is colliding. If I increase the speed by 1 to 215 it does not work anymore.
At a radius of 1.0 and a rigid body speed of 153 it is colliding. If I increase the speed by 1 to 154 it does not work anymore.
At a radius of 0.5 (so a width of 1 unit) it is really weird: following speeds (for example) work: 61, 62, 70, 71 while others (eg 60, 72) do not work. I wasn't able to find a pattern about when it works and when not.

Another thing that I noticed:
A Sphere with the radius 0.1 and a speed of 30 can pass through too. I think I have a explanation for this one:
In rigid_body_bullet.cpp line 704 the ccd motion threshold is set to 1.
(https://github.com/godotengine/godot/blob/master/modules/bullet/rigid_body_bullet.cpp#L700)
If I understand physics correct this means that ccd will only be used if the body moves more than 1 unit in the frame. At a physics framerate of 60 FPS this means that ccd is only used for linear velocities greater than 60 (as this means 1 unit per physics frame). So ccd is not used for a sphere with radius 0.1 and a speed of 30. At a speed of 30 the sphere moves 0.5 units per physics frame. The sphere only has a radius of 0.1 (so a width of 0.2) and that means that there is a gap of 0.3 units that are not checked each frame. See the image

So I think the motion threshold should be calculated based on the smallest possible line through the object (for a sphere this is the radius*2).
This would enable CCD also for smaller objects at low speeds, and I think that is what most users will expect from a continuous detection: no tunneling, no matter of the size of the object. I guess this is only a solution for my small and slow object and not for the general not working ccd.

I am not an expert at physics simulation, maybe everything above is wrong. I just thought I would drop my thoughts about it here, maybe it's helpful.

If there is anything I can do to help (for example testing) that does not involve coding in C++ then I am happy to help as I would like to use CCD in godot.

[paul-dosenbrot]

Ok please forget what I was saying in the first part of my previous comment:

At a radius of 1.5 and a rigid body speed of 214 it is colliding. If I increase the speed by 1 to 215 it does not work anymore.
At a radius of 1.0 and a rigid body speed of 153 it is colliding. If I increase the speed by 1 to 154 it does not work anymore.

This was false. I was now able to find other values (for example below 214 for the radius of 1.5) that also do not collide, so it seems like there is no pattern when it works and when not.

[eon-s]

@paul-dosenbrot CCD is supposed to prevent the tunelling in these cases, it seems it do not work at all, you can try switching to Godot Physics and check if fail in the same velocities (I was unable to make godot physics work).

Other things that can be checked are if PhysicsDirectSpaceState.cast_motion() fails too, I suppose it should fail if it is using the same methods.

[twilson90]

Has anyone looked into this?
Continuous Cd still seems to be broken.

[takeontom]

Am seeing the same problem (Godot v3.0.6) . Is this bug is in all Godot 3.x versions? And is there any reasonable workaround other than changing to Godot Physics?

[eon-s]

@takeontom a workaround can be making your own tunnelling prevention system, but will depend on each case what you can do to make corrections, predictions...

[Toshiwoz]

I am experiencing the same, I have a custom build (942855a, built today 2018-11-26).
Using bullet and continuous CD enabled.
If anyone can direct me to the code I am willing to give it a try.

[eon-s]

It seems to not penetrate the statics consistently on 3.1 with the OP project, but keep pressing space and after a few tries the rigid go through the solid.

[AndreaCatania]

This is not a fix, but is an improvement of the CCD thresholds calculation: #28595

Is necessary to open a issue in the bullet github because the ccd is turned off with any threshold.

[Steven89Liu]

i have updated the "CCD doesn't work #2228", let's work together to make it work well.

[gururise]

Here's a simple test project (Godot v3.2 Beta) showing the tunneling that is occurring with RigidBody (regardless of whether CCD is on or off):

Make sure to enable Debug -> Visible Collision Shapes

Note: This scene is a RigidBody 3D with an Orthogonal Camera to better view the collision tunelling.

rb3dtest.zip

[gururise]

Is the updated merge of bullet inside Godot still planned? Hoping that fixes CCD for 3D

[akien-mga]

If you refer to bulletphysics/bullet3#2228 (comment), bullet has been updated in June 2019, so it's newer than this comment.

[jitspoe]

Bullet is implemented for 3D, but, from my understanding, the intent is to stick with Godot's physics for 2D, since it has some custom behaviors (one-way collision, and things like that).

[gururise]

This issue is referring to 3D and Bullet Physics. There is a separate issue for CCD on 2D Rigidbody.

[eon-s]

While testing again on 3.2b, I have found that this only happens on rigid mode, CCD seems to be working fine on character mode (at least with the OP example).

[vhp1360]

Hi every one, is there any update?
I have this issue on rigidbody2d too.

[starwolfy]

This issue impacts games which run at a lower physics tickrate (16tick/s -> 32tick/s) a lot more. I have to put speed limits on my rigid bodies to ensure nothing flies through walls. For me, CCD doesn't fix it! This only happens with Bullet for me.

[Zireael07]

@nikitavondel: CCD has been broken/not working for a long time.

[Nekuromu]

This issue seems to still be prevalent in Godot 3.4

[andyp123]

Is CCD only an option for RigidBody? Would it make sense to have it available on anything that can detect collisions? I'm currently experiencing this problem in Godot 4.0 pre-alpha builds with a fast moving projectile using an Area3D to detect collisions instead of a full-on PhysicsBody, and it also misses collisions with objects it should hit. I'd like it if there was a simple solution, but currently I'm looking into spherecasting between previous and current position to check for missed collisions, but although it's solvable, doing this correctly and finding the point of impact is more work than expected.