• Unity
  • Wrong interpolation, animation error or something else?

Hello,

I've been unable to solve a problem of wrong bone position. Please see the attached 2 images. Dark background image is a Spine editor screenshot, white background is Unity runtime.

Problem:
Playing attack animation in Unity snaps left leg to weird position as shown in attached image. Result occurs when playing attack animation from both setup pose (none animation), and from other attack animation. Result occurs both when not using mix time, and mix time test ranges .05 - .2f. Expected result when not using mix time = correct leg position.

I've tried replicating the issue in Spine editor preview view in order to test if this somehow is a problem of wrong setup or bone manipulation in animations resulting in a 'shortest path' interpolation issue. I've tested using a setup pose animation, keying all setup bones on all parameters using a 60 frame animation. Playing the setup pose in track 0 and the offending attack animation in track 1 yields expected result: no mix time = snap leg to expected position, and mix time .05-.2f = smooth leg transition from setup pose to attack animation bone position.

What am I missing here? :angry: :think:

Related Discussions
...

Can you post the exported asset or Spine project with images? What Spine Runtimes version are you using?

Thanks for the quick reply. 🙂

I am using spine runtime spine-unity 4.0 (updated 2022-05-25), and the spine file is from editor version 4.0.55.

Do you have a direct support mail that I can send the files to?

Do you have a direct support mail that I can send the files to?

Yes, please send us the files to contact@esotericsoftware.com so that we can investigate the problem. Please briefly mention this forum thread URL in the email so that we know the context. Then we can have a look at what's going wrong.

Cheers- sent 🙂


I should also mention the names of the offending animation - it's called "attack_second2"

5 giorni dopo

Thank you for sending your Spine project files. I have replied to your email, but as I wrote in it, I could not reproduce the problem. The attack animation was able to be played fine with no mix, so I suspect something is wrong in your implementation. Could you send us a minimal Unity project that can reproduce the problem?


After checking the .json file in your Unity project, the cause was found. First of all, we have already fixed this issue, so using the latest 4.0 should solve your problem.

The details are as follows: The problem did not occur when Animation clean up was enabled, but your Spine project which sent us has enabled it, so I had not been able to reproduce it at first. It was the ”foot_ik_L" and “foot_ik_L2" keys that were causing the problem, which were unnecessary because they had the exact same values as the setup poses, but in older versions there were problems with the compress for IK constraint timelines when using JSON export, so those keys were causing things to go wrong. This problem has been fixed in 4.0.60 and should not be a problem in later versions.

As a side note, your first report said that your animation went wrong when it was mixed, but actually you could find the problem in the Preview of the Inspector window, without placing it on the scene. When you find something is wrong, it is often helpful to check the appearance in the Preview. If it looks wrong here, then something is going wrong with the export from Spine to Unity. To learn more about using the Preview, please see this section of our documentation:
spine-unity Runtime Documentation: Preview

Please let us know if you still have problems after updating the editor.

Thanks for the input, I've tested the unity version 2020.3.25f1 with spine editor version 4.0.64, and the problem is indeed solved! Huzzah! :grinteeth:

On the unnecessary keys I've got a question. Are the keys really not necessary? I've had some trouble before with playing animations and mixing looking wrong because cleanup removed "unnecessary" start frame keys from animations. I can't recall the forum post, but it had something to do with cleaning up keys messing up animations.

I'm glad to hear the problem is solved! 😃

Regarding unnecessary keys, in fact, this is a point that sometimes causes confusion.
If you are using the SkeletonMecanim component to add your skeleton to the scene, you will need the keys at the first frame of an animation. For more information, please see this section of the documentation:
spine-unity Runtime Documentation: Required Additional Keys

If you are using the SkeletonAnimation component, in many cases the first frame keys with exactly the same value as the setup pose are unnecessary. However, when an animation is intended to be applied on a higher AnimationState track, keys may be needed to override animations from lower tracks. Therefore, a property called Layered has been added for animations used that way in Spine 4.1, and animations with Layered enabled are protected so that the keys at the first frame will not be removed when cleanup is performed. 4.1 is currently released as a beta version, but both the editor and the spine-unity runtime are already mostly stable, so we hope you will give it a try if you like.