Operating system or device - Godot version:
2.1.3 Stable (64-bit)
Issue description:
The Rigidbody2D node does not appear to have correctly functioning Continuous Collision Detection (even thought the option is present). "Tunneling" occurs with both "Cast Ray" and "Cast Shape" options.
Steps to reproduce:
I have tried both options (Cast Ray and Cast Shape) and neither of them seem to work. Looking back on previous issues posted here (and elsewhere), it appears Continuous CD was broken since version 2 of Godot was released and never got fixed. Is there any chance this can be corrected soon? It impacts a lot of my testing currently.
I'd just like to add that comments in those related issues suggest it's only "Cast Ray" that's not working but I've tried this with both "Cast Ray" and "Cast Shape" and neither are working.
Potentially a result of d7d65fa2f2b51d03f7bdfcbceedca99188ce979c
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 its current status 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.
The bug still occurs for both Cast shape
and Cast ray
.
Version tested: d87307d850186d27d2c27c5916ec8c4744c14979
Can someone retest after d403b4086c514647bba7620591061b7de7dfaf4b?
Tested with current master (11d77386221a4d911edee4fdbba5d3b9109a1c6b)
Cast ray
does not tunnel through objects any more, but at high speeds, objects will not stop at the collision but instead will be set back quite far.
With Cast shape
tunneling still appears
Both behaviours can be seen in this test project
Seemingly still an issue on 3.1?
Yes, still occurring on the latest master e16fc72ce
Oh thank god this is an issue and not just me doing it wrong. I have a 3-pixel wide (pixel art game, zoomed in) shield and a projectile that flies kinda quickly, and if I position the character's shield juuuuust right, the projectile gets past the shield. I tried both CCD options and neither of them helped. I really suck at physics, so I really hope this gets fixed.
@mitchcurtis As a workaround for your particular case, you could make the shield's collision shape thicker. It should work well if its collision layers/masks are adjusted not to collide with the player or other parts of the world.
Another workaround specifically for projectiles that mostly move in a straight line, is to use raycasts, or an elongated collision shape matching the motion of the projectile for 1 frame. It's a bit of code to write but it should work pretty well. (actually maybe doesnt need code at all, just different setup)
I need this fixed in order to continue working on my game's mechanics, I am not a great programmer, I am (for now) pretty much a web dev(HTML, CSS, JS) and a year of Python. With my skill set, could I fix this bug? If not, can someone else fix it please?
Someone please, before 3.2 releases, do something.
@ZingBlue Sorry, 3.2 was too close to release, we couldn't afford doing something that potentially introduces a regression somewhere else. I advise you look at the workaround given above: https://github.com/godotengine/godot/issues/9071#issuecomment-529217698
@Calinou No problem. I'll look into the workaround mentioned above.
Throughout my journey with Godot since 2.1 I wasn't sure whether CCD was actually working. This lead me to use Physics2DDirectSpaceState.intersect_shape
and similar methods to be run every frame with RigidBody2D
with custom_integrator
on and disabling the shapes. :eyes:
Some gd-pseudocode:
class_name Arrow extends RigidBody2D
func _enter_tree():
$shape_cast.shape = shape_owner_get_shape(0, 0).duplicate()
func _integrate_forces(state: Physics2DDirectBodyState):
$shape_cast.force_shapecast_update()
if $shape_cast.is_colliding():
get_stuck()
Actually I managed to implement a ShapeCast2D
node which can do shape casting similar to RayCast2D
as a workaround (yet use cases not limited to CCD):
https://github.com/godotengine/godot-proposals/issues/72#issuecomment-587981106
Hi, this bug is more than three years old now, and there seems to be no plans to fix it in the foreseeable future, probably under the assumption that there are workarounds.
However, the possible workarounds do not cover all use cases.
For example in my use case, I have a few small objects that can move fast in some situations and which must physically interact with each other in a realistic way. Ie. unlike simple projectiles, those objects do not disappear on collision but must bounce of each other. I cannot use the expanded shape workaround (or any of its variations) as it would change the impact point and bounce completely unrealistically and in a seemingly random and unpredictable direction depending on the exact collision position (while the bouncing angle must be predictable for the gameplay).
The only « workaround » that I see would be to implement a custom collision detection and custom integrators myself, which would be extremely complex (and I think is beyond my skill set, and many game developer’s), and would be much slower than an engine-level implementation.
Another workaround would be to set a very high physics FPS in the hope that no objects will pass through one another. Which is what I am doing now for the time being during development (physics FPS = 180), but it does not guarantee that there will be no tunneling (it still sometimes happens when two objects have relatively high speed in opposite direction), and a high physics FPS can have a severe impact on performance.
I hope this bug can be given higher priority in the future.
@njor We do aim to fix this issue eventually as it's labeled as a bug
. See https://github.com/godotengine/godot-proposals/issues/570.
Thank you for your answer. I see that the fix is planned for Godot 4, I hope this will be possible and will happen as planned. :-)
And thank you (and all Godot contributors) for all your work on the engine.
This bug is confirmed to also hit 3d physics:
https://github.com/godotengine/godot/issues/41404
Most helpful comment
Hi, this bug is more than three years old now, and there seems to be no plans to fix it in the foreseeable future, probably under the assumption that there are workarounds.
However, the possible workarounds do not cover all use cases.
For example in my use case, I have a few small objects that can move fast in some situations and which must physically interact with each other in a realistic way. Ie. unlike simple projectiles, those objects do not disappear on collision but must bounce of each other. I cannot use the expanded shape workaround (or any of its variations) as it would change the impact point and bounce completely unrealistically and in a seemingly random and unpredictable direction depending on the exact collision position (while the bouncing angle must be predictable for the gameplay).
The only « workaround » that I see would be to implement a custom collision detection and custom integrators myself, which would be extremely complex (and I think is beyond my skill set, and many game developer’s), and would be much slower than an engine-level implementation.
Another workaround would be to set a very high physics FPS in the hope that no objects will pass through one another. Which is what I am doing now for the time being during development (physics FPS = 180), but it does not guarantee that there will be no tunneling (it still sometimes happens when two objects have relatively high speed in opposite direction), and a high physics FPS can have a severe impact on performance.
I hope this bug can be given higher priority in the future.