Having this new issue with IKs in Unity, through spine version 3.5.35-3.5.37.

In the video below, on the right is the spine version of the animation, on the left is the unity export playing just the same animation. The right one plays fine, but as you can see on the left one the wrist IK jitters through the animation. This is one of the IK's that broke in version 3.5.34 so i'm not sure if that has something to do with it. All other IK's on this model are acting as expected, although this is the only one where the bones are bent for the IK.

(reposted cause title was missing description)

Something else noticed with this, when I pin the hand down with an IK, the in editor animation properly keeps the hand still and appropriately at their IK points. In unity the hand moves on that same animation. Adding the bone hierarchy, I can see that the IK for both the arm and hand are remaining still, so something isn't entirely matching up

Xelnath написал

This is probably that animation blending/dipping issue again.

hmm, should there be a blending issue if theres only one animation running though?

Nate написал

Is it just one animation that loops without you making any further setAnimation or addAnimation calls? If so, it shouldn't be the dipping problem. Maybe it's a lack of accuracy with the sin/cos LUTs. Can you try increasing this number in MathUtils? const int SIN_BITS = 14; Try 18 or so and if it's better, reduce until you are 1 above where you see the problem.

Just the one animation and no other animations being triggered, looping is on. Tweaking the SIN_BITS does seem like its on the right track (at least when decreasing it, the same jittery twitching is happening on other IKs & Bones), however, regarding the wrist, no matter of increasing the const value seems to have any impact on it.

Nate написал

Another thing you can try is the replace the LUT calls in MathUtils with actual Math.Cos, Math.Sin, Math.Atan2, etc calls.

Yeah that was it, all the cos and sin ones are fine (through process of elimination), just the atan2 is culprit for it, animation is performing as expected with math.atan2. Overhead difference on this doesn't seem really that serious, is it something that I need to be concerned about in the long run?