• Editor

  • Understanding WHY curves change automatically when I don't want them to

I see several discussions on this going back a couple of years, but no one has given an explanation as to why this happens in the first place. When you move a bone in the editor, even with bezier handles set to manual, and regardless of "match" and "separate" settings, the curves I set prior get corrupted.
Before:

After:

My best guess is Spine is trying to preserve the intent of the animation when a bone is moved. However, my goal is to move the bone and keep the same animation curve intact.

Because this constantly stops my workflow to return my curves back to their intended values, and especially because this introduces jank into my animations when I don't catch it happening, I want to understand the underlying reason this happens in the first place so I can avoid it.

Related Discussions
...

When you move keys in Spine, the software attempts to adjust the curve handles to maintain a smooth transition, which can sometimes alter the curves you have set. This behavior is due to the complex logic Spine uses to ensure animations remain smooth and visually appealing, even when keys are moved. The adjustments are made to prevent jerky motions, especially when the curve has a cusp, as mentioned in the context. The handle modes, such as "Value" mode, can influence how these adjustments are made. If you want to maintain the original curve, you might need to manually adjust the handles after moving keys or explore different handle modes that better suit your needs.


    To show it also happening when not in separate mode, by adding a key between existing keys. I would have expected the editor to split the curve at the insertion point a la 3DS Max or Maya, not go wild with the separated values.

    Spinebot Bad bot. The question is how do I avoid spending half my time fixing curves I've already set.
    Okay, the real question is why, and the bot answered that. The NEW question is how to I work around this behavior?

      The bot mentioned trying to avoid cusps. Previous threads mention that too. But the cusp is the intention here. I would say 90% of my workflow revolves around adding keys iteratively between existing keys, which is a very common workflow in Flash, Max, and Maya. I would love the ability to not have Spine intervene with what it thinks is smoother or better animation.

      • Nate replied to this.

        Don't look only at the curves view. It has good uses, but it provides you a myopic view of only the curves between the selected keys and the next key, and those curves are scaled to normalize the time (X) and values (Y). That scaling can make the curve handles appear to move when they have not.

        Look at the graph instead, or look at both at the same time, but it can be harder to wrap your head around how the curves are shown in the curves view. The graph shows you all the keys at once, the actual time on X, and the actual values on Y.

        You said "when moving a bone" and I assume you have auto key on, so essentially you are moving a key in the graph up/down. That does not change the handles at all (see the graph), unless you have keys set to automatic Bezier.

        When moving keys left/right, handles are adjusted based on Retiming in the graph view settings:
        http://n4te.com/x/1424-Nw1h.png
        I apologize we don't have proper docs for that, but try the 3 values and moving keys left/right.

        When moving key handles it should be readily apparent why the curves change like they do: it's to keep the tangents straight through the keys, which avoids cusps (ie velocity discontinuity, the motion changes direction abruptly).

        If you separate the handles using the graph button, then when moving key handles, Spine won't adjust adjacent handles to keep the tangents straight and you will have a cusp. That can be acceptable, depending on what you are doing, but most of the time animators want smooth movement through their keys.

        You can separate all handles you change in the curves view using the Separate button in the curves view. When enabled, if you move a handle in the curves view, it doesn't move the handle on the other side of the key (which the curves view doesn't show you). This only affects moving handles in the curves view. It also affects pasting of keys, when enabled the handle before the paste is not changed.

        To show it also happening when not in separate mode, by adding a key between existing keys. I would have expected the editor to split the curve at the insertion point a la 3DS Max or Maya, not go wild with the separated values.

        Spine does curve splitting without changing the curve. It may just be that you are looking at the curves view, where it can be harder to see why the handles change.

        FCSW_Ben But the cusp is the intention here.

        Cusps (keeping straight tangents through keys) only come into play when 1) moving key handles, or 2) moving a key left/right. If you are moving a bone (ie moving a key up/down) then the handles do not change at all (unless the key has automatic for a curve).

        I would say 90% of my workflow revolves around adding keys iteratively between existing keys, which is a very common workflow in Flash, Max, and Maya.

        When adding a key in the middle of a curve, the handles of the new key are set so the curve does not change. If you then move that key up/down, the handles stay the same. Maybe that is the behavior that is causing you issues?

          All fair points. You're right about the graph view, and it explains why you've done it this way, but as I said creating those cusps is exactly my intention in the first place. I actually avoid the graph view entirely because it doesn't show me what I need to complete my work. It's a difference of paradigms to compare Spine here to my 15 years of experience elsewhere, and perhaps I just need to get with the times, but if I only had the option to not have Spine try to smooth the animation across a graph I could work a LOT faster and curse a lot less.

          Thank you for your time, regardless. I feel a little better at least knowing the underlying reason for this behavior. Please consider this thread a humble feature request from an aging animator.

          There's many possible workflows. If you are productive and making high quality animation, it's not a bad workflow even if you avoid our wonderful graph! 😆

          I'm surprised you prefer the curves view, as that is mostly unique to Spine and most other software has a graph. Most people who prefer Spine's curves view are that way because it used to be the only option in Spine. We replaced the curves view with the graph, lots of people wanted it back, and now we have both. I find the curves view most useful when changing the curves of multiple keys at once.

          Since the graph shows the actual, unscaled time and actual, unscaled values, smoothing the change in value as seen in the graph means smoothing the motion across the animation. When that is unwanted, separating keys should do what you need.

          We'd be happy to better accommodate your workflow, if possible. When moving a key up/down in value space, ironically Spine doesn't do anything to keep the motion smooth. You say you'd like Spine to do less, but I think you actually want it to do more in this case.

          For example, I have this curve:

          In the curves view, the left handle is at 40%, -30% and the right handle 60%, 70%.

          I moved the selected key down:

          In the graph view, the handles are the same relative to the key. The shape of the curve gets smashed a bit, and I doubt that is ever desired.

          In the curves view, the handles moved up/down (because their position is based on the percentage of the difference in key values (Y axis) between the 2nd and 3rd keys).

          Now I moved the handles in the curves view back to where they were, 40%, -30% and 60%, 70%, and also adjusted the first key handle to the same position in the curves view (not shown):

          This seems better, yeah? It's more similar to the original curve than the smashed curve we get by keeping the handles in the same position relative to the key.

          It could be that we need a mode for adjusting handles when a key is moved up/down, similar to the Retiming modes we have when moving a key left/right. We'll explore that more and see how it works in practice on various curves.


          That's all good, and I totally understand your intention. I'd like to walk you through the problem from my perspective, though, because we are talking about two different things.
          A lot of our work is based in traditional animation. So we're really thinking in key poses, and less key frames. We want to move from pose to pose with specific timing.

          Above is an actual timing chart from this project, with two key poses mapped to breakdowns (which Spine would call a keyframe). Breakdown numbers on the left, equivalent timeline timing on the right. Below, I've drawn what that would look like in Spine's timeline.
          This is exactly why I use the curve editor and avoid the graph. The graph is useful for how you describe how you animate. The curve editor is useful for how I animate.

          Here's a simple pose-to-pose animation with three keys. I'll add two extreme ease-out curves for illustration purposes.

          Now if I want to move the pose in the middle, Spine will attempt to create a beautiful perfect graph no matter the settings.
          With separate:

          Without separate:

          However, what this does is change the entire intent of the movement. What was a simple ease-out from one spot to another is now a complex animation that rounds somehow between the first position and the second, instead of simply correcting the second position as I expect.
          Worst of all, if I'm not careful about the separate settings being as consistent as possible throughout the project, the process of correcting and re-correcting the curves will inevitably lead to a blow-out like this:

          Particularly, this tends to happen to keys and curves earlier in the timeline, so I might not even catch the problem until I'm several steps ahead of it.

          This is easily the biggest time sink for me when using Spine.

          • Nate replied to this.

            You say you don't want Spine doing things to keep the curve looking nice, but the reality is Spine has to do lots of things to make any scheme work. It's a matter of deciding what the behavior should be. I appreciate you showing how you work and where you run into pain and I think we can make improvements here.

            FCSW_Ben That's all good, and I totally understand your intention. I'd like to walk you through the problem from my perspective, though, because we are talking about two different things.

            I think the screenshots in my last post show that what you seem to want (3rd screenshot) is better than what we currently do (2nd screenshot).

            Your graph is difficult to read because it's not very tall, it's very wide, and it's zoomed out. Frame would likely provide a better view.

            I recreated roughly what you showed:
            http://n4te.com/x/1460-curve-test.zip
            To reproduce: on frame 15 move the hip bone down.
            Expected: the same curves, fast-then-slow.
            Actual: wonky overshoot and curves that are nothing like fast-then-slow.

            Making the keys not separated (which gives very different curves) does not change the issue. The curves (especially the second curve) are still not similar to fast-then-slow after moving the hip bone down.

            I think what I described in my last post would solve this: when a key is moved up or down, the handles of the moved key should be adjusted so they don't move in the curves view. Also, the "after" handle of the key before the moved key and the "before" handle on the key after the moved key need to be adjusted. We'll dig into this more and let you know how it goes.

            Worst of all, if I'm not careful about the separate settings being as consistent as possible throughout the project, the process of correcting and re-correcting the curves will inevitably lead to a blow-out like this:

            I don't understand this part. Can you clarify what you mean?

              Hey @FCSW_Ben
              Also an aging animator here, with 20+ years of experience in classical hand-drawn 2d animation and 13+ years of 3d animation.
              We try to make Spine as user-friendly as it gets, trying to fit the needs of different animators with different experience levels coming from different software. Spine is unique because it has 2 graph views the Graph and the Curves view. We noticed that some of the old users prefer to use the old Curves view, and there are certainly some use cases where it's more handy to use it than the Graph view.
              We take every feedback very seriously and we always try to make our product the best there is, so concerning that we are trying to make the curve behave in a more efficient way.
              That being said, I did notice some mistakes in your approach that I think you need to address. The timing chart and the curve representation you drew out do not match. I sketched out the corrected curves on your drawing

              To be more clear I did the same thing in Spine with the whole curve visible in the Graph view for clarification.
              So from keys 0-6
              then 6-9
              and 9-13
              Another benefit of using the Graph view is offsetting the X and Y curve, which can help a lot in different places. I recommend checking this video, maybe could help:
              Also as you like to think in poses rather than frames, as I do, I recommend checking this video where I go through my workflow and show how I think and do animation:
              I can see a few different workflows you could try if working with default bezier does not work out for you, but personally, after trying all kinds of different approaches, I still find the fastest and the most efficient workflow the one I explained in the video.
              Another thing you are doing that I would avoid is separating tangents for a breakdown, if you want a breakdown to have a smooth transition, you would not separate them. Or separate the tangent on a first key, which has only half of a tangent handle to begin with.
              On your example, you show interpolation between key 0 and 5 and then you move the tangent handle to 90 degrees, it's to be expected you will get an extreme overshoot in that case. I recorded the gif making the same thing in Maya so you can see the same curve overshoot result.
              I would definitely recommend you to get familiar with a Graph view because you will see what the curve is really doing, and it will help you to notice mistakes right away.



              To be clear, we want to support many workflows. Sinisa isn't saying you must use the workflow he prefers, only that as a fellow traditionally trained animator, it's what he feels works best for many reasons. I think what he's getting at is to avoid the situation you are encountering so often by taking a different approach.

              Get as far as possible without using curves, then do curves at the end to polish. The favor tool is great for adding breakdowns. You can get very far without needing curves, greatly reducing the amount of fiddling with handles. Also when you have overshoot from a curve, drop a key at the peak to better control your extremes.

              That said, we are exploring how Spine can better adjust handles when keys are moved up/down to reduce the amount of fix up needed. You can see Maya does the same as Spine when a key is moved up/down: you get a squashed curve that isn't anything like what you had. We can do better!

              Separately from better handle positions, note that using an automatic Bezier gives you a good result when moving keys up/down. We'll consider making it easier to drop automatic keys, as currently you have to click automatic a lot. Automatic of course doesn't help you if you want a key with separated handles.

              A 4.3 preview:

              A couple things to note:

              • The curves view handles don't change when the key value changes. This keeps the curve shape in both the graph and curves view as the key moves up/down.
              • The handle after the moved key is preserved, but the handle before the key isn't. It can't be, unless the handles are separated. Alternatively, we could prefer to preserve only the handle before the key. When separated, both handles are preserved.
              • The leftmost and rightmost handles don't change because they are flat. If they weren't flat, they could also be adjusted so they don't move in the curves view (but we haven't implemented that yet, so we conveniently don't show it 😬). That means handles on the other side of those keys would also move, which if not separated would affect the adjacent curves. We'll have to try that to see if it's annoying in practice. Without doing that the curve isn't preserved.
              7 days later

              We've completed this feature now. It took a lot of effort but turned out fantastic! Curves are preserved as much as possible when you change key values. It's really nice. We'll start the 4.3 beta soon so you can try it.