Optimize gyroscopic motion#738
Merged
Merged
Conversation
Merged
Jondolf
added a commit
that referenced
this pull request
May 26, 2025
# Objective #738 optimized gyroscopic torque. However, it also broke it! The current algorithm only uses the diagonal of the inertia tensor at the end, when it should be using the full tensor. ## Solution Use the full tensor. Alternatively, if we represented the inertia tensor with the principal moments of inertia and an orientation, we would just apply that additional orientation. This is what Jolt does.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Objective
#420 changed Avian to use implicit Euler integration for solving gyroscopic torque. This was done for stability, as the semi-implicit version was prone to blowing up, because it extrapolated angular velocity and brought energy into the system.
However, that implementation of gyroscopic torque is fairly expensive, often being more than half of the total cost of velocity integration. It is also computed even for shapes with isotropic inertia tensors (e.g. spheres and regular solids) that don't experience gyroscopic torque. It would be nice to make this have less overhead.
Additionally, #735 broke gyroscopic motion, which needs to be fixed.
Solution
ApplyGyroscopicForceInternal.Note
Do regular solids really have isotropic inertia tensors? Yes!
See Moments of inertia of Archimedean solids by Frédéric Perrier: "The condition of two axes of threefold or higher rotational symmetry crossing at the center of gravity is sufficient to produce an isotropic tensor of inertia. The MI around any axis passing by the center of gravity are then identical."
Results
This is a 3D test scene with a bunch of cube stacks. The cubes have isotropic inertia tensors.
Velocity integration went down from 0.24 ms to 0.18 ms with the new solver, and still down to 0.13 ms ignoring unnecessary gyroscopic computations. Nice!
In the future, we could also consider making gyroscopic motion opt-in with a
GyroscopicMotioncomponent if we wanted to optimize this further for non-isotropic cases.Bonus:
gyroscopic_motionExampleI added a new
gyroscopic_motionexample to demonstrate the Dzhanibekov effect and test the conservation of angular momentum.2025-05-14.20-21-16.mp4