You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a problem when I add keyframes to the animation skeleton while manipulating it in Pseudo-IK mode.
For example, using the Capsule model, I checked what happens when moving from the refPose to the "up" pose in Forward mode, then going back to the rest pose, and finally to the "up" pose in Pseudo-IK mode:
When registering the KeyframedValueController into the Timeline in the SkeletonBasedAnimationUI, the insertionCallback is:
which produces this effects during animation, the forward part is going fine, but the Pseudo-IK part is not:
I first thought that this is due to the fact that the Pseudo-IK scheme also modifies the parent's transform, which is not captured when inserting the keyframe.
Thus I tried the following insertionCallback, taking into account the fact that the parent's pose might be needed:
which produces this effects during animation, the forward part is still fine (not shown), but the Pseudo-IK part, while going to the desired keyframe, is badly interpolated (middle image):
What I mean by "badly interpolated" is that the edited movement for the bone is only a translation upwards, but when animating it it describes an arc of a circle due to the mix of the interpolation of the parent's rotation and the bone's translation.
I finally tried setting the Pseudo-IK -like "up" pose using the Forward mode (i.e. manually rotating the parent bone, then posing the bone), and the result is the same "bad interpolation".
Thus I am quite sure this is actually not an issue with the Pseudo-IK, it has more to do with the fact that the pose corresponds to a translation of the bone while rotating its parent.
So I think we might update the insertion callback, so that we would have the same behavior between pseudo-IK and rotated+translated Forward mode (I mean if we want the mesh to follow the shown parent bone).
Regarding the "bad interpolation": we have to rotate the parent and translate the bone in the same time, thus linear interpolation can't solve it. But we need it for standard movements (i.e. rotation OR translation only).
I though about the fact that the animation keyframes of the skeleton are stored in LOCAL space. Having them in MODEL space
could not help either since the bone would follow the straight path but its parent won't match in terms of rotation.
Also, changing the interpolator to match some specific cases as this one might cause issues with other animations, just like the problems @MathiasPaulin was having with the "smart stretch" mode when evaluating PR #735 .
The text was updated successfully, but these errors were encountered:
I have a problem when I add keyframes to the animation skeleton while manipulating it in Pseudo-IK mode.
For example, using the Capsule model, I checked what happens when moving from the refPose to the "up" pose in Forward mode, then going back to the rest pose, and finally to the "up" pose in Pseudo-IK mode:
When registering the
KeyframedValueController
into theTimeline
in theSkeletonBasedAnimationUI
, theinsertionCallback
is:which produces this effects during animation, the forward part is going fine, but the Pseudo-IK part is not:
I first thought that this is due to the fact that the Pseudo-IK scheme also modifies the parent's transform, which is not captured when inserting the keyframe.
Thus I tried the following
insertionCallback
, taking into account the fact that the parent's pose might be needed:which produces this effects during animation, the forward part is still fine (not shown), but the Pseudo-IK part, while going to the desired keyframe, is badly interpolated (middle image):
What I mean by "badly interpolated" is that the edited movement for the bone is only a translation upwards, but when animating it it describes an arc of a circle due to the mix of the interpolation of the parent's rotation and the bone's translation.
I finally tried setting the Pseudo-IK -like "up" pose using the Forward mode (i.e. manually rotating the parent bone, then posing the bone), and the result is the same "bad interpolation".
Thus I am quite sure this is actually not an issue with the Pseudo-IK, it has more to do with the fact that the pose corresponds to a translation of the bone while rotating its parent.
So I think we might update the insertion callback, so that we would have the same behavior between pseudo-IK and rotated+translated Forward mode (I mean if we want the mesh to follow the shown parent bone).
Regarding the "bad interpolation": we have to rotate the parent and translate the bone in the same time, thus linear interpolation can't solve it. But we need it for standard movements (i.e. rotation OR translation only).
I though about the fact that the animation keyframes of the skeleton are stored in LOCAL space. Having them in MODEL space
could not help either since the bone would follow the straight path but its parent won't match in terms of rotation.
Also, changing the interpolator to match some specific cases as this one might cause issues with other animations, just like the problems @MathiasPaulin was having with the "smart stretch" mode when evaluating PR #735 .
The text was updated successfully, but these errors were encountered: