Understanding spline VS linear, once and for all

  • As a general rule Splines are effected by the two points before and after the Key Frame you are placing. Actually all Key frames have an effect however after 2 it starts to dampen a lot (to almost zero) unless there is a radical change in values between Key Frames. Break Spline will stop the over shoot, however it provides a slope very much like if not identical to Linear. I have asked that either they add an additional Spline type or fix the Break Spline, but under the last development team that was not going to happen as if you watch the Animation Webinar given by Chuck Taylor from around May 12/13 2018 he said so in as many words. He then went on to show the work around which I have been using for many years now, which is to copy a Key Frame and paste it one frame before or after the one it is copied from. So in your example above copy (CTRL C) and move a frame forward or backwards and (CTRL V) and that will get rid of most if not all the overshoot.

    The reason the overshoot happens is that Spline is a Sine Wave Curve and can not change direction in a frame. It can change Amplitude and Frequency as it needs too the complete the Sine Wave as can be seen in your graph. Here are a couple of examples of the placing an extra Key Frame.

    0_1536520043386_How it works now.png
    How it works Now

    0_1536520078913_How it should work.png

    After adding the extra (exact) copy.

    One other way to do it is start from the beginning and say you place a Key Frame at 20 & 19, go to 35 and have a nice slope if you go back to frame 34 and just create a Key Frame with value in Place it will also lock down the overshoot, unless you make a super radical change within a very short time frame, in which case it will again have a overshoot.

  • Here is another really fun example there are only 5 Key Frames one at Frame 1 one at the end Frame and three one frame apart (8,9,10).
    0_1536520894100_Spline 9A UUD.png

    As you can see the Spline goes up to the peak at Frame 9 and goes back down and undershoots at Frame 19.

    0_1536521015499_Spline 9 UDU.png

    Now just by moving Frame 9 down there is no undershoot but now there is two overshoots Frame 7 and Frame 16. Again the Spline is trying to complete a Sine Wave to the best of its ability. To prove this put a Key Frame at Frame 1 and another (exact copy) on the Last Frame. Now if you place a Key Frame at Frame 15 (assumes 30 frames) or the exact center of the time line then the Spline smoothly goes Up and then back Down. However move that center Key Frame to another location (say Frame 8), then the Spline goes Up through Frame 8 peaks at Frame 15 and drops back down to Frame 30 (Last).
    0_1536521548849_Spline 1Middle.png

    Below are an example of not placing overshoot Key Frames and then adding them in one by one.
    0_1536521661388_Spline 2Overshoot.png
    0_1536521674817_Spline 3Correct Overshoot.png
    0_1536521688650_Spline 4Correct Overshoot2.png

  • The way that splines behave in Poser is really, really, really stupid. I have no idea how it calculates the tangents, but whatever it is, it's broken for many, many, many, many years. These wild overshoots with splines is the single reason why I never, never, never use splines. Splines are evil. Down with splines!

    But the fix could be very simple! If the previous or the next key has about the same value as this key, then force the tangent at this key to have a horizontal tangent (that is, dv/dt = 0). That forces smooth transitions from places where the value is about the same from old to current. That is, instead of doing the crazy red thing it currently does, do the blue thingie by forcing dv/dt = 0 at those points. And if the the previous key and next key have different values, then let it do what it does today.


  • The Code to fix this problem is already in Poser so there is no need to come up with complex solutions as above that adds more complexity to the problem such as the statement "And if the the previous key and next key have different values, then let it do what it does today."

    Here is an example to show that the Code is already there.0_1536546512882_One Key Point.png

    As you can see there is only a single Key Frame not counting the one on Frame One which has to be there by default. Notice the nice smooth curve as it goes to the Key Frame. The reason it does this is as explained above the Spline is a Sine Wave. The issue here is since there are only two points it can not calculate a Frequency since there is none. That is the reason after it gets to the Key Frame it just continues on a straight line, having no other direction to head in.

    Now if we had a proper Break Spline we would get something like this. Actually it works on the higher side of the time line going from Frame 15 to 27 it has the nice smooth curve.

    0_1536551236443_BreakSPline Middle.png

    However it turns the Spline from a curve to Linear on the Lower side of the time line see below. Both Key Frames are Break Spline. If you turn of the First Break Spline then the Line peaks above the Key Frame before turning in to a Linear line.

    0_1536551905147_BreakSPline Both.png

    So to my way of thinking the Code is there just need to make a switch to turn On/Off the code to process the effects of the Spline going through all the points. If they fix the Front part of the Break Spline to work like a Spline with no further Key Frames after that Break then it would get rid of the Overshooting.

  • people, thank you so much for your thorough sharing of your knowledge and conclusions! no doubt there are some gems here.

  • @fbs7 said

    The way that splines behave in Poser is really, really, really stupid. I have no idea how it calculates the tangents, but whatever it is, it's broken for many, many, many, many years.

    There is nothing stupid or broken about the mathematical precision and formulas Poser, Maya and even that crappy dasz uses to calculate tangents. The only thing required is an understanding of the way things work, a proper workflow for setting keys and an an intuition for animating in 3D.

    The secret to Poser animation is to "anchor" the action of a character at every 4-5 frames by setting a keyframe for the entire model instead of only the things that are
    animated. This way the tangents don't get out of hand and for the most part very little adjustent will be required between the MAIN keys which are exactly 4-5 frames apart.
    Depending on the speed of the action, (dance or fight sequences) the main keys could be 3 frames apart. For something slower, (conversations), the keys could be 6 frames apart.

    With this kind of approach, there will never be unpredictable tangents by having keys randomly placed in the timeline.

  • @gsfcreator
    If you would have a Main key every 4th frame, the curve would look more like this:

    No funny business with the tangents.

  • @krios said in Understanding spline VS linear, once and for all:

    @fbs7 said

    The way that splines behave in Poser is really, really, really stupid. I have no idea how it calculates the tangents, but whatever it is, it's broken for many, many, many, many years.

    There is nothing stupid or broken about the mathematical precision and formulas Poser, Maya and even that crappy dasz uses to calculate tangents. The only thing required is an understanding of the way things work, a proper workflow for setting keys and an an intuition for animating in 3D.

    Hmm... let me rephrase. There are many kinds of splines, and Poser can choose any one of them; "unfortunate choice" is a better attribute for the kind of spline chosen, and "obstinate" is Smith Micro's attachment to it, given that these problems with overshooting have been around since Poser 5 at least.

    The problem is with the tangents. It's very common for a software to allow control of the tangents in splines. For example, this is from Blender:

    alt text

    I don't know about Maya, but Blender allows control of the tangents, and I'd suspect that Maya does too. Without control of the tangents the splines get wild. It would be so easy to fix that in Poser - just have some rule or control that forces the 1st derivative to be zero at chosen points. That would stop overshooting right there.

    As for myself I don't use splines for anything, exactly because of the lack of control of what happens for example if you leave eyes open on splines. You just add a blink - the thing goes bananas and then you need to adjust. Too much trouble for me.

  • @fbs7

    Once again fbs, if you set a "main" keyframe every 4 or 5 frames, there will simply be no tangent overshoot and chaotic movements.
    It is true that Maya and aparently Blander have tangent handles (if that's the correct lingo), but in Poser, something like that would be a royal pain in the index finger, because we can only adjust one channel or attribute at a time. Now imagine how significantly harder it would be to adjust 9 channels or curves for each individual limb (rotate, transform and bend x XYZ), instead of simply posing the character correctly.

    Not sure about Blender, but Maya has 1001 ways to fiddle with the tangents. It gives you the ability to control/adjust several curves (or channels) at a time. But it's the old artist vs scientist approach: do you mix colors by entering precise RGB values or simply point and click on a color wheel? Which for animation would translate as: animating with curves, tangents and trigonometrical formulas, or do you simply pose the silly characters? Artistic vs. scientific approach.

    Sure you have infinitely more control over movements in Maya, but you will also wear out your index finger much faster because of the extra clicks Maya requires.

    To put it simply, 2D animators do not have tangents and 1001 ways of manipulating them! And Poser is like a 100% accurate animation assistant (the inbetweener). All you need to do is tell Poser what the main keys are, and have faith that flawless mathematical formulas being calculated at indescribable speeds, will have predictable and reliable results. But if you don't know how to use Poser... then it becomes a matter of blaming the Playstation controller when you loose to a 10 year old.

  • The whole point of spline to me, is to set where the maximum is in the curve.

    Most of the examples shown from other programs, have the key at the top of the curve.
    If your key isn't at the top of the curve in those apps, well, it may over shoot as well.

    I use curves a lot in Poser animations, and yes it will drastically over shoot if you only have a few keys.
    But if you look at the curve it made, it is correct based on what you told it to do.

  • @shvrdavid one of the (major?) difficulties with how Poser derives it's splines is that intermediate poses can look fine as one is constructing the animation, but as subsequent keyframes are set, every single intermediate pose needs to be reviewed, unless spline breaks, or other non-spline interpolated keyframes are interposed. Given that the final keyframe of a channel is always interpreted as constant (zero first derivative), unless the prior slope was also constant, there will always be a significant change in interpolated values between the previous last keyframe and a newly appended one, so there's this continual requirement to go back and review what just got changed.

    I'll admit that I don't have any better suggestions, but a recent revisit to an animation sequence that I'd previously abandoned in disgust, (due to constant Poser crashes (prior to my awareness of, and then enabling auto-save, which still only kicks in after an idle period) losing the scene I'd spent hours building, but had yet to save, apart from a few individual poses) reminded me that Poser has no muscle-memory, or integrated hind-brain, constantly computing the most efficient, physically possible, intermediate limb attitudes to get from the current pose, to the latest one the frontal consciousness dictates, without having the hands intersect the torso, or the feet drag through the floor.

  • @anomalaus Which is why I always place two key frames one frame apart. Not the most elegant solution but it works. So if you like a pose just go back a frame and key frame that one too. Unless you do extreme changes the small difference will not result in the massive over shoot issue. And if it does have a overshoot then do an exact copy of the frame and place it back the one frame.

  • @anomalaus

    In many apps when you load one pose then advance some frames, then load another pose. Things will inevitably go a bit wonky. The difference from one pose to another can involve so many rotations that the splines can go crazy after that. I have done animations in many apps, and all of them have advantages and drawbacks. Poser is no different, just different. lol.

    One of the biggest things that took me a while to get used too was not having FK and the splines over shooting because poses and the joint limits were to high. Oddly, the spline will over shoot in other apps as well. But if you take the approach of topping the splines, it gets a lot easier. If the version of Poser you are running has constraints, you can set up sudo FK as well.

    What I mean by topping the splines, is thinking about them as a function curve. Where the pose places the keys isnt always the best place for all of those keys. If I do an animation the way you mentioned, loading a few poses, I go back and look at the splines to see where the top and bottom of the curve should be. Then make those the keys. Many of the keys loaded with the pose will get removed. So I get the curves that work with as few keys as possible.

    Also keep the animation short. IE dont start out with a 1000 plus frame total, just add as you go. Sometimes turning loop on helps, sometimes it doesnt, sort of scene dependant.

    There are a few advantages to thinking about the splines as a function. One is that you get acceleration and de acceleration right off the bat. Some things need that to look right, others dont and you need to go linear, etc. The other is that you only need a few added keys to do basically the same thing the curve handles do in other apps. Basically all those handles do is modify attack and decay, which you can do with 2 or 3 additional keys in the function curve. If you need more than that for a rise or fall of the slope, the topping keys are on probably on the wrong frame. And chances are good it will look odd as well

    Simply put,
    Splines are to add acceleration and de acceleration to the rotation of a joint. And if the change in rotation from one pose to the next accelerates a lot, zoom, over shoots either to the moon, or to the set or forced limits. It is basically doing what it is supposed too. You just need to move the keys to the peaks you want.

    Linear, has no change in acceleration between keys, it is a constant slope and that is basically all it does.

    Yes you can add acceleration to it with Linear, but you going to end up with a ton of keys to represent a function curve that slope can do with far less keys.

    If you prefer to use linear, make a key frame at frame one, then set that frame to all linear. The over shoot is gone.... And you will just get constant rates between poses, and rather odd movement.

    Linear and spline need different approaches as well.
    Linear will have lots of vertical key columns in the animation pallette.
    Spline will look like you shot it with a shotgun, keys all over the place.
    It is two different styles of animating.

  • @shvrdavid that sounds essentially like what I have ended up doing, without having a name to put to it. More often than not, I need to retime my animations and add intermediate keyframes, since the retiming invariably breaks the association of adjacent keyframes. I frequently have sinusoidal motions as well, (I think I read someone saying the interpolations were sinusoidal, but I'm yet to be convinced of that, unless both loop and quaternion interpolation are turned on, and not even then) which always require slope-setting keyframes if they begin at a zero-crossing.

    Maybe someone can clarify exactly what the spline interpolation algorithm is, and whether it bears any relation to the key value operation interpolation, which I could not match exactly with a three point polynomial from numpy/scipy, back before the UnaffectedValue() method was implemented (still waiting for UnaffectedValueFrame() method for API symmetry).