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
1. sayfa (Toplam 1 sayfa)
zeno
Bu mesaja eklenen dosyaları görüntülemek için gerekli yetkilere sahip değilsiniz.
2 years ago
- zeno
- Mesajlar: 9
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
2 years ago
-
Mario - Mesajlar: 3035
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.
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
Bu mesaja eklenen dosyaları görüntülemek için gerekli yetkilere sahip değilsiniz.
2 years ago
- zeno
- Mesajlar: 9
Nate
Here is a project file which shows the issue more clearly (
http://n4te.com/x/8095-spine_test2.zip
To reproduce:
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
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 track1: a -> b with mix duration
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 track1: a -> b (where b has holdPrevious=true)
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. 2 years ago
-
Nate - Mesajlar: 11863
zeno
I solved it.Nate yazdı:Here is a project file which shows the issue more clearly (walk
only keys arm up high,a
andb
have a single identical key):
http://n4te.com/x/8095-spine_test2.zip
To reproduce:track0: walkActual: the arm dips toward the lower track during the
track1: a -> b with mix durationa -> 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 TrackEntryholdPrevious
to true forb
. Also be sure to read the API documentation there for a little more information.track0: walkAs mentioned in the
track1: a -> b (where b has holdPrevious=true)holdPrevious
docs,b
needs to key all the same properties asa
. If it does not then there will be snapping of the propertiesb
does not key when the mix completes.
Thank you.

2 years ago
- zeno
- Mesajlar: 9
Mark topic unread
• 1. sayfa (Toplam 1 sayfa)
Dön 한국어 Spine 사용자
- Tüm zamanlar UTC