Page MenuHome

NLA: rewrite evaluation channel data structures.

Authored by Alexander Gavrilov (angavrilov) on Dec 23 2018, 6:39 PM.



Implementing a new intelligent mixing mode that combines quaternions
via multiplication requires rewriting the NLA code to recombine array
properties from separate scalar channels during evaluation.

In addition, stable evaluation of NLA stack requires that any channel
that is touched by any of the actions in the stack should always be
set to a definite value by evaluation, even if no strip affects it
at this point of the timeline. The obvious choice for the fallback
is the default value of the property.

To make scanning all actions reasonably efficient, mapping paths to
channels should be done using hash tables.

Diff Detail

rB Blender

Event Timeline

Alexander Gavrilov (angavrilov) marked an inline comment as done.Dec 23 2018, 6:48 PM
Alexander Gavrilov (angavrilov) added inline comments.

One big user interface design aspect of this is which tracks and strips should count for determining which channels are touched "anywhere" on the timeline. Here I implement it in a way that muting strips doesn't affect it, but muting/soloing tracks does.

The main reason for this is so that "stashed" inactive tracks are ignored by this computation.

The user-visible aspect of this is that channels left uncontrolled after muting strips will always be reset to default, but muting tracks will leave them at the current values.

Brecht Van Lommel (brecht) requested changes to this revision.Dec 27 2018, 5:24 PM

It seems reasonable to me.


We generally use XXX to mean something in the code is broken, which I guess is not the case here.


I was confused by the terminology for quite a while, especially since NLA is about animation layering and this seems unrelated to that type of layer.

Could it be called NlaEvalProperty instead, since it seems to correspond to a single RNA property?


Maybe leave a comment about item values being allocated past the end of the struct, this is a bit of an obscure C feature.


Leave a comment that this must be at the end of the struct for the above reason.

This revision now requires changes to proceed.Dec 27 2018, 5:24 PM

This bit is copy & pasted from somewhere else, maybe this comment doesn't even apply here actually...


It is actually related to layering - the layer data structures allow having multiple temporary copies of the complete animation evaluation state (i.e. values) for use in complex blending. Currently the main use is the transition strip type that needs to independently evaluate both ends, and then interpolate. The data is structured as per-channel data NlaEvalChannelLayer structures, collected into a NlaEvalLayer variable length pointer array for fast indexing.

Maybe it would be better call it Snapshot instead of Layer?..


Snapshot sounds good to me.

For me it would have been more intuitively clear if was NlaEvalLayerChannel instead of NlaEvalChannelLayer, somehow that makes it more clear that this is owned by an NlaEvalLayer.


Should NlaEvalChannel then be named NlaEvalProperty?

I'm a bit confused because I thought the term "channel" always corresponded to a single array item. But maybe I'm mistaken, or the intent here is to give it a wider meaning. In any case an extended comment in this header file that explains things on a higher level would be helpful.


Like with that XXX comment there's no intent - I just kept the original name of the structure :)

Alexander Gavrilov (angavrilov) marked 9 inline comments as done.Dec 31 2018, 6:10 PM
Alexander Gavrilov (angavrilov) added inline comments.

Removed this confusing comment.


Renamed "layer" to "snapshot" everywhere. I think "channel snapshot" sounds better than "snapshot channel" though.

This revision is now accepted and ready to land.Jan 4 2019, 3:39 PM
Alexander Gavrilov (angavrilov) marked an inline comment as done.Jan 5 2019, 8:52 AM
This revision was automatically updated to reflect the committed changes.