Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

[4.x] Not smooth sine interpolation

foriero

Hi Nate,

Our animator has found this weird behaviour where we experience not smooth sine interpolation movement.

https://www.dropbox.com/s/ab3d96bjatxx9fu/nate_sine_movement.mp4?dl=0

Thank you, Marek.

Nate

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.

foriero

I understand that for displaying the curves you need segments but that does not mean you need the segments for animations itself. The movement can be super smooth especially if you have all in bezier curves. I just want to point out that for displaying curves it is always done that way but for the movement calculation while playing one uses math function and not the segmented "visual" line.

In other words the value of the controlled item must be always calculated mathematically without segmentation OR in other words the mathematical value function has to have much higher segmentation than the visual one you need for drawing curves in editor.

Mario

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

Which points to that the number of segments is not a constant but linearly depends on the time between two keys. In other words the bezier approximation points need to have a constant cadence over the period of time. So for what time 10 segments per bezier curve works? Does it work for 1s and 10s visually the same? I trust you guys trying to move all forward and help where I can help.

Regarding the names. Get it.

Mario, Nate, can you please show us smooth sine easing between two keys? I mean in 3.8 all was smooth. We have never experienced this kind of behaviour. 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 so important to have it right otherwise the whole animation simply won't look "right".

Ok I have tested 3.8 and see the same issue. So all is good. But regarding the easing speed. For animation sketch we think that to have "Speed" view ( former Graph in 3.8 ) is necessary. You really don't want to work in your new Graph except in special cases or when animating characters. For all other cases dopesheet and old graph ( speed view ) is more than enough for the work.

I mean look at the 3.8 graph as other tool how to efficiently and conveniently adjust animation speed. A possible name for the old graph - Velocity, Speed, Easing !!!

Can we have "VELOCITY" graph please? This is not possible.

Nate

foriero написал
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 написал
I mean in 3.8 all was smooth. We have never experienced this kind of behaviour.

Spine has always used 10 Bezier segments.

foriero написал
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 написал
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 написал
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.

foriero

Thank you, Nate. Yes I definitely see there will be two approaches to animations. From our perspective we are going to use in 90% of the cases dopesheet and velocity view. And only in cases we need to have more fine control we are going into the new graph view. 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. Vasek told me that by removing the old graph view ( I would really call it velocity view since it is affecting velocity in between two keys without worrying if I accidentally moved a bezier handle arm in your new graph view ) Spine lost the easy to use and fast animation workflow. We understand V4 graph is powerful and give us all the control we need but that does not mean the 3.8 graph was workflow redundant, the opposite is true. the 3.8 graph still has its place in the workflows. Just we need to start to call it "velocity graph". Hope it makes sense. Thank you.

Sinisa

Hi foriero,

foriero написал
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.

foriero

Yes we know it is superior to how and what you can control. Regarding the speed sorry, nope. We have tried and things take 3 times more for simple animations.

Sinisa

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.

foriero

5s work even in super complicated projects with new graph 30s work.

Here in new graph. May be we don't understand some details but we are simply not able to achieve the same acceleration as in 3.8 version.

Nate

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.