Solution feels a bit weak, though not sure theres a really elegant way to handle this.

Yea, SLERP is definitely the sort of algorithm that ignores any sort of component-wise interpolation. Overriding the fcurve interpolation entirely at the right point of update cycle is necessary to gather the curves together.

It makes for a much more sane interpolation over longer keyframe-spans. I think it's a good mode to have, one that Maya has had for years.

Yea, honestly I haven't considered all the possibilities for animation sources.

Currently, the fcurve values themselves are all obtained via evaluate_fcurve when user-editable keyframes are present on all curves of the current action. A better solution would be to resolve keyframe-times via the NLA.

I'll do some testing and explore other options for controlling the 'ease' of the SLERPed curve

From a user perspective, I'd prefer (strongly) to see this on a per bone/object bases, perhaps close to where the rotation mode option is (UI wise) . Having it as an armature wide setting feels like a production kludge, aka 'old blender' ;)

A half-baked idea I've been toying around with is that perhaps we will have to look into allowing keyframes to store "extra data", instead of forcing everything into a strict 1 FCurve = 1 Float Value = 1 Number Property Affected.

So, in essence, you could have a single FCurve for "quaternion rotation" (i.e. all 4 quaternion rotation components in one go). We would probably add a "SLERP" rotation mode to make sure that this way gets used, and to keep backwards compat with files saved using the old per-element quaternion stuff. The FCurve would still have normal BezTriple (Keyframes) and FSamples - these would be there for controlling the interpolation/timing behaviour. Alongside this, you'd then have a separate array of the 4 quaternion components (one set per keyframe), which is what the user sets in the UI.

You'd also probably want to have another copy of this, to be stored alongside the "curval" float, to store the interpolated value, which will then be written to the file? Or perhaps, it might be better to instead store some kind of reference/index to the before/after quaternions to use, so that things like FModifiers can "just work" on the normal keyframes, and interpolate/play around with those as they like. Going with this second option, we'd then only perform the actual slerping in the animsys_write_rna() -> we'd take the value from the FCurve, along with the quat values to interpolate between, do the deed, and then write out this quaternion as a whole into the relevant RNA components.

A similar approach could then be used for things like strings and pointers - by making this "extra data" storage general, and able to store arbitrary stuff (we just need to tell it how big each one of these elements is in the array - sizeof(FCurveQuatData), sizeof(FCurveStringData), sizeof(FCurvePointerData)) something similar could happen there too. In the case of strings and pointers though, the FCurves might end up making less sense (as the y-values are effect useless - unless we somehow coop them to indicate in some way whether the pointer values are equal, etc.?). And these kinds of extra data could of course be edited via the Properties Region -> Active Keyframe pane would probably be an ideal candidate for that.

What is murkier however is going through all the various tools in Blender which use/modify keyframes, and make sure that they still do a good job (instead of causing the keyframes and extra data to get out of sync when they modify the curves). That would probably end up being the bulk of work required if we decide to do something like this.

Also, there's the issue of how drivers would then be handled.... In those cases, we might have to only allow for direct "driven value <= source value" mappings, as anything else wouldn't make any sense.

Anyway, that's just a general overview of an option that we could consider. There are still probably lots of smaller details I've overlooked which would end up causing us some grief.

In D1929#44172, @Joshua Leung (aligorith) wrote:

You'd also probably want to have another copy of this, to be stored alongside the "curval" float, to store the interpolated value

I like that idea a lot, made a mockup image to better understand the various control cases

Extending the FCurve with arbitrary data buffers sounds like the best way store it. That would also enable objects to be transformed that way.

If adding auxiliary data to FCurves is too invasive, a simpler option would be a single animatable float property on top of the existing rotation_quaternion array.

Also add a new "SLERP Quaternion" rotation mode which could reveal a fifth animatable value in the UI. Keyframes of this property could be treated as a clock signal, sampling all 4 quaternion fcurves at each curval keyframe.

I like this idea, since it's compatible with existing quaternion data and just a matter of switching rotation mode and (optionally) animating the curval channel

I have a couple of unrelated thoughts about this.

First:
SLERP is not typically useful for most animation in the same way that LERP isn't typically useful for e.g. location animation: it's not smooth. It can still, of course, be useful in the blocking process, but would rarely be used for final animation. I strongly recommend that SQUAD also be implemented, as it is roughly the SLERP equivalent of spline interpolation. Then in the animation process, SLERP can be used during some stages of initial blocking, and the user can then switch to SQUAD to have smooth interpolation and control over e.g. ease-in-ease-out.

Second:
I like the idea of having more sophisticated interpolation modes for quaternion rotations. But I think if we go this route, we need to think more generally.

Fundamentally, SLERPing (and SQUADing) introduces an inter-dependency between the quaternion channels, turning them into something of an indivisible single unit. Is there a way that we can generalize this concept to other animation in Blender? For example, maybe there are weird interpolation modes where it would be useful to similarly treat e.g. translations as a single unit rather than three channels. How can we handle this in a way that generalizes, and also doesn't break existing workflows?

My initial thought is that rotations already have alternate representations in Blender: the various Euler's, axis-angle, and quaternion. Couldn't this be just another rotation "mode" added to that list? Maybe "linked quaternion" or "unified quaternion" or something like that? Or maybe we could go the other way and use "quaternion" for the new mode and "split quaternion" for the old. Then within the new mode the user can set the curve's interpolation mode to constant, SLERP, or SQUAD interpolation.

Personally, I prefer that to SLERP/SQUAD just being additional interpolation modes on the current quaternion implementation. Because a lot more than just interpolation is changing: the nature of the curves are changing. This would make it explicit that, just like when switching between euler and axis-angle, the nature of what you're working with is changing at a more fundamental level: you won't be manipulating individual channels anymore, you'll be manipulating a single indivisible unit that wholly represents the rotation.

There are still a lot of problems that my suggestion doesn't solve, of course (most or all of which Aligorith has listed above). But I'm hoping this makes sense as a foundation for how users access the functionality. It keeps a clean split between old/new behavior, and it can easily generalize to other similar situations if they arise in the future.

(As a final side-note: for the love of god don't get rid of the current quaternion workflow. It is easily among my favorite things about animating in Blender rather than e.g. Maya/XSI. I am super happy to see someone working on SLERP because it absolutely will be useful, but I strongly, strongly feel that it should be added as an additional feature, not as a replacement. This is very much a trade-off kind of situation. Although SLERP/SQUAD are more perfect mathematically, in practice they do not universally make for a better animation workflow or user experience.)

Here's a 3-mode quaternion comparison showing the modes so far (purposefully with long-case quaternion intervals):

https://vimeo.com/164798991

The requested changes have been made, could we get another review?
@Joshua Leung (aligorith) @Campbell Barton (campbellbarton)

In D1929#44817, @Jack Andersen (jackoalan) wrote:

NlaStrip blending is implemented like so:

• Add: multiply higher quaternion with lower quaternion

In T47035#372476, @Jack Andersen (jackoalan) wrote:

D1929 adds a code path for gathering quaternions on a per-strip basis. It's specifically designed to sample explicitly-keyed timed points surrounding the evaluated strip-time.

After interpolating with SLERP/SQUAD, the proposed quaternion math is implemented for blending tracks.

This same code path could be made to evaluate direct nlerp via the fcurves, instead of the 2x or 4x evaluations for SLERP/SQUAD

Any chance this could be considered for 2.79, before the long stretch to 2.8? @Joshua Leung (aligorith)

Any news on this?

It seems weird to me that NLA blending does the wrong thing with quaternion rotations, but quaternion rotations are the default mode for pose bones. It seems like a big hole in Blender's animation functionality.

(Edit: Sorry for marking this as "needs revision", I didn't mean to set that)

I know this is old, and apparently not going anywhere, but lerped component interpolation is still a problem with Blender. Particularly with abstract or mechanical animation, or when exporting animation (as what you see ends up not being what you get.) And it's one of those problems that requires enough technical expertise that most users aren't even going to realize what's happening and are going to bang their head into the wall and eventually give up.

To my mind, this is something that an "everything nodes" plan, incorporating rigging nodes, should be designed to address.

A good rigging nodes setup would allow customizable interpolation (more customizable than just lerp or slerp or squad) by reading current, raw keyframe components as an input, reading *last raw keyframe* components as an input, and reading *next raw keyframe* components as an input. That would allow users to use the current W component (probably) to slerp between last keyframe and next keyframe quaternions. Possibly, just via math nodes, but slerp is a reasonable enough candidate for turning into a prefab node.

An even better rigging nodes setup would have *per-action* inputs, complete with weights and mix mode, or else allow NLA mixing in a different node editor.

I'd also like to see this fixed. IT becomes extremely problematic when rendering with motion blur, since while you can add manual keyframes on every frame to make it look good without motion blur, turning on motion blur will still use the wrong interpolation when calculating subframes.