-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix rotations when center of mass is offset #250
Fix rotations when center of mass is offset #250
Conversation
…putation of position offset to util function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huge thanks for looking into this! The behavior looks a lot more realistic and stable with your fixes and resolves a lot of issues with child colliders. I'm a bit surprised that it's as easy as applying AccumulatedTranslation
a bit differently. Thanks again!
No problem, thank you for your work on this project! |
Objective
Fixes #246 and #244.
Solution
If we consider
AccumulatedTranslation
to represent the translation of the center of mass (instead of the position),it's only necessary to account for the center of mass offset when applying the translation. Since we already have access to the original position and translation, computing the change in
Position
based on the change in center of mass position and rotation is straightforward.Usages of
AccumulatedTranslation
that assumed it refers to a translation applied directly toPosition
had to be updated. Fortunately,AccumulatedTranslation
is often accessed throughRigidBodyQuery::current_position
, so not many changes were needed.Performance
There's no measurable performance impact when testing in my game with hundreds of child colliders and profiling with Tracy (external trace includes this PR, this trace is main branch):
Alternative solutions considered
An alternative approach is to apply the additional translation due a rotation every time we apply a rotation (during integration, constraint solving) and take into account only the change in position of the center of mass in
update_lin_vel
. This was what I tried first, but I was unable to get it to work due to numerical inaccuracies that caused unexpected accelerations, or some other insidious bug I couldn't find :). Either way, this alternative would have required more changes, and for what it's worth I personally found it less clean as there was no longer a clean separation between updates to position and rotation (every rotation had to add a small change to the position).Changelog
AccumulatedTranslation
now refers to the translation of the center of mass, which may not equal the translation applied toPosition
when the center of mass is offset.