Hi, I haven't dropped this in bugs because I'm not entirely sure if it is yet.

I'm working on a simple scene, and started animating some basic transform keyframes and have noticed that the transition jerks a bit even though there are only two keyframes?

It seems to be worse and more apparent if I manually alter the easing graph, but it's even visible when hiding the attached images so not sure what is going on?

I've set things back to a basic to see if anything could have been conflicting & have uploaded a quick video to youtube here, not sure if it is immediately obvious with the video frame rate but there is quite a pronounced wobble towards the end of the ease?

This also appears in the pixijs project Im using it with on export.

EDIT (Have updated the video with one from a blank project just animating a single bone to test). If the keyframing duration is short its barely noticeable but over a longer duration it becomes quite pronounced?

Any ideas greatly appreciated!


Just updated to 3.8.84 and appears the same (as did the last version of 3.7) also tried a fresh reinstall but still the same. Is this a known issue with easing over a duration like this. Have never noticed it before?
  • Posts: 10


By wobble do you mean that the change in speed of the movement is abrupt? Spine has to turn every curve into line segments. Since there can be hundreds of curves, to be efficient the default is to use as few segments as possible, which is 10. This is usually enough, especially when your curve handles stay in their corner, say within ~50% of the width and height of the graph. Here is rendering the curve using the actual 10 segments:

You can see the segments in this image, but it's impossible to see the change in speed in the animation with this curve.

If the handles are moved farther, the curve bends more sharply and can become less smooth with some handle configurations when represented by 10 segments, eg:

To workaround the problem, you can make your animation using a single curve, then scrub the timeline to midway between the keys and set a new key. When setting a new key between keys that use a curve, Spine splits the curve, keeping the movement the same. The two resulting curves will not bend so sharply, and the movement will be smoother. You can set as many keys this way as you like to increase the smoothness, but it's rare to need more than 1. The downside to this workaround is that changing that portion of the animation later becomes slightly more difficult. Likely you'd delete the middle key, create a new curve, then key the middle again.

Another workaround is to change the number of segments Spine uses. Currently the number of segments can only be changed at runtime, not within the editor. For technical reasons that make things faster, at runtime all the curves use the same number of segments. The runtime creates the segments for all keys using a curve when the skeletal animation data is loaded. You can calculate the memory needed at runtime to store the segments: total number of keys using a curve in all animations * the number of segments * 8 bytes. Eg if you have 100 animations and they all have exactly 300 curves, to use 15 segments you need: 100 * 300 * 15 * 8 = 3,600,000 bytes = 3.6MB. If you do the same math with 10 segments you get 2.4MB, so the increase is 1.2MB. Projects vary in size a lot, so of course it may be much less or much more memory needed for your particular project.

In the next version of Spine we have a proper curve editor, where you can see the value over time. Likely the number of segments the curves use will be more of an issue then, because people will be doing more with a single curve. We will likely make improvements in this area.
User avatar

  • Posts: 9491


Thanks Nate, I didn't realise it worked in segments like that, it may help explain the problem I've been seeing then (just strange I never noticed it before!).

Best probably illustrated at this point here Spine Wobble (3.8.83) - YouTube

It almost looks like it is easing between segments so appears as a slight wobble at the end and start of the entire animation (Guessing this is the transition between segments). Thanks for the workaround, but as this animation may need quite a bit of tweaking may have to rethink it and possibly use gsap for these elements. I suppose having a more intense ease on a longer transition like that is not ideal in this case. (Its to be used on text sprites - so it will be more noticeable).

Thanks again for the info!

Maybe that because I've been using gsap that the difference became more noticeable :)
  • Posts: 10

Return to Editor