Цей сайт найкраще переглядати в сучасному браузері з включеним JavaScript.

[Unity] Frame-to-frame animation cancel blending?

sl_studio_harrison

Hello,

I am trying to make frame-by-frame animation in Unity Runtime recently.

The animator of my team split each animation into different slot (what I saw is like following image)

And when I tried to use those frame-by-frame animation by SkeletonMecanim and set those clip into blend tree (or state blending),

the animations blend seems also blend the image alpha of each slot (or animation clip? I am not sure with the term),

is there any setting of spine-unity runtime or Unity Mecanim can avoid the alpha changing?

For the frame-by-frame animation effect, hard changing clips will be better than the alpha blending.

Thanks to reading my post.

sl_studio_harrison

Harald

sl_studio_harrison написав
the animations blend seems also blend the image alpha of each slot (or animation clip? I am not sure with the term), is there any setting of spine-unity runtime or Unity Mecanim can avoid the alpha changing?

Your animator should be switching the visibility of the attachments at each slot instead of setting alpha values. The normal way of switching attachments will not create any alpha crossfade.

sl_studio_harrison

Harald написав
sl_studio_harrison написав
the animations blend seems also blend the image alpha of each slot (or animation clip? I am not sure with the term), is there any setting of spine-unity runtime or Unity Mecanim can avoid the alpha changing?

Your animator should be switching the visibility of the attachments at each slot instead of setting alpha values. The normal way of switching attachments will not create any alpha crossfade.

Thanks! I will tell animator this message, thanks a lot.

Harald написав
sl_studio_harrison написав
the animations blend seems also blend the image alpha of each slot (or animation clip? I am not sure with the term), is there any setting of spine-unity runtime or Unity Mecanim can avoid the alpha changing?

Your animator should be switching the visibility of the attachments at each slot instead of setting alpha values. The normal way of switching attachments will not create any alpha crossfade.

Thanks for answering my post.

We've tried to enabled and disabled the visible to each slot, then import into unity, the alpha blending effect is no more exist now, that great.

However, when I use blend tree or animator state changing, in transition part, both of the previous and next slot appear at the same time, and it looks same on every 3 mix mode (alway mix, mix next or hard) set, that's pretty weird.

Which looks like following :

Is that spine runtime default behavior? Or maybe there are some settings that we missed in Spine Editor or Spine Unity Runtime?

BTW, our animation also contains skeleton animation, so the frame-by-frame animation is use visibility to switch now, if that's possible, please tell us the setting steps, or there is any tutorial or manual for this frame-by-frame switching rule.

Thanks for replying again 😉

Harald

Sorry for the late reply! Could you please show your setup (in the hierarchy panel) in Spine with a few screenshots? Especially how your problematic switched attachments are arranged, and when in the animations you enable and disable attachments.

Alternatively you could also send us a minimal Unity project that still shows the problem, as a zip package to contact@esotericsoftware.com. Please also briefly mention the url of this forum thread in the email so that we know the context.

The problem is a combination of the following:

SkeletonMecanim not supporting TrackEntry.AttachmentThreshold and similar mix threshold functionality (as described on the spine-unity documentation page).
Your attachments of your image-sequence animations being arranged at slots like this:
```
Slot sequence_animation_1:
- seq1/frame1
- seq1/frame2
- seq1/frame3
Slot sequence_animation_2
- seq2/frame1
- seq2/frame2
- seq2/frame3
```
The above arrangement allows two Attachment frames of different sequences seq1/.. and seq2/.. being visible at once, because they are attached at different Slots. A transition of sequence 1 to sequence 2 with e.g. a resulting mix of 0.1 and 0.9 will not hide any attachment because there is no attachment threshold which would hide it when below and show when above. Auto Reset is enabled, but only reverts attachment state to invisible at the end of the transition, so this does not help during a transition.

Possible solutions:
One solution would be to have only a single Slot for all sequence animation frames, this will then automatically only have a single Attachment visible at any time:

Slot sequence_anim_all
- seq1/frame1
- seq1/frame2
- seq1/frame3
- seq2/frame1
- seq2/frame2
- seq2/frame3

Another solution would be to set a keyframe at all Attachments that shall be hidden in the first frame of each animation, to explicitly set their state to hidden and not rely on the setup pose. Be sure to disable Animation clean up in the Spine Export settings, otherwise these keys will be removed. This way as soon as the next animation starts playing, you ensure that there are no leftover Attachments visible. This can also solve a similar problem that would occur between your sequence animations and your bone-based skeleton animations (which shall hide all sequence animation Attachments)..

Another way would be to set the animation's MixDuration to 0, as you would normally not want any frame-by-frame animation to be played active at the same time anyway.

sl_studio_harrison

Harald написав
Sorry for the late reply! Could you please show your setup (in the hierarchy panel) in Spine with a few screenshots? Especially how your problematic switched attachments are arranged, and when in the animations you enable and disable attachments.

Alternatively you could also send us a minimal Unity project that still shows the problem, as a zip package to contact@esotericsoftware.com. Please also briefly mention the url of this forum thread in the email so that we know the context.

The problem is a combination of the following:
SkeletonMecanim not supporting TrackEntry.AttachmentThreshold and similar mix threshold functionality (as described on the spine-unity documentation page).
Your attachments of your image-sequence animations being arranged at slots like this:
Slot sequence_animation_1:
- seq1/frame1
- seq1/frame2
- seq1/frame3
Slot sequence_animation_2
- seq2/frame1
- seq2/frame2
- seq2/frame3
The above arrangement allows two Attachment frames of different sequences seq1/.. and seq2/.. being visible at once, because they are attached at different Slots. A transition of sequence 1 to sequence 2 with e.g. a resulting mix of 0.1 and 0.9 will not hide any attachment because there is no attachment threshold which would hide it when below and show when above. Auto Reset is enabled, but only reverts attachment state to invisible at the end of the transition, so this does not help during a transition.
Possible solutions:
One solution would be to have only a single Slot for all sequence animation frames, this will then automatically only have a single Attachment visible at any time:
Slot sequence_anim_all
- seq1/frame1
- seq1/frame2
- seq1/frame3
- seq2/frame1
- seq2/frame2
- seq2/frame3
Another solution would be to set a keyframe at all Attachments that shall be hidden in the first frame of each animation, to explicitly set their state to hidden and not rely on the setup pose. Be sure to disable Animation clean up in the Spine Export settings, otherwise these keys will be removed. This way as soon as the next animation starts playing, you ensure that there are no leftover Attachments visible. This can also solve a similar problem that would occur between your sequence animations and your bone-based skeleton animations (which shall hide all sequence animation Attachments)..

Another way would be to set the animation's MixDuration to 0, as you would normally not want any frame-by-frame animation to be played active at the same time anyway.

It works great!
Thanks a lot for your support. 😃

Harald

Very glad to hear you've figured it out, thanks for getting back to us! 🙂