dimforge / dimforge/rapier

Hierarchical kinematic motion

Open
#479 0 comments 0 reactions 0 assignees View on GitHub
2D 3D A-Dynamics C-Enhancement D-Difficult P-High
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.