MixBlend Add bugging on Owl Example Project

alfanders

Hi, I'm trying to implement the owl example project in Spine 4.2 latest inside Unity. I've tried to use both Unity 6.1 and Unity 2022.3. Currently I'm on 2022.3. I also used the latest Unity Package, installed from git using the Package Manager.

My issue is that, when I play the "idle" animation on track 0, and "up" animation on track 1 using Additive Mix Blend on Spine, it's doing perfectly well. But when I do it on Unity, it rotates wildly. I have not tried other prject as I'm not a spine animator, so I couldn't create my own example project.

My code is fairly straightforward

``using Spine.Unity;
using UnityEngine;
using Sirenix.OdinInspector;
using Spine;

public class SpineAnalogPlayer : MonoBehaviour
{

[Tooltip("Only used for editor purpose, not used in game."), Space]
[SerializeField] SkeletonDataAsset skeletonDataAsset;

[SerializeField] SkeletonAnimation targetSkelAnim;

[SerializeField, PropertySpace(10f, 10f)] private int trackIndex;

[SpineAnimation(dataField = "skeletonDataAsset")]
[SerializeField] private string upAnim, downAnim, leftAnim, rightAnim;

[Button]
void PlayAnalog()
{
    targetSkelAnim.state.SetAnimation(0, "idle", false);

    TrackEntry entry = targetSkelAnim.state.SetAnimation(trackIndex, upAnim, true);
    entry.MixBlend = MixBlend.Add;
    entry.Alpha = 0.01f;
}

}
``

Is there something I'm doing wrong? thank you!

Spinebot

It seems like the issue you're experiencing with the owl example project in Unity might be related to how the animations are being mixed using the MixBlend.Add mode. In the Spine editor, the setToSetupPose is called each frame, which might hide issues that occur when using additive tracks. In Unity, this doesn't happen automatically, which can lead to unexpected behavior if the animations on different tracks don't key all the same properties.

To address this, ensure that the animations you are using for additive blending are set up correctly. Specifically, make sure that the lower track keys all the properties that the higher track will modify. Additionally, check that the Animation cleanup is disabled upon skeleton export to prevent keys identical to the setup pose from being removed. This can help maintain the correct base for additive animations.

If the problem persists, you might want to verify that the animations are configured correctly in the Spine editor and that the Unity runtime is up to date. You can also try adjusting the Alpha value to see if it affects the blending behavior.

alfanders

Thank you Bot! This is pretty helpful!

I've forgot to mention that I've both done disabling "Animation Cleanup" and adjusting "Alpha" value to no avail. In fact, adjusting Alpha value only slows down the broken animation of the owl.

I haven't tried the setToSetupPose but I don't think it'd be nice to use it on Update, is there anything else I could do? Thank you!

alfanders

Actually calling SetToSetupPose on Update fixes the issue thank you! I'm still looking for a better alternative but this'd work for now thanks!

Harald

@alfanders Glad to hear you've figured it out!

The better alternative when using additive animations would be to key the same values on the lower-track animation (idle in your case). Animations are applied every frame, applying the keys set in the animations. So if you don't have any keys of a certain bone location on track 0, but apply an additive animation on a higher track every frame, it will be ever-increasing.

alfanders

Thank you @Harald !! I'm currently using Spine's default Owl project. I'm simply trying to implement the interactable "looking to cursor" function in this example https://en.esotericsoftware.com/spine-examples-owl

I assumed it'd be quite straightforward, but having to key the bone on the lower track, would you consider updating the code base so that it'd support blending on keys that hasn't been keyed on the tracks below?

I assume we could just get the key from the setup pose

====

or if there's anothey better way then I'm open to try!! I think it'd be more ideal than the current Update SetToSetupPose implementation. Thank you again Harold!!

Harald

alfanders I assumed it'd be quite straightforward, but having to key the bone on the lower track, would you consider updating the code base so that it'd support blending on keys that hasn't been keyed on the tracks below?

No, it's intentionally working this way, that's by design. That's not only for efficiency reasons. It's also so that you can overlay e.g. a blink animation on a higher track over lower track animations, e.g. a walk animation. If the blink animation would reset everything that's un-keyed to the setup-pose, your blink would replace the walk instead of layer on top of it.

If you want all keys to reset, you can call SetBonesToSetupPose.

alfanders or if there's anothey better way then I'm open to try!! I think it'd be more ideal than the current Update SetToSetupPose implementation. Thank you again Harold!!

As I said, there need to be keys on the lower track animations, or call SetBonesToSetupPose.

We will fix the sample project. Sorry for the inconvenience!