NLA Animated Influence is ignored if strips below have zero total influence. #35382

New Issue

Josh Wedlake · 2013-05-15T23:29:42+02:00

Josh Wedlake commented

2013-05-15 23:29:42 +02:00

Relates to: #35263

%%%Please see the attached blend file first.

Apologies in advance if I've misunderstood any of the C code, I'm just a regular python hack but I think I've found a few issues in the NLA evaluation system.

Looking at nlaevalchan_accumulate in anim_sys.c it seems the behaviour I'm noticing might be intentional in some cases, though I find it very counter-intuitive in many other cases.
For example, a comment in the code reads...
/* if channel is new, just store value regardless of blending factors, etc. */

If I'm using an additive strip and set the 'animated influence' to zero, the evaluation system only observes this when there are strips below it which have an influence greater than 0 (or are not muted). I would expect 'animated influence to work like an opacity slider does, but the current behaviour means that if all strips below fade out (ie their influence fades to zero), as soon as they reach zero influence, the top strip suddenly becomes completely 'opaque' - ie its influence factor is ignored (nlaevalchan_accumulate returns value rather than value*inf as it recognises the channels as if they are new channels).

I'm not quite sure why this would be desirable? It might make sense to do this if there were no strips below, or if strips below were muted, but when strips below exist but their influence fades to zero it causes some nasty surprises. If you try to smoothly animate the influence of a lower strip towards the zero value the top strip suddenly 'pops' in on full influence. It seems to me that if a strip exists but has zero influence it should always create the channels present in it, rather than pretend the channels do not exist, AND/OR the influence of the top strip should always have effect regardless of whether the channel is new.

To make the NLA system behave more intuitively I need to add a 'dummy' strip at the bottom with all channels keyed at the rest pose to make sure that zero influence always means zero influence!

I realise that my suggested change might cause an issue with the way certain blend modes are currently calculated when animated influence is used.

Another related issue is the way influence is treated for multiply mode strips. Currently the influence factor affects ALL strips below, rather than just the current strip. For example in multiply mode the code does...

result=value_this_stripinfvalue_all_strips_below

Which to me does not seem like a way of controlling the influence of a multiply strip, rather it is a scalar for the channel? In fact the comment in the code states "multiply the scaled value with the stack" so I'm guessing this was Ali's intention to scale the value, but surely doing...

multiplied_value=(value_this_stripvalue_all_strips_below)
result=(value(1-influence)) + (multiplied_value * influence)

Would be much more intuitive in terms of influence, and much more similar to how we are used to adjusting layers in compositing/image packages?

For a multiply strip at the moment if influence==0, there is no effect on the evaluation of strips below (ie the same as multiplying by 1), but if influence = 0.01, then the value of all strips below is multiplied by the value of the current strip, then multiplied by 0.01! Again, fading from 0 to a non-zero value yields a surprising result! When influence==0 it is interpreted as influence, but when influence>0 it is interpreted as a scalar...?

Hopefully this is all clear and apologies if I've got the wrong end of the stick on how the NLA is supposed to work. I'm using it for crowd simulation work at the moment and was debugging my own code for hours before I checked to see what was going on inside blender's code!

%%%

**Relates to**: #35263 %%%Please see the attached blend file first. Apologies in advance if I've misunderstood any of the C code, I'm just a regular python hack but I think I've found a few issues in the NLA evaluation system. Looking at nlaevalchan_accumulate in anim_sys.c it seems the behaviour I'm noticing might be intentional in some cases, though I find it very counter-intuitive in many other cases. For example, a comment in the code reads... /* if channel is new, just store value regardless of blending factors, etc. */ If I'm using an additive strip and set the 'animated influence' to zero, the evaluation system only observes this when there are strips below it which have an influence greater than 0 (or are not muted). I would expect 'animated influence to work like an opacity slider does, but the current behaviour means that if all strips below fade out (ie their influence fades to zero), as soon as they reach zero influence, the top strip suddenly becomes completely 'opaque' - ie its influence factor is ignored (nlaevalchan_accumulate returns value rather than value*inf as it recognises the channels as if they are new channels). I'm not quite sure why this would be desirable? It might make sense to do this if there were no strips below, or if strips below were muted, but when strips below exist but their influence fades to zero it causes some nasty surprises. If you try to smoothly animate the influence of a lower strip towards the zero value the top strip suddenly 'pops' in on full influence. It seems to me that if a strip exists but has zero influence it should always create the channels present in it, rather than pretend the channels do not exist, AND/OR the influence of the top strip should always have effect regardless of whether the channel is new. To make the NLA system behave more intuitively I need to add a 'dummy' strip at the bottom with all channels keyed at the rest pose to make sure that zero influence always means zero influence! I realise that my suggested change might cause an issue with the way certain blend modes are currently calculated when animated influence is used. Another related issue is the way influence is treated for multiply mode strips. Currently the influence factor affects ALL strips below, rather than just the current strip. For example in multiply mode the code does... result=value_this_strip*inf*value_all_strips_below Which to me does not seem like a way of controlling the influence of a multiply strip, rather it is a scalar for the channel? In fact the comment in the code states "multiply the scaled value with the stack" so I'm guessing this was Ali's intention to scale the value, but surely doing... multiplied_value=(value_this_strip*value_all_strips_below) result=(value*(1-influence)) + (multiplied_value * influence) Would be much more intuitive in terms of influence, and much more similar to how we are used to adjusting layers in compositing/image packages? For a multiply strip at the moment if influence==0, there is no effect on the evaluation of strips below (ie the same as multiplying by 1), but if influence = 0.01, then the value of all strips below is multiplied by the value of the current strip, then multiplied by 0.01! Again, fading from 0 to a non-zero value yields a surprising result! When influence==0 it is interpreted as influence, but when influence>0 it is interpreted as a scalar...? Hopefully this is all clear and apologies if I've got the wrong end of the stick on how the NLA is supposed to work. I'm using it for crowd simulation work at the moment and was debugging my own code for hours before I checked to see what was going on inside blender's code! %%%

Josh Wedlake commented

2013-05-15 23:29:42 +02:00

Changed status to: 'Open'

Josh Wedlake commented

2013-05-16 15:26:49 +02:00

%%%Correction - my dummy strip ('background' strip) only contains the rest pose if the first strip above is a replacement strip, all zeroes if the first strip is additive, and all ones if the first strip above is a multiply strip... I guess this is complicated because rest quat W=1,rest scale=1, everything else at rest=0 (except custom props etc...)... which doesn't offer an easy solution on what new channels should 'influence'? But if they don't influence anything it still creates the popping problem for layers above...%%%

Joshua Leung commented

2013-06-09 15:06:20 +02:00

%%%- Main issue (re influence and blending) - well spotted. This is perhaps one of the greatest limitations I know of currently with this system, though admittedly I didn't quite realise that it would cause this particular problem (of popping when the influence drops to 0).

Currently we don't zero out all channels that may get affected in NLA if they are potentially involved in the stack somewhere (though the old 2.4x one did). Apart from the sheer logistics of it (i.e. we're no longer only dealing with armatures here), there is also the issue of what values we should zero things out to (e.g. it may in fact be totally unacceptable that before any strip has influence, things always snap back to 0-values, when you may want some other default pose to be held instead). IIRC, the old system used to suffer from such problems. Another related issue to this I noticed at one point was that results can be a bit non-deterministic if you there's a parameter that's only keyed on a strip that has a limited range only. Hence, it will always hold a value from somewhere within that strip (but where exactly we do not know) if you jump away from that strip while it is playing.

It's not entirely impossible to resolve these issues, but I've been a bit reluctant to go down that path since the beginning since it involves dancing around with caches or a table of all the channels in the stack, zeroing out these to acceptable defaults before each eval step, and then trying to keep these caches valid when things change (i.e. the tricky part). As this report shows though, this problem inevitably needs to be solved :/

Your workaround is perhaps the best option currently, though it is perhaps something that ideally shouldn't be needed (or at least clearly documented in the docs!).

Regarding the multiply stuff: Damn! You're right

When I wrote this, I really wasn't sure what a multiply should look like, and the current equation looked like a "close-enough" version.%%%

%%%- Main issue (re influence and blending) - well spotted. This is perhaps one of the greatest limitations I know of currently with this system, though admittedly I didn't quite realise that it would cause this particular problem (of popping when the influence drops to 0). Currently we don't zero out all channels that may get affected in NLA if they are potentially involved in the stack somewhere (though the old 2.4x one did). Apart from the sheer logistics of it (i.e. we're no longer only dealing with armatures here), there is also the issue of what values we should zero things out to (e.g. it may in fact be totally unacceptable that before any strip has influence, things always snap back to 0-values, when you may want some other default pose to be held instead). IIRC, the old system used to suffer from such problems. Another related issue to this I noticed at one point was that results can be a bit non-deterministic if you there's a parameter that's only keyed on a strip that has a limited range only. Hence, it will always hold a value from somewhere within that strip (but where exactly we do not know) if you jump away from that strip while it is playing. It's not entirely impossible to resolve these issues, but I've been a bit reluctant to go down that path since the beginning since it involves dancing around with caches or a table of all the channels in the stack, zeroing out these to acceptable defaults before each eval step, and then trying to keep these caches valid when things change (i.e. the tricky part). As this report shows though, this problem inevitably needs to be solved :/ Your workaround is perhaps the best option currently, though it is perhaps something that ideally shouldn't be needed (or at least clearly documented in the docs!). - Regarding the multiply stuff: Damn! You're right When I wrote this, I really wasn't sure what a multiply should look like, and the current equation looked like a "close-enough" version.%%%

Joshua Leung commented

2013-06-10 14:00:04 +02:00

%%%Ok, I've fixed both issues reported in this report.

The more severe issues I noted above still stand, and are likely candidates for refactoring soon (unless something else gets in the way).%%%

%%%Ok, I've fixed both issues reported in this report. The more severe issues I noted above still stand, and are likely candidates for refactoring soon (unless something else gets in the way).%%%

Joshua Leung commented

2013-06-10 14:00:04 +02:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2013-06-10 14:00:04 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

NLA Animated Influence is ignored if strips below have zero total influence. #35382