2D Kinematic bodies seem to be inactive in the simulation

[aleokdev]

2D Kinematic bodies (Both position and velocity based ones) don't seem to be processed by the engine. To replicate:

• Open the events2 example from the 2D example folder.
• Run the example and see how collision events are registered and the transform gizmo follows the body.
• Now, change the rigidbody used to RigidBody::KinematicVelocityBased and insert a Velocity component with a vertical lineal velocity of -100.
• Rebuild and run the example again, noticing how the transform gizmo doesn't move, and collision events aren't logged.

I don't know if this is expected behaviour or not, as I've been trying to look for more info on the site and docs but couldn't find anything relevant that used kinematic rigidbodies. From what I've seen, they're mostly treated as a special or not fully implemented feature. (They don't appear in any of the 2D examples, which perplexed me because it looked like a great fit for the player movement one.)

[sebcrozet]

Hi! The fact that the transform gizmo doesn’t move looks like a bug in the debug-renderer, but not in the way the kinematic body is processed. By default collision-detection between colliders attached to kinematic bodies and colliders attached to a dynamic body is disabled. To enable collision checks (and thus, collision events events) with colliders not attached to a dynamic rigid-body, you need to add the ActiveCollisionTypes::all() component to the kinematic body’s entity.

[aleokdev]

Thank you! I missed that section :) I do think the 2D player example could use a kinematic body and a few colliders for explaining this behaviour better though, I could PR a few changes to the example if you're ok with that.

[benfrankel]

I've run into the same bug with the debug renderer where kinematic bodies' transform gizmos don't move.

[Pascualex]

I can confirm that this is still an issue in 0.19.0, and indeed looks like a bug in the debug-renderer.

[Vrixyz]

Thanks for the report and easy to follow reproduction! From my testing this has been fixed since then (on master as of 032bd5c5adcbd0e70e1aa33), closing.