High speed physics2d collision - intermittent tunneling

[linuxuser44]

Operating system or device - Godot version:
Godot - 2.1 / windows 7

Issue description (what happened, and what was expected):
2d Rigid body passes through kinematic & static body when moving at high speeds (velocity around 800,1000). The tunneling happens in about 25% of the collisions with the kinematic body and about 10% collisions with the static body. Seems to happen more frequently at higher speeds. The problem persists even when setting continuous Cd to: cast shape or cast ray.

Expected: 2d rigid body should always collide and bounce off kinematic bodies and static bodies.

Steps to reproduce:
Surround viewport with 4 rectangle static bodies to act as walls.
create static body with circular collision shape
create kinematic body with polygon collision shape using solid-vector polygon
Set gravity in project settings to 0
Set static body to 0 friction and 1 bounce
set static body to velocity (800,1000) or higher
control kinematic body to hit the "ball" (left & right arrow keys - optional)
After some time the "ball" will pass through the kinematic body or the wall.

Link to minimal example project (optional but very welcome):
https://dl.dropboxusercontent.com/u/12995630/pong.zip

[Zylann]

It is expected to see tunnelling happen when CCD is disabled, because collision checks will be done once per physics frame. This increases performance at the cost of having tunneling if objects move too fast. It allows to tune CPU usage depending on the game.

With CCD on, however, tunnelling should not happen that often (it should not even be a thing, in theory, because frame-by-frame processing is replaced by time slice processing).

Related QA thread: https://godotengine.org/qa/8448/possible-rigidbody2d-through-staticbody2d-kinematicbody2d

Edit: I played your example project but I didn't managed to make the ball traverse walls, however one time I saw it disappear under the paddle and reappear on top of the screen.

[linuxuser44]

Agreed, that was my conclusion as well. I spent about 6 hours on this and couldn't figure out why it was happening (i'm relatively new programmer so not an expert :D ).

[linuxuser44]

There was an additional collision shape below the bottom wall, that one has code to move the object back to the starting position. So basically that means that it "passed through" the first collision object and hit the second. I've noticed that moving the paddle and making the ball hit the corner makes it happen more often. I'll try to get a screen cap and post that.

[linuxuser44]

Ok this actually worked out perfectly. I took two videos. One at regular speed and one at "high" speed watch the bad video until the end you'll see instances where the ball passes right through the paddle especially after I change the size of the paddle, and finally at the end it actually some how gets stuck inside it... This doesn't happen at all in the good video (or ever from what i've seen when it's going slow enough). The collision also seems to be off many of the times is does collide. It registers the hit much higher up. There is no code change between the videos except the initial starting speed.
Good: https://dl.dropboxusercontent.com/u/12995630/Ball%20Good.mp4
Bad: https://dl.dropboxusercontent.com/u/12995630/ball-bad.mp4

[Zylann]

In the bad video, you can obiously see the ball travels across 3 times the height of the paddle each frame. There is little chance for it to bounce on it. Is it done with CCD?

[linuxuser44]

Yes, I've tried it with all three (off, cast ray, cast shape) they all act about the same way. My understanding is that with CCD it should collide with any objects in the way. Is that not true? Also, why would in some of the hits, it detect the collision early? You can see that happen at different points in the video where it seems to bounce much sooner.

I guess I'm trying to confirm this is a bug and/or if i need to build a workaround. Though it seems like this would be a pretty typical use case for motion & collision detection...

[Zylann]

I'm curious to know how CCD was implemented because what it usually does is not working here...

[bojidar-bg]

Hm, some people reported that CCD stopped working between 1.0 and 2.0, can we confirm this? (i.e. can you confirm that it works in 1.x?)

[radicaled]

Hm, some people reported that CCD stopped working between 1.0 and 2.0, can we confirm this? (i.e. can you confirm that it works in 1.x?)

I never used 1.x rigorously, but I'm exercising physics in 2.1.x right now and I'm pretty sure that CCD isn't working.

I had an issue last night where I was experiencing tunneling with about 10% of my projectiles. Toggling CCD on my rigid bodies did nothing for me. However, by removing the objects from the physics system entirely, and simply using Physics2DDirectSpaceState.cast_motion with a shape manually inserted into the physics server to represent the projectile, I was able to stop 100% of the tunneling. My understanding of CCD is that it should be doing something similar: either raycasting or shape casting to ensure that impossible movements don't occur.

Right now it appears that CCD just doesn't do anything regardless of what it is set to.

[bojidar-bg]

@radicaled Uhm, we already know that it doesn't work on 2.1.x, I was asking if someone can actually test on 1.x and see if it is working there.

Anyway, nice point about cast_motion, that probably what CCD is supposed to do indeed.

[radicaled]

@bojidar-bg Sorry, your question + the thread in general gave me the impression that no one was sure if the current behavior of CCD in the 2.x series was working as expected ("not very well" in other words) or if it was well and truly broken.

I wasn't able to find any documentation last night confirming that CCD was recognized as being broken, which prompted me to "confirm" the bug here.

My bad, I guess I didn't look hard enough. Is there another issue I can use to track the progress of this bug?

[bojidar-bg]

@radicaled I would guess #6926, though it seems like we don't have one indeed. Feel free to keep it here anyway, since CCD was designed to actively prevent tunnelling and it isn't working. 😃

[ghost]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[noidexe]

@Noshyaar This is still happening with 3.0.2

[bojidar-bg]

To make confirming the bug a bit easier, I made (yet another) sample project, both 2D and 3D:
physics-ccd.zip

It works fine with 3D Godot Physics, but fails with 2D Godot Physics and 3D Bullet Physics.
the sample also runs intersect_ray and cast_motion checks every frame, printing when and where they detect a collision. Both of them report the collision simultaneously, though cast_motion is a few units off.

[bojidar-bg]

Uhm, we already know that it doesn't work on 2.1.x, I was asking if someone can actually test on 1.x and see if it is working there.

So, I tested with a similar project on 1.1 and 1.0 (self-compiled release_debug), but I managed to reproduce tunnelling on both versions. So, seems like CCD didn't work correctly back then either.