-
-
Notifications
You must be signed in to change notification settings - Fork 21.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
CollisionShape does not update moving AnimatableBody3D? #67257
Comments
The workaround is to compose your moving platform like this: and make the This is because the godot/scene/3d/physics_body_3d.cpp Line 347 in 042e81f
which explains why your other node composition didn't work. This should be either properly documented or fixed. |
Thank you! |
You're welcome for the workaround. This still needs to be documented or fixed, so let's keep this open until that's done :) |
AnimatableBody3D and CharacterBody3D seem to work differently in this regard: 2023-04-01.01-00-10.mp4In this video green plate is CharacterBody, red AnimatableBody. Transparent red MeshInstance shows the original position of the AnimatableBody. AnimatableBody (or collision shape of it?) stays on it's original position as said in this thread, but CharacterBody follows the rotation of the parent (AnimatableBody and CharacterBody are siblings and childs of a common rotating Node3D here). So isn't this more like a bug in implementation than documentation? MRP (used in the video above): Godot version: v4.1.dev.custom_build [c29866d] (identical in 4.0.1 stable) |
@GNSS-Stylist As I wrote above, If you rotate the So this needs to be documented. Edit: Or animatable bodies should use the Edit 2: Briefly tried that (also using |
@rburing I understand how it currently works. But it feels kinda weird that AnimatableBody3D works differently than for example CharacterBody3D (or especially RigidBody3D, see later), IMHO. Made some tests and tried if just "touching" (overwriting the local transform with itself, in this case by $Rotator/AnimatableBody3D.transform = $Rotator/AnimatableBody3D.transform) fixes the issue and it looks like it does. And modifying the local transform also does the trick (as already said). But if the local transform is modified (or "touched") only occasionally, it leads to "teleporting". Also it seems that StaticBody3D reacts to changes in it's parents' transforms (checked this as it is the base class for AnimatableBody3D). Video: 2023-04-02.20-29-33.mp4Green plate is CharacterBody3D, red AnimatableBody3D and blue StaticBody3D. Transparent red MeshInstance shows the original position of the AnimatableBody. Modified "MRP": Doesn't the current behavior lead to strange issues if AnimatableBody3D is used in vehicles etc? That said, now after reading the documentation about StaticBody3D and AnimatableBody3D more thoroughly I don't quite get their difference. Although documentation for AnimatableBody3D says "When the body is moved manually, either from code or from an AnimationPlayer (with AnimationPlayer.playback_process_mode set to physics), the physics will automatically compute an estimate of their linear and angular velocity." it looks like it just teleports. So maybe it's just documentation issue after all. |
Hey, |
Still present in 4.2.1. So, this was kinda alluded to earlier, but simply setting |
I'm assuming its related but I've also noticed that with the node setup that rburing suggested and having sync_to_physics set to true, this causes the moving_platform not to move if get_tree().paused = true even if the moving_platforms's process_mode is set to always |
This was very confusing to me and I thought there were bugs in my implementation. Is the intended design that global transforms are ignored when sync_to_physics is true? What's the reason behind that choice if so? Seems like it would be feasible to still respect parent transforms while syncing movement to physics. As a side note, I've noticed that this works as expected if the parent's initial transform is set to identity and then is later on manipulated. |
When setting up a AnimatableBody2D with a CollisionShape2D this can also happen. In one instance when I animated the AnimatableBody2D and not the default Node 2D it works with "Sync to Physics" but when I duplicated the moving 2D Platform and animated the parent 2D Node it didnt work anymore. I do not understand the reason behind it to only respect the local transform. So this problem persists in 4.2.2 and in 2D. |
The RemoteTransform approach seems workable for scenes where there is only one AnimatableBody that must move relative to another node (the PathFollow3D in the original issue), but in a scene where a moving platform is composed of many AnimatableBodies, is there a recommended way to apply this? For example, something like:
The player moves with the train car because of the physics engine matching their velocity to the floor. I guess this is a long way of me asking if the original posted issue be treated more like a bug than expected behavior? |
then if understood correctly, the solution is (and just call any movement, applied to its local transform, from a The thing here is that But what people really expects from it to be is just "a |
Godot version
4.0.beta2
System information
Windows 11
Issue description
I created a moving platform composed this way:
The Playback Process Mode of the Animation Player is set to "Physics", though it looks like the CollisionShape doesn't follow its parent, the AnimatableBody3D.
Test.DEBUG.2022-10-11.15-39-12.mp4
Steps to reproduce
I attached the project.
Just open it with Godot 4 and run pressing F5.
Try to walk above the moving platform.
Minimal reproduction project
Test.zip
The text was updated successfully, but these errors were encountered: