Hierarchical kinematic motion
- Dominant language
- Rust
- Stars
- 5.7k
- Forks
- 387
- Avg merge
- 4d 23h
- Merged PRs (30d)
- 6
Description
`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)`, with rapier using this information within rapier to compute the effective global kinematic position after integrating motion, but before running any swept collision tests.
Contributor guide
Assessment
This issue has not been assessed yet.