Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
RigidObject velocity control #486
RigidObject velocity control #486
Changes from all commits
6711416
2e97f47
5ef0ec1
872c637
3476de8
4fd43c7
17ec713
c35fce8
5543d86
a464627
d685d96
2a44e2f
c071cb2
e484741
3e3e7f4
cc16e83
f839338
4de4e9a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@mosra: have you read this function?
Any advanced matrix manipulation from Magnum library can kick in to improve it?
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.
See my earlier comments.
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.
Just be careful.
It may cause significant numerical drift here (even with "double"). Not so sure if it would an issue in the future.
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.
One option to consider in the future might be switching to TranslationRotationScalingTransformation3D that stores rotation as a quat and thus could allow for faster and more precise calculation without having to go through matrices. However extra care has to be taken as relative order of the T/R/S transformations is different than with
MatrixTransformation3D
.Another option might be DualQuaternionTransformation but while it reduces the amount of ALU ops even further, it is more restrictive as there's no shear or scaling.
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.
Storing and time stepping rotation using a unit quaternion, or exponential map is the typical way we do in rigid body simulation.
Applying DualQuaternion method to handle rigid-body dynamics is rare. It is initially introduced by Kavan to computer animation to avoid the artifacts shown in linear skinning.
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.
Yes, I know it got first widely used for skinning, but that's not relevant in this case. Dual quats are, at its core, an efficient way to store translation+rotation together, so why not use it like that. The only thing related to animation/skinning is the DLB operation, and that's not used here.
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.
I am talking about the the rigid body dynamics system in general. Because dual quaternion will make it much more complicated than it should be. A rigid body has only 6 DOFs but the dual quaternion method provides 8 DOFs + 2 contraints. Such redundancy makes the 1st and 2nd derivatives of generalized coordinates
q
w.r.t timet
(dq/dt
) difficult to derive.So typically in a dynamics system, we decouple the state to rotation + translation, and apply exponential map (which has exact 3 DOFs, compared to quaternion, which has 4 DOFs + 1 constraint) to handle rotation change. In this case, you can still employ a unit quaternion to accumulate such orientation changes (and represent the orientation state at any frame).
Dual quaternion is good at handling the kinematics, which has nothing to do with the time derivatives.
In our simulator, whether we use dual quaternion depends on our future needs. If we would like to do some research of our own on "dynamics systems", not just "kinematics", we need to carefully choose the generalized coordinates, and maintain the internal states. In this case, I will not go with dual quaternion.
If we keep ourselves as customers to the physics libraries such as bullet, completely leaving the dynamics to it, or doing some very simple, explicit integration (not implicit integration), then sure we can use the dual quaternion.
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.
Thanks for the good discussion on state representation. We should continue to keep an eye on our use cases moving forward. If we find that our current representation is lacking in speed or accuracy we can revisit the alternatives. 👍