Godot: PhysicState.get_contact_collider_velocity_at_pos is unusuable in 3D

Created on 7 Jul 2017  Â·  23Comments  Â·  Source: godotengine/godot

Operating system or device - Godot version:
Linux, Godot 2.1.4 (but I assume this behavior is probably much much older)
update: it's present in 7fc3c51169957f0907a13dd07d4004496e6ebd56 (3.0) as well

Issue description:
Recently I was looking at platformer 2d demo, and I saw very neat feature of PhysicState that allows to easily program following after movement floor parts like horizontal platforms in couple lines: (https://github.com/godotengine/godot-demo-projects/blob/2.1/2d/platformer/player.gd#L221).

if (found_floor):
    floor_h_velocity = s.get_contact_collider_velocity_at_pos(floor_index).x
    lv.x += floor_h_velocity

floor_velocity_2d

Immediately wanted to apply this to my 3d project where player movement is realized in quite similar fashion (also rigidbody), but it turns out it's not working so well in 3D.
This probably is somewhat know issue to @reduz since I looked at Platformer 3D demo, and very similar code is there... but it's turned off (commented): https://github.com/godotengine/godot-demo-projects/blob/2.1/3d/platformer/player.gd#L169
floor_velocity_3d

Would be cool if we could have something similar in 3d, since at current moment this method is returning big forces even if terrain is perfectly static.

UPDATE 1: For sample and more info check https://github.com/godotengine/godot/issues/9537#issuecomment-332870576

Steps to reproduce:
Download Platformer demo 3d and uncomment line 171 of Player script.

Link to minimal example project:
Edit1: For sample and more info check https://github.com/godotengine/godot/issues/9537#issuecomment-332870576

bug physics usability

Most helpful comment

Awesome, its working very well now! :)
platforms_fixed

This issue can be closed when bullet will be merged.

All 23 comments

@reduz Maybe you could take a look at this at the time of porting 3dPlatformer demo to 3.0?

It should happen in 3D too, it simply doesn't work due to how the 3D platformer demo is made. Will be fixing this today.

well I had this issue in my own project as well, but guess it's created in quite similar fashion to platformer 3d. Will be happy to check new platformer demo then! :)

@reduz is there any reason in particular why new platformer demo is using fixed_process instead of integrate_forces (like it was always recommended I think)??
edit: It's in fixed because it's no longer Rigid character demo. It now uses kinematic logic.

In any case, I ported rigid platformer demo to 3.0, and tested it on 7fc3c51169957f0907a13dd07d4004496e6ebd56 unfortunately the results are still the same

@AndreaCatania Just wondering if there are chances that this get_contact_collider_velocity_at_pos method will work as expected with Bullet. Don't get me wrong, there are ways to workaround this issue, but the simplicity of how moving platforms can be implemented with this method is very nice.

I tested this method get_contact_collider_velocity_at_pos time ago when I implemented it, and it looked to me that it is working correctly. Did you test it or it's just a question?
If you tested it and it doesn't work please submit an example project where this function doesn't work so I can fix it.

@AndreaCatania it was just a question, but I will test it for sure and let you know :)

I checked this issue once again, I can tell for sure contact_collider_velocity_at_position is not working well in 3D (or at least it's usage is different than in 2D). I created very minimal reproduction project in 2d which I'm using as a reference on how I think this function should be used. Recreated the same project in 3D (it practically use the same script). Godot physic engine in 3D contact_collider_velocity_at_position is returning 0,0,0. Also tested Bullet branch, and well it's hard for me to tell if this method is working properly on bullet because of other problems.

Recorded very short 40s vid that is presenting all above: https://youtu.be/jYK5xC_a9fI
Also here is sample project: FloorVelocityTest.zip (3.0 project)

Reproduction Steps:

  1. Open 2DVelocityAtPointTest.tscn and run it. Observe proper (I think) behavior.
  2. Open 3DVelocityAtPointTest.tscn and run it. Observe wrong (I think) behavior.
  3. (additional) Check together, on Godot internal physic engine and on Bullet.

@AndreaCatania you might want to check demo/vid from the post above. I'm curious, if you will be able to reproduce how bullet behaves on my machine.

The delayed motion is normal. This needs to be fixed in KinematicBody, so
it only actually transforms when it gets the callback from physics server.

On Thu, Sep 28, 2017 at 12:24 PM, kubecz3k notifications@github.com wrote:

@AndreaCatania https://github.com/andreacatania you might want to check
demo/vid from the post above. I'm curious, if you will be able to reproduce
how bullet behaves on my machine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9537#issuecomment-332871713,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2yLS4xNtn6O_L-kh0g6IrxyaEmgIks5sm7oigaJpZM4OQ2bP
.

@reduz what delayed motion?

I'm sure this problem is also on windows because you are using "_integrate_forces" function. I'll check this problem when the PR of "physics_process" and "get_body_direct_state" will be accepted

@AndreaCatania good to know! Will give it a shot then as well :)

I just tested it with https://github.com/godotengine/godot/pull/10013/commits/21535bb7e16ff956dbd6b6bbee98947f684935c9 on windows, and it works.

Here the gif: https://gfycat.com/gifs/detail/ValuableShowyHoopoe

Please let me know if you still have the problem on linux.

_Bullet related post_
Works very nicely on Linux as well, thank you!
I could not resist and I have added rotation to the mix. Not sure if this should work the way how I imagine, but it would be very easy to implement rotational moving platforms in such case :)
vid: https://www.youtube.com/watch?v=cJ3NXgrbg_w&feature=youtu.be
reproduction project: v2FloorVelocityAndRotationTest.zip

@AndreaCatania I was trying to play with your recent commits that are getting rotation into account (like we were talking on irc). I haven't found a way to make it usable and I'm not sure but I think there is still something fishy on the bullet site. On this gif I'm visualizing current readings from state.get_contact_collider_velocity_at_position:
rotationatpoint

It can be seen the forces are rotating together with the platform, but I think they are rotating in a wrong direction, I imagine this vector should more or less always point in the same direction as that smaller vector from this second gif (since this is more or less direction where that given point will be in next step):
rotationatpoint2

Here is a sample project which I think is better to use when investigating this:
FloorRotationAtPointTest.zip (run with debug -> visible collision shapes)
Also sorry for delay

Also what can be seen on those gifs is that more the more body is near the edge the more its accelerating, which is perfectly good since, points on the edge are traveling greater distance than the point in the middle (point that is perfectly at the center is not moving at all).

Another gif, maybe it will help somehow. It can be seen on it that something is wrong, point movement direction should be constant because body is always touching a point that will move in the same direction as previous one:
rotationatpoint3

it was made by commenting line 17 in Hero.gd # lv = floorVelocity;
or if you prefer sample is here: FloorRotationAtPointTest-no-movement.zip

Did some more test. It seems that get_velocity_at_pos in some way don't take rotation of the "floor" body into account. After compensating for floor body rotation with:

var floorRotY = state.get_contact_collider_object(0).rotation.y;
floorVelocity = state.get_contact_collider_velocity_at_position(0);
var fix4FloorVelocity = floorVelocity.rotated(Vector3(0,1,0), floorRotY);

It's starting to work for rotation, but in such case movement it broken:
https://youtu.be/jSlRwITh0SY

project:
FloorRotationAtPointTest-compensate-rotation.zip

Fixed 9227c55

Tested with platform with increased speed:
bugphysicstest

Awesome, its working very well now! :)
platforms_fixed

This issue can be closed when bullet will be merged.

solved by #12641 :smile:

Was this page helpful?
0 / 5 - 0 ratings