Buggy distortion when two NLA Strips overlap #36496

New Issue

David Brennan · 2013-08-17T19:26:59+02:00

David Brennan commented

2013-08-17 19:26:59 +02:00

Relates to: #37276

%%%--- Operating System, Graphics card ---
Windows 7.
Intel integrated graphics. (No GPU.)

- Blender version with error, and version that worked ---

Blender 2.68.
The Bug reportedly does not occur in 2.67.

- Short description of error ---

When two NLA Strips overlap, there is a bizarre problem in which some of the values become distorted. In this case, the Scale and Location of a character's Root Bone suddenly explode when the two strips overlap.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Simply check out the attached .Blend and hit play.

%%%

**Relates to**: #37276 %%%--- Operating System, Graphics card --- Windows 7. Intel integrated graphics. (No GPU.) - Blender version with error, and version that worked --- Blender 2.68. The Bug reportedly does not occur in 2.67. - Short description of error --- When two NLA Strips overlap, there is a bizarre problem in which some of the values become distorted. In this case, the Scale and Location of a character's Root Bone suddenly explode when the two strips overlap. - Steps for others to reproduce the error (preferably based on attached .blend file) --- Simply check out the attached .Blend and hit play. %%%

David Brennan commented

2013-08-17 19:26:59 +02:00

Changed status to: 'Open'

blender-admin commented

2013-08-17 19:26:59 +02:00

#37455 was marked as duplicate of this issue

Ton Roosendaal commented

2013-08-23 19:10:05 +02:00

%%%I don't think strips in NLA were meant to overlap even? Joshua can tell more though.%%%

David Brennan commented

2013-09-04 21:43:52 +02:00

%%%Yeah, NLA strips are definitely intended to overlap. That is one of their biggest attributes: the blending between two overlapping strips!

Has anybody diagnosed or further investigated this?%%%

%%%Yeah, NLA strips are definitely intended to overlap. That is one of their biggest attributes: the blending between two overlapping strips! Has anybody diagnosed or further investigated this?%%%

Joshua Leung commented

2013-11-01 13:02:38 +01:00

%%%Hi,

Apologies for the delay in getting around to investigating this further. It's been a hectic few months on my end, so any non-work commitments have had to take a bit of a backseat for a while.

Before I started getting busy, I had a poke around trying to figure out why exactly the problem was arising in this particular case. The specific problem appears to have something to do with how small scale values interact with the influence setting and/or the "base" values used when there are no strips. I'm still not sure why exactly these end up bugging out yet, but I'll keep investigating (perhaps plotting out some more detailed charts of what's going on to get a better picture).

In the meantime, the workaround here is to ensure that you've got a strip at the bottom of your NLA stack which includes the "default" values for all channels animated in your NLA strips, and make it so that this strip has full influence over the entire range of the animation frame range. Specifically, make sure that you've got keyframes for the 0.054 scale you've set on the root bone within this action/strip at the bottom of the stack. Once you've done this, you don't really need to have the scale in the tracks above, though it doesn't hurt to keep it there either, as everything should behave once you do this.

Note: I've been pondering about ways to automate this process for having a "base" strip created/updated automatically. It seems increasingly likely that it will be necessary to have something like this to avoid some other weird quirks the can arise (most notably those seen in your other report). %%%

%%%Hi, Apologies for the delay in getting around to investigating this further. It's been a hectic few months on my end, so any non-work commitments have had to take a bit of a backseat for a while. Before I started getting busy, I had a poke around trying to figure out why exactly the problem was arising in this particular case. The specific problem appears to have something to do with how small scale values interact with the influence setting and/or the "base" values used when there are no strips. I'm still not sure why exactly these end up bugging out yet, but I'll keep investigating (perhaps plotting out some more detailed charts of what's going on to get a better picture). In the meantime, the workaround here is to ensure that you've got a strip at the bottom of your NLA stack which includes the "default" values for all channels animated in your NLA strips, and make it so that this strip has full influence over the entire range of the animation frame range. Specifically, make sure that you've got keyframes for the 0.054 scale you've set on the root bone within this action/strip at the bottom of the stack. Once you've done this, you don't really need to have the scale in the tracks above, though it doesn't hurt to keep it there either, as everything should behave once you do this. Note: I've been pondering about ways to automate this process for having a "base" strip created/updated automatically. It seems increasingly likely that it will be necessary to have something like this to avoid some other weird quirks the can arise (most notably those seen in your other report). %%%

David Brennan commented

2013-11-01 13:08:25 +01:00

%%%Joshua,

I will test out this "base strip" work-around, which I think I will have to experiment with to fully comprehend.

I appreciate the time and effort (I'm sure many other silently seething animators will, too.) I'll be on the lookout for updates, and if you need other .Blend samples, just say so.%%%

%%%Joshua, I will test out this "base strip" work-around, which I think I will have to experiment with to fully comprehend. I appreciate the time and effort (I'm sure many other silently seething animators will, too.) I'll be on the lookout for updates, and if you need other .Blend samples, just say so.%%%

Joshua Leung commented

2013-11-01 13:44:31 +01:00

%%%I've just done a few more tests of the blending formulas: from the looks of things, an easer workaround would be to simply disable the blend-out on the lower strip (by disabling "auto-blends"). However, for reasons of preventing weird errors on some channels only being keyed in some strips, I'd still recommend the base strip workaround for now as the more comprehensive solution.

I've attached a little spreadsheet of the current blending method to illustrate/investigate this problem. It's probably better to have this inline here for good measure.%%%

%%%I've just done a few more tests of the blending formulas: from the looks of things, an easer workaround would be to simply disable the blend-out on the lower strip (by disabling "auto-blends"). However, for reasons of preventing weird errors on some channels only being keyed in some strips, I'd still recommend the base strip workaround for now as the more comprehensive solution. I've attached a little spreadsheet of the current blending method to illustrate/investigate this problem. It's probably better to have this inline here for good measure.%%%

David Brennan commented

2013-11-02 07:21:39 +01:00

%%%Unfortunately, I don't know any programming. However, wouldn't it be possible to simply cut-and-paste the NLA code from 2.67 (where it worked fine) to 2.69? Alternately, I think document programs can identify differences automatically, so you could immediately spot any changes that were made and deduce the problem that way.

Also, for any lurkers, I tried the latter work-around (disabling the blending of the strips altogether) and that did not work immediately. I first had to push the higher NLA Strip up to a new track (so that it is not directly overlapping the one we want to blend with). After doing this once, I could then put the NLA Strip back to the lower track, and then the wonkiness did not occur (although, then there was no blending of the values).

Your works are appreciated, Joshua.%%%

%%%Unfortunately, I don't know any programming. However, wouldn't it be possible to simply cut-and-paste the NLA code from 2.67 (where it worked fine) to 2.69? Alternately, I think document programs can identify differences automatically, so you could immediately spot any changes that were made and deduce the problem that way. Also, for any lurkers, I tried the latter work-around (disabling the blending of the strips altogether) and that did not work immediately. I first had to push the higher NLA Strip up to a new track (so that it is not directly overlapping the one we want to blend with). After doing this once, I could then put the NLA Strip back to the lower track, and then the wonkiness did not occur (although, then there was no blending of the values). Your works are appreciated, Joshua.%%%

David Brennan commented

2013-11-08 18:06:47 +01:00

%%%Joshua,

Has there been any progress with this? I'm again at a point where the Bug is absolutely preventing further work on an animation of mine: http://www.pasteall.org/pic/show.php?id=62237

(I can't understand how this isn't causing problems for tons and tons and tons of users. Virtually all my animations use the NLA setup.)%%%

%%%Joshua, Has there been any progress with this? I'm again at a point where the Bug is absolutely preventing further work on an animation of mine: http://www.pasteall.org/pic/show.php?id=62237 (I can't understand how this isn't causing problems for tons and tons and tons of users. Virtually all my animations use the NLA setup.)%%%

David Brennan commented

2013-11-09 08:10:21 +01:00

%%%Joshua,

Here are a few facts which could aid in the effort to solve this Bug.

Antont at the BlenderCoders IRC channel found this discussion of the Bug from back in July (in a conversation you participated in):

fdf38b56c3

There it is noted that this apparently first popped up in "r.57333". %%%

%%%Joshua, Here are a few facts which could aid in the effort to solve this Bug. Antont at the BlenderCoders IRC channel found this discussion of the Bug from back in July (in a conversation you participated in): https://github.com/antont/blender/commit/fdf38b56c3f31a418d02171eefd2b92c242aaeca There it is noted that this apparently first popped up in "r.57333". %%%

David Brennan commented

2013-11-09 08:32:43 +01:00

%%%Here is a link to a different .Blend for testing and diagnosing:

http://www.pasteall.org/blend/25112%%%

%%%Here is a link to a different .Blend for testing and diagnosing: http://www.pasteall.org/blend/25112%%%

Toni Alatalo commented

2013-11-09 09:48:53 +01:00

%%%I tried to revert that commit to test - it did not work automatically, so I just disabled it manually by commenting out the call to nlaevalchan_value_init(ned)

that seemed to fix the case in the original untitled.blend here (if the walk anim is supposed to move the char away from the cam) -- the zoom jump at least went away.

the code structure here had changed a bit so this revert-attempt can be broken otherwise, anyhow just for info this is how i tried it:
b6b7674952

this is probably nothing new for Aligorith who has worked on the code and analysed the issue already etc but reporting just in case there's something useful.%%%

%%%I tried to revert that commit to test - it did not work automatically, so I just disabled it manually by commenting out the call to nlaevalchan_value_init(ned) that seemed to fix the case in the original untitled.blend here (if the walk anim is supposed to move the char away from the cam) -- the zoom jump at least went away. the code structure here had changed a bit so this revert-attempt can be broken otherwise, anyhow just for info this is how i tried it: https://github.com/antont/blender/commit/b6b7674952703ebcd352aeb82f944b4a082bff83 this is probably nothing new for Aligorith who has worked on the code and analysed the issue already etc but reporting just in case there's something useful.%%%

David Brennan commented

2013-11-09 09:54:18 +01:00

%%%Great thanks, Toni. This will probably contribute to the eventual fixing of this all.%%%

Brecht Van Lommel commented

2013-11-14 22:10:53 +01:00

◀ Merged tasks: #37455.

David Brennan commented

2013-12-11 11:10:05 +01:00

Has there been any progress towards a fix?

David Brennan commented

2014-02-17 10:13:36 +01:00

This Bug - which, for me, makes extensive character animation virtually impossible (I am still using 2.67) - has not been fixed as of "blender-2.69-cc7cfd6" (the latest build as of February 17).

Because the 2.70 release is at BCon4 and, therefore, is now dedicated solely to Bug fixing, and because this is such a HUGE Bug (as I said, it makes character animation nearly impossible), I would be very appreciative if somebody would actually fix it.

In addition to all the other .Blend samples, I've attached a new example of this with Batman running and then jumping between two NLA Strips.

(As a side note, the Grease Pencil was not working, but I'll file a separate Bug Report for that.)

NLA-StripOverlapProblem.blend

This Bug - which, for me, makes extensive character animation virtually impossible (I am still using 2.67) - has not been fixed as of "blender-2.69-cc7cfd6" (the latest build as of February 17). Because the 2.70 release is at BCon4 and, therefore, is now dedicated solely to Bug fixing, and because this is such a HUGE Bug (as I said, it makes character animation nearly impossible), I would be very appreciative if somebody would actually fix it. In addition to all the other .Blend samples, I've attached a new example of this with Batman running and then jumping between two NLA Strips. (As a side note, the Grease Pencil was not working, but I'll file a separate Bug Report for that.) [NLA-StripOverlapProblem.blend](https://archive.blender.org/developer/F77697/NLA-StripOverlapProblem.blend)

Sergey Sharybin commented

2014-02-17 10:22:36 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-02-17 10:22:36 +01:00

@JoshuaLeung, any luck into this report?

David Brennan commented

2014-02-24 22:10:57 +01:00

Is there anybody besides Aligorith who can look at this? I don't know what his timeline is, but it wasn't before 2.69, and now it's clearly not before 2.70.

Again, it worked fine in 2.67, and so a simple comparison between that and 2.68 should help greatly in identifying the source of the glitching.

Is there anybody besides Aligorith who can look at this? I don't know what his timeline is, but it wasn't before 2.69, and now it's clearly not before 2.70. Again, it worked fine in 2.67, and so a simple comparison between that and 2.68 should help greatly in identifying the source of the glitching.

David Brennan commented

2014-02-27 17:10:09 +01:00

Is there ANY way that this critical bug could be fixed for 2.70?

Brecht Van Lommel commented

2014-02-27 22:18:24 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2014-02-27 22:18:24 +01:00

From what I can tell this issue was first introduced with {27d792fa9ca103a4f669ab6e26bbb7f2c89f064c}, which fixed bugs #35263 and #35382. Reverting that commit makes those bugs appear again, so that alone is not a good solution.

Those other bugs were with blend mode Add, while this file is using blend mode Replace. So to fix both cases, here's a patch that reverts to the old behavior for Replace mode, but keeps the new behavior for Add mode: fix_T36496.diff

What this does is that to not do any blending for the first strip, rather than blending the first strip with the default value for the channels (e.g. 0,0,0 for locations and 1,1,1 for scale). This seems more useful to me, and if someone actually wants the old behavior they can still make an action with the default pose and use that as the first strip.

@JoshuaLeung, do you think this fix would be ok to commit?

From what I can tell this issue was first introduced with {27d792fa9ca103a4f669ab6e26bbb7f2c89f064c}, which fixed bugs #35263 and #35382. Reverting that commit makes those bugs appear again, so that alone is not a good solution. Those other bugs were with blend mode Add, while this file is using blend mode Replace. So to fix both cases, here's a patch that reverts to the old behavior for Replace mode, but keeps the new behavior for Add mode: [fix_T36496.diff](https://archive.blender.org/developer/F79182/fix_T36496.diff) What this does is that to not do any blending for the first strip, rather than blending the first strip with the default value for the channels (e.g. 0,0,0 for locations and 1,1,1 for scale). This seems more useful to me, and if someone actually wants the old behavior they can still make an action with the default pose and use that as the first strip. @JoshuaLeung, do you think this fix would be ok to commit?

David Brennan commented

2014-03-01 04:59:07 +01:00

brecht,

I greatly appreciate your work on this. Greatly. (I continue to be surprised that more people are not reporting this. Perhaps others just don't use the NLA as much as I do.)

However, I downloaded the nightly build (from February 28) and did not notice any changes. Is the patch included in that? I don't know how to plug the patch in, on my own.

brecht, I greatly appreciate your work on this. *Greatly*. (I continue to be surprised that more people are not reporting this. Perhaps others just don't use the NLA as much as I do.) However, I downloaded the nightly build (from February 28) and did not notice any changes. Is the patch included in that? I don't know how to plug the patch in, on my own.

Brecht Van Lommel commented

2014-03-01 15:40:43 +01:00

There's no build yet with this fix, I'm waiting for feedback from @JoshuaLeung since I'm not so familiar with this code. But if he doesn't have time before the release I can still commit it I think, I'm pretty sure the fix is ok.

Joshua Leung commented

2014-03-03 10:53:00 +01:00

@brecht: Thanks for looking into this. It looks like a workable solution :)

blender-admin commented

2014-03-03 16:34:10 +01:00

This issue was referenced by blender/blender-addons-contrib@53b03eff96

This issue was referenced by blender/blender-addons-contrib@53b03eff965d6bd82dfb2db01d77a599c367d187

blender-admin commented

2014-03-03 16:34:10 +01:00

This issue was referenced by 53b03eff96

This issue was referenced by 53b03eff965d6bd82dfb2db01d77a599c367d187

Brecht Van Lommel commented

2014-03-03 16:41:35 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2014-03-03 16:41:35 +01:00

Brecht Van Lommel commented

2014-03-03 16:41:35 +01:00

Closed by commit 53b03eff96.

Closed by commit 53b03eff96.

David Brennan commented

2014-03-05 01:27:01 +01:00

Whew! Just downloaded the Daily Build and, at last, I can delete my old 2.67 version that I was using for character animations!

Thanks so much, brecht! And, of course, great thanks as always to everybodyat Blender. God bless!

Whew! Just downloaded the Daily Build and, at last, I can delete my old 2.67 version that I was using for character animations! Thanks so much, brecht! And, of course, great thanks as always to *everybody*at Blender. God bless!

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

Buggy distortion when two NLA Strips overlap #36496