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.
Fixed #60306. Discontinue the use of exp map in blending.
The exp map can easily perform multiple quaternion blends. However, it really comes into its own when you need to compute two or more quaternions at the same time, such as when diverting the cubic interpolate formula in an issue like #57951, which is what we are trying to solve now.
In the blending process, quaternions are always complemented one by one by the iterator, so there is not much point in using exp map. The calculation cost is much lower, but the error is larger when there are large rotations, as in #60306. See #58043 and https://swkagami.hatenablog.com/entry/lie_03algebra for a description of the error of the exp map.
Actually, in fact I replaced slerp and confirmed before that it does more than 3 blends correctly.
Here is the video after the fix:
2022-04-17.4.13.41-1.mov
In the opening of the video above you can see that changing the connection order for blending more than 3 Nodes is not a problem, prior to 4.0.alpha4 these results were different and the calculations were not done correctly in the first place.
Earlier, reduz said there was a problem with slerp from an empty quaternion as in #34134 (comment), it was that a 180 degree rotation from the init quaternion from always could not be done. In fact, we can use any base quaternion by adding init_rot to the calculation, so we don't have to worry about that problem.