Esoteric Software

[zeno]

Hello
I'm inquiring about a problem with mixing animation.
I'd like to blend the 0 animation on track 0 and the 1st and 2nd animations on track 1.
Pose 1 and 2 are the same.
When changing from 1 to 2 animation, move as if the value of the setup pose is applied.
There is no problem with blending value of zero, but it is a problem when the pose is not the same.
I attach the video and file.
Please check.

Version 3.8.93

test.zip

[Mario]

If two animations key the same property (in this case the transforms of the bones in the skeleton), the animation applied last will win out. Any transformation of animations on lower tracks keying the same property will be overwritten, unless you use additive animation blending, as described here: Owl example: Additive animation blending

[zeno]

Thank you for your reply.
But I don't think it's the answer I want.

Track 0 - walk
Track 1 - a -> b mix 0.25

The last pose of a and the first pose of b are the same.

When the animation is changed to a -> b, the upper arm pose is the same, so the animation has to continue.
But if you look at the movement of Upper arm, it's different from the animation we've worked on.

When the animation changes to a-> b, it is judged to be affected by the setup pose.


Attach another file.
Please check again.

spine_test.zip

[Nate]

Here is a project file which shows the issue more clearly (walk only keys arm up high, a and b have a single identical key):
http://n4te.com/x/8095-spine_test2.zip
To reproduce:

track0: walk
track1: a -> b with mix duration

Actual: the arm dips toward the lower track during the a -> b mix.

This is expected behavior. When a lower track keys a value and a mix happens on a higher track, the value will dip toward the lower track value. Unfortunately it needs to work this way so that mixing is correct in all scenarios. Note this problem doesn't happen on the first lowest track that keys the value (which may be > track 0).

This can be solved setting TrackEntry holdPrevious to true for b. Also be sure to read the API documentation there for a little more information.

track0: walk
track1: a -> b (where b has holdPrevious=true)

As mentioned in the holdPrevious docs, b needs to key all the same properties as a. If it does not then there will be snapping of the properties b does not key when the mix completes.

[zeno]

Here is a project file which shows the issue more clearly (walk only keys arm up high, a and b have a single identical key):
http://n4te.com/x/8095-spine_test2.zip
To reproduce:

track0: walk
track1: a -> b with mix duration

Actual: the arm dips toward the lower track during the a -> b mix.

This is expected behavior. When a lower track keys a value and a mix happens on a higher track, the value will dip toward the lower track value. Unfortunately it needs to work this way so that mixing is correct in all scenarios. Note this problem doesn't happen on the first lowest track that keys the value (which may be > track 0).

This can be solved setting TrackEntry holdPrevious to true for b. Also be sure to read the API documentation there for a little more information.

track0: walk
track1: a -> b (where b has holdPrevious=true)

As mentioned in the holdPrevious docs, b needs to key all the same properties as a. If it does not then there will be snapping of the properties b does not key when the mix completes.

I solved it.
Thank you.