-
-
Notifications
You must be signed in to change notification settings - Fork 20.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bullet] 3d physics stepping is two frames late for bullet physics #37702
Comments
@huhund Does this occur if you use |
Thanks Calinou for looking into this.
bullet 3d is
while godot 2d is
I added a test project to github: https://github.com/huhund/godot_tests.git
I hope this info is helping. Thanks for a great engine. |
I tried to figure this out on my own. Thankfully the source code of Godot is very well structured and easy to read - big thanks for that. Anyway, the situation looks like this to me: Bullet library does not return the most resent position until the pre-tick in the next frame. This sound a bit weird to me but after a lot of log outputs, this is what it looks like.
One might think that a work around would be be to never use _physics_process and only rely on _integrate_forces. However, this would conflict with e.g. the 2D physics works. Also, the _integrate_forces is called right after the xform is applied. We wouldn't be able to trust that other objects in the scene have yet had their xforms synced.
I would suggest that we change so that _physics_process is called from insde the pre-tick. And split the RigidBody::_direct_state_changed functions so that transforms are applied before any process or integrate functions. Like this:
Maybe this setup would make it more stable? What do you guys think? It's not perfect because the rendering will always use transforms that are one frame late. But in case we can't read the most recent transforms from bullet there is not much we can do. At least it is not two frames late. |
Big thanks for looking into this. However, can we keep this bug report open? I can still see the two frame issue for Bullet 3D physics in 3.2.3.RC3. I think the issue is that Bullet library does not return the most resent position until the Bullet pre-tick callback in the next frame. Currently I can work around the issue just by using Godot 3D physics. |
Probably this is not yet back ported? |
The 3.2.3.RC3 release log says it should have the #40184 commit. I'm happy to test again later if I had the wrong version. |
My understanding is that issues should be closed if they're fixed in #40184 was backported (#40185) but then reverted (with 10544f1), because of regression issues. It will be reapplied with #40788, but it depends on whether #40486 is considered a bug or not.
The release log needs to be updated to reflect the reversion. |
I was impacted by this issue too. The main problem for me is raycasting from vehicles moving at high velocity. The raycast ends up picking the vehicle itself. I tried to use the body's direct physics state. I would be happy with this solution, but there is still a one-frame lag. I think one of the frames is the flushing happening at the start of the next frame instead of at the end of the current. But the one from the direct body state seems a deeper issue in the Bullet code. |
Can you use Godot physics instead? Or do you need a specific feature from Bullet? |
No, but I have patched my build for the moment. The original poster is experiencing a one-frame lag, not two. I was experiencing two because I was tinkering with the source code and introducing an extra lag frame. |
Godot version:
3.2.1-stable
OS/device including version:
Mac
Issue description:
3d physics stepping is two frames late using bullet physics. Expected would be that it is one frame late.
Steps to reproduce:
Apply either velocity or force to a 3d rigid body. You will notice that the object moves two frames after you apply the velocity.
Minimal reproduction project:
Create a 3d scene and add rigid body with this script.
The output is
Expected would be that body has moved at frame 11.
** Note **
Using godot physics is the update is only one frame late. Hence bullet physics works differently.
Create equivalent script for 2d. You will notice that the body moves on frame 11. Hence, 2d physics works correctly.
The text was updated successfully, but these errors were encountered: