A Bezier transition between keys is calculated using 10 line segments. You can see the line segments if you make a Bezier that bends sharply. This relatively low number of segments is used for performance reasons, as one Bezier needs to be calculated for every timeline and there can be many hundreds of timelines. We explored using a different number of line segments for each Bezier, but this would introduce new performance challenges. Most of the time 10 is sufficient (Spine <= 3.8 also uses 10), so we decided to stay with 10.

If the movement is not smooth enough, you can add more keys to get smoother movement. The easiest way to do that is to create your large (or sharply bending) Bezier first to get the shape you want, then add keys between those keys. Spine will split the large curve when adding new keys, keeping the original shape.

The problem of calculating the Bezier function for rendering is the same as calculating it for animation purposes, i.e. calculating values along a timeline. The Bezier function is a polynomial which can not be approximated in a more efficient closed form. Doing this for hundreds of timelines, for dozens of skeletons, per frame within a 16ms or lower time window does not work. As Nate tried to tell you, we've done the benchmarks, in multiple languages/runtimes. We'd appreciate if you trust our judgement, as it is based on work we did and experience we gained.

By the way, the rest of the team would appreciate if you started using our names, instead of always addressing Nate, even if it was one of us replying to you.

foriero yazdı

can you please show us smooth sine easing between two keys?

Note "sine easing" describes a very specific curve between keys using the trigonometric function called sine. All easing is done in Spine using cubic Bezier curves.

foriero yazdı

I mean in 3.8 all was smooth. We have never experienced this kind of behaviour.

Spine has always used 10 Bezier segments.

foriero yazdı

Vasek, our main animator, says that if we add more points then we are unable to control it and still are not able to achieve nice smooth transition.

This is incorrect. Having more keys does make it harder to edit an animation, all transitions can be smooth. The workflow I described can make it easier.

foriero yazdı

For animation sketch we think that to have "Speed" view ( former Graph in 3.8 ) is necessary.

The graph in 3.8 is not a speed graph, it is a value graph as is the graph in v4. The 3.8 graph is a much more limited version of the v4 graph which 1) shows only the transition between two keys and 2) shows the value (Y axis) as the percent of the difference between the keys rather than actual values. There is not a single aspect or use case where the old graph is superior.

A speed graph is a very different way of looking at the values over time. It can be useful but is harder to understand and difficult to use for some common use cases.

foriero yazdı

You really don't want to work in your new Graph except in special cases or when animating characters.

The v4 graph is much more powerful than 3.8 and a graph-centric is likely what most people will want to be using. If you prefer a dopesheet-centric workflow you can still do that.

Hi foriero,

foriero yazdı

The new graph view is perfect for character, emotions, or simply fine tune animations, but for fast animating the old workflow is much faster and visually easier to work with.

That's actually incorrect, there is no workflow where the old Graph is superior to the new one. Especially with the speed of the animation. The full-scale curve editor is an industry-standard, and for the sake of progress, we wanted to implement this important feature for the users.
The Graph is handy for solving many motion problems. It helps identify and fix kinks that cause jerkiness; it can tweak and make changes to multiple keys at once. There are hundreds of uses for how it can help improve the speed and quality of your animation.
If your animator needs some workflow tips, feel free to ask, I would be glad to help out. I know that some changes can be hard, especially when learning a new thing.

Interesting!
I like a good challenge! Can you show me an example of an animation you have been testing? I can replicate it in the new Graph. Just for comparison, check the bouncing ball animation I did at the beginning of this video https://www.youtube.com/watch?v=37CeFRzrjqc&t=13s That is a pretty simple animation. It took me around 5 min to animate it. Try to replicate it with the old Graph and let me know how long did it take you.

Not sure what you are showing here. The first animation is translation over 25 frames. The second is translation over 170 frames. Try making the same animation with the old and new graphs.

I just don't see how you can be having problems in the new graph. It should be easy to achieve the same results and the new graph gives a much better view of what is happening. We are not dismissing your concerns, but we need to be shown what the actual issue is.

I understand you are not primarily an animator. It may help to have your animator explain the problems they are having.