Missing kinematicbody2d functions

[briansemrau]

The Godot physics API for KinematicBody2D includes:

• move_and_collide
• move_and_slide
• move_and_slide_with_snap

and other state accessors:

• is_on_floor/wall/ceiling
• get_floor_normal/velocity
• property sync_to_physics

These functions should be supported in this module. I don't expect implementation to be trivial, though hopefully not too difficult.

[briansemrau]

There is some mismatch between how to move kinematic bodies in Godot vs Box2D. Box2D integrates kinematic body position on its own with the b2Body linear velocity property. However, Godot does not integrate on velocity, but it updates it so that contact/collision behavior is consistent. Velocity is calculated internally based on changes of the body transform.

I am adding a property kinematic_integrate_velocity (false by default) that selects if the Box2D behavior should occur. That is, by default the user must integrate velocity themselves using move_and_collide/slide/etc. or directly updating the transform.

Setting velocity with this property disabled will result in an error, though behavior similar to #54 could be implemented.

[jordo]

Hmm, i'm a little confused on this as well. directly updating the transform in box2d ends up being a pretty expensive operation, you don't want to do this every frame to move stuff around, esp for dynamic or kinematic bodies and collision responses won't be correct. Instead only move them by vel or force.

[briansemrau]

The way I'm implementing this won't manually set the b2Body transform. It will appear this way to the user, but internally the new transform will be achieved by setting the b2body's linear/angular velocity. However, if the user enables kinematic_integrate_velocity and sets the transform manually (not linear velocity as they should, unless teleporting) then the b2body transform will be set.

Hopefully this will work without any hitches... :)

[briansemrau]

Being partway through implementing kinematic features, I've noticed that there are going to be a fair number of functions and properties that only apply to kinematic bodies (which error/behave unexpectedly for other types). I wonder if it would be valuable to separate functionalities of rigid, kinematic and static bodies into their own classes.

This sorta leaves the property Box2DPhysicsBody.type in a strange position. I think it should remain accessible for all body types. There is a valid use case for switching bodies between rigid and static, for example.

[jordo]

I think maybe some of this fundamentally boils down to whether or not the module will be intended to be a back-end for the godot physics api, or a godot module that wraps the box2d api (in theory anyways). b2d the type is a property of the bodydef, and stuff like linear & andgular vel on say static bodies just ends up being a noop.

I think move_and_collide is going to be tricky to implement correctly in b2d, esp test_only. Move and slide potentially the same thing. But in box2d you don't really want to stop the bodies on contact (position) and apply the collision response / linear vel on the next step, you just let the solver handle the response, and integrate the next position for you, this generates more accurate simulations especially at high velocities or low hz tick rates.

I typically switch between body types often (even in the current prototype I'm working on). Sometimes i decide i don't need to move a body around, and i just make it static. Or I convert from a kinematic type to a dynamic type, etc. I agree, I think that's a very common use case