dimforge / rapier

2D and 3D physics engines focused on performance.
https://rapier.rs
Apache License 2.0
3.89k stars 242 forks source link

Hierarchical kinematic motion #479

Open Ralith opened 1 year ago

Ralith commented 1 year ago

RigidBody::set_next_kinematic_position presently allows kinematic bodies to integrate gracefully with continuous collision detection in global coordinates. If a kinematic body is instead positioned relative to a dynamic body, this breaks down, as the dynamic body's next position is unknown until the timestep--and its collision detection--is complete, and hence cannot be used to inform the value passed to set_next_kinematic_position.

For example, consider a dynamic body modeling a train car carrying both a character controller and a sensor. If the character stands in front of the sensor, it will be spuriously triggered, because as far as rapier can tell, the character is stationary for the duration of the timestep, even if the application fixes up the character's position afterwards. Another example might be interactions between objects held in a VR player's hands or on their body while they're moving.

One solution could be offering fn set_next_relative_kinematic_position(&mut self, base: RigidBody, relative_position: Isometry<Real>), with rapier using this information within rapier to compute the effective global kinematic position after integrating motion, but before running any swept collision tests.