Armature animation glitch when using collection instances across scenes #105873

Open
opened 2023-03-18 05:55:06 +01:00 by LOIC BRAMOULLE · 27 comments

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.49

Blender Version
Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: rB55485cb379f7
Worked: Probably never (2.90 is buggy still)

Short description of error
When an armature is included in a collection, and that collection is instanced in another scene, selecting a bone or moving in the timeline creates a seemingly random time-jump in the posing/animation, until the bone is moved, at which point the whole armature snaps back into its real position.

This issue only occurs when an armature is included in a collection that is instanced in another scene. If the armature is not in a collection or is not instanced, the animation plays back as expected. The meshes under the armature does the same, if one mesh stays in the collection, the bug still happens, everything needs to be removed for the bug not to happen.

Workaround:
Moving the bone causes the entire armature to snap back into its correct position, so this can be used as a workaround to keep the animation accurate. Alternatively, the armature can be removed from the collection and into the main scene hierarchy.

Thank you for looking into this issue.

Exact steps for others to reproduce the error

  • Open attached file
  • Click on any bone

The pose will change. Change frame and pose will jump unexpectedly again.

Some info that may be helpful: This issue seems to happen when persistent data is enabled and frame is rendered. Armature will then "remembers" last rendered frame. The cause may be linked to usage of Autorig pro addon.

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.49 **Blender Version** Broken: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-19 17:00, hash: `rB55485cb379f7` Worked: Probably never (2.90 is buggy still) **Short description of error** When an armature is included in a collection, and that collection is instanced in another scene, selecting a bone or moving in the timeline creates a seemingly random time-jump in the posing/animation, until the bone is moved, at which point the whole armature snaps back into its real position. This issue only occurs when an armature is included in a collection that is instanced in another scene. If the armature is not in a collection or is not instanced, the animation plays back as expected. The meshes under the armature does the same, if one mesh stays in the collection, the bug still happens, everything needs to be removed for the bug not to happen. Workaround: Moving the bone causes the entire armature to snap back into its correct position, so this can be used as a workaround to keep the animation accurate. Alternatively, the armature can be removed from the collection and into the main scene hierarchy. Thank you for looking into this issue. **Exact steps for others to reproduce the error** * Open attached file * Click on any bone The pose will change. Change frame and pose will jump unexpectedly again. Some info that may be helpful: This issue seems to happen when persistent data is enabled and frame is rendered. Armature will then "remembers" last rendered frame. The cause may be linked to usage of Autorig pro addon.
LOIC BRAMOULLE added the
Priority
Normal
Type
Report
Status
Needs Triage
labels 2023-03-18 05:55:07 +01:00

Hello. I was unable to reproduce this in 3.6 and 3.4.
Can you specify more precise playback steps (for example, how exactly should you switch between scenes?)
Or can you show an example file? There's also a chance it's fixed in newer releases, you can check that out as well.

Hello. I was unable to reproduce this in 3.6 and 3.4. Can you specify more precise playback steps (for example, how exactly should you switch between scenes?) Or can you show an example file? There's also a chance it's fixed in newer releases, you can check that out as well.
Iliya Katushenock added the
Interest
Animation & Rigging
label 2023-03-18 13:01:16 +01:00
Pratik Borhade added
Status
Needs Information from User
and removed
Status
Needs Triage
labels 2023-03-19 03:13:52 +01:00
Author

Hi, thanks for having a look. It's the second project where I have this issue, last time was a year ago on 2.9 I think. I have two very different characters with AutoRig-Pro armatures, both have the bug. The armatures are either hard-duplicated or linked, and some in collection instances to appear in other scenes (so their visibility can be animated to match camera markers, to appear in only the shot they belong.)
The scene is under NDA, but I can share a workbench view, where I simply alternate between selecting a bone, moving a couple frames in the timeline. Both actions create this jump between the real posing, and the "fake" one that puts the armature far away from the transform gizmo, where it appears maybe in another scene at another time, not sure why this position.
I tried appending the collection to a blanck scene and the issue doesn't appear, so it might be more complex than that.
But removing the amrature and mesh from the collection, But also the mesh that has a constraint to follow the hand of the armature, solves the bug. But if a mesh is still parented or constrained to the armature while being in a collection, the bug persists. Only having everything at the scene root/collection it behaves normally.
So to me right now it's not an issue at all with this workaround, but I suspect some people might panic a bit when they can't animate their projects anymore. (as the bug totally prevents animating, impossible to see what you're doing.)

Hi, thanks for having a look. It's the second project where I have this issue, last time was a year ago on 2.9 I think. I have two very different characters with AutoRig-Pro armatures, both have the bug. The armatures are either hard-duplicated or linked, and some in collection instances to appear in other scenes (so their visibility can be animated to match camera markers, to appear in only the shot they belong.) The scene is under NDA, but I can share a workbench view, where I simply alternate between selecting a bone, moving a couple frames in the timeline. Both actions create this jump between the real posing, and the "fake" one that puts the armature far away from the transform gizmo, where it appears maybe in another scene at another time, not sure why this position. I tried appending the collection to a blanck scene and the issue doesn't appear, so it might be more complex than that. But removing the amrature and mesh from the collection, But also the mesh that has a constraint to follow the hand of the armature, solves the bug. But if a mesh is still parented or constrained to the armature while being in a collection, the bug persists. Only having everything at the scene root/collection it behaves normally. So to me right now it's not an issue at all with this workaround, but I suspect some people might panic a bit when they can't animate their projects anymore. (as the bug totally prevents animating, impossible to see what you're doing.)
Iliya Katushenock added
Status
Needs Triage
and removed
Status
Needs Information from User
labels 2023-03-19 10:26:35 +01:00

@loicbramoulle Can you simplify the file so NDA doesn't apply? Or is it possible to create such file from scratch? Without sample file I can't reproduce the report.

@loicbramoulle Can you simplify the file so NDA doesn't apply? Or is it possible to create such file from scratch? Without sample file I can't reproduce the report.
Richard Antalik added
Status
Needs Information from User
and removed
Status
Needs Triage
labels 2023-03-28 18:30:34 +02:00
Author

Hi iss, thanks. I just tried to prepared a stripped down version, but I realized that I soon as I delete a scene, even one that does'nt have a single element in commong, the bug disapears, does it only once when entering pose mode, and display the anim correctly after that.
So I gathered more behaviour on the bug, basically, each thing that triggers it are:

  • entering pose mode
  • exiting pose mode
  • in pose mode, selecting a bone.
    The bug itself is:
    the armature taking exactly the last pose of the animation (even if stored inside a nla track.)
    And moving in the timeline, in or out of pose mode, always "removes" the bug instantly by displaying the actual pose/animation at that instant.

So basically, if entering pose mode, the armature jumps/takes the last posing of the anim, so clicking anywhere (except on the last frame of the animation) creates a jump again back into the real pose at that frame. if I click on the last frame of the animation the jump/bug is not visible as that was already the pose that was erratically displayed.

Hi iss, thanks. I just tried to prepared a stripped down version, but I realized that I soon as I delete a scene, even one that does'nt have a single element in commong, the bug disapears, does it only once when entering pose mode, and display the anim correctly after that. So I gathered more behaviour on the bug, basically, each thing that triggers it are: - entering pose mode - exiting pose mode - in pose mode, selecting a bone. The bug itself is: the armature taking exactly the last pose of the animation (even if stored inside a nla track.) And moving in the timeline, in or out of pose mode, always "removes" the bug instantly by displaying the actual pose/animation at that instant. So basically, if entering pose mode, the armature jumps/takes the last posing of the anim, so clicking anywhere (except on the last frame of the animation) creates a jump again back into the real pose at that frame. if I click on the last frame of the animation the jump/bug is not visible as that was already the pose that was erratically displayed.
Author

Ok did more tests with scene deletion, deleting unrelated scenes did not in fact make the bug disapear, but deleting the scene that has this animated character collection instanced in it, removed the bug. Doing a ctrl+z to undelete the scene restored it (as it should) but the bug is now gone.
Ok tried it a few more times, the bug is only gone from the active scene, if the main scene is restored with redo. But that time the posing that is taken is the first one of the animation.. And only on one of the characters now.. so sorry it's super confusing to diagnose what's happening. will keep trying to simplify the file until there's just a couple of scenes with 100% of the bug.

Ok did more tests with scene deletion, deleting unrelated scenes did not in fact make the bug disapear, but deleting the scene that has this animated character collection instanced in it, removed the bug. Doing a ctrl+z to undelete the scene restored it (as it should) but the bug is now gone. Ok tried it a few more times, the bug is only gone from the active scene, if the main scene is restored with redo. But that time the posing that is taken is the first one of the animation.. And only on one of the characters now.. so sorry it's super confusing to diagnose what's happening. will keep trying to simplify the file until there's just a couple of scenes with 100% of the bug.
Author

Ok I managed to strip down everything apart from the armatures in the scene, while conserving the bug on both characters, in all instances and scenes:
https://www.dropbox.com/s/ulf936ko0112t54/blender_armature_issue_2.blend?dl=0
Thanks if anyone manages to get to the bottom of it so anyone having the issue too doesn't have to rely on the workaround
(dragging armature + childs/constrained meshes out of any collection, animate, and back in.)

Ok I managed to strip down everything apart from the armatures in the scene, while conserving the bug on both characters, in all instances and scenes: https://www.dropbox.com/s/ulf936ko0112t54/blender_armature_issue_2.blend?dl=0 Thanks if anyone manages to get to the bottom of it so anyone having the issue too doesn't have to rely on the workaround (dragging armature + childs/constrained meshes out of any collection, animate, and back in.)

Thanks for file. It seems to work well here, but perhaps I am missing something. Can you clarify steps for how should I reproduce this? Please be as exact as possible.

Also check if this issue happens with alpha build from https://builder.blender.org/download/daily/

Thanks for file. It seems to work well here, but perhaps I am missing something. Can you clarify steps for how should I reproduce this? Please be as exact as possible. Also check if this issue happens with alpha build from https://builder.blender.org/download/daily/
Author

Hi, thanks, I just tested with yesterday's 3.5 release, and the bug is still here on my end.
3 things trigger it (each):
go in or out of pose mode, and selecting a bone.
Moving in the timeline reveals the bug too as the armature snaps back into it's real pose.
I just tested on another machine in case, the bug is there too.
Just tested on today's 3.6 build too, same the bug is still there.
In theory if you just alternate between toggling pose mode/selecting a bone, and moving on the timeline like 1 frame, you should definitly see it. The armature takes a pose from the very end of the animation. if the current time is the end of the anim it's not visible, but if you're at the start of the anim, the armature jumps to the end pose each time you do one of the 3 things, and back when moving the timeline (or moving a bone), where it reveals back the actual posing at that time.

Hi, thanks, I just tested with yesterday's 3.5 release, and the bug is still here on my end. 3 things trigger it (each): go in or out of pose mode, and selecting a bone. Moving in the timeline reveals the bug too as the armature snaps back into it's real pose. I just tested on another machine in case, the bug is there too. Just tested on today's 3.6 build too, same the bug is still there. In theory if you just alternate between toggling pose mode/selecting a bone, and moving on the timeline like 1 frame, you should definitly see it. The armature takes a pose from the very end of the animation. if the current time is the end of the anim it's not visible, but if you're at the start of the anim, the armature jumps to the end pose each time you do one of the 3 things, and back when moving the timeline (or moving a bone), where it reveals back the actual posing at that time.

Can you make a short recording of how this looks? Maybe also check mine to see if the steps are correct.

Also forgot, please click on Help > Save System Info and upload saved file.

Can you make a short recording of how this looks? Maybe also check mine to see if the steps are correct. Also forgot, please click on Help > Save System Info and upload saved file.
Author

Thanks, damn yes the bug doesn't happen on your end, so strange. Maybe it's caused by some addon then.
Here is my system info, I can boot my second pc to get the system info too.

I added a video on my second message at the top here. Basically the character jumps to its final pose, forward.

Thanks

Thanks, damn yes the bug doesn't happen on your end, so strange. Maybe it's caused by some addon then. Here is my system info, I can boot my second pc to get the system info too. I added a video on my second message at the top here. Basically the character jumps to its final pose, forward. Thanks

Yeah, that't a lot of addons. Can you run file blender_factory_startup.cmd from daily build folder and re-check?

Yeah, that't a lot of addons. Can you run file `blender_factory_startup.cmd` from daily build folder and re-check?

Sorry, I have checked the video, and I can reproduce the issue. Will confirm.

Sorry, I have checked the video, and I can reproduce the issue. Will confirm.
Author

Hi, I'm running into a very similar issue, so will describe here:
I'm in a EDIT file, I have linked a rigged character from a RIG file, and some actions of it from a ANIM file. I place the actions on NLA tracks ect.. I did that on a test scene and no problem, here on the EDIT file where I will render, when entering or exiting pose mode, or when selecting any bone, the character goes in A pose/rest pose mode (like if it ignored the bottom NLA track/action, except the top action where I just move the Traj ctrl.) and moving one frame in the timeline un-bugs it, the character get into pose again.

This is a full show-stopper as any bone I select, OR move, make the armature ignore its action and teleport far away.

Attached is a screenshot where you can see the Traj rig controler on the left of the image, having jumped back into its real position, while the transform gizmo is still bugged on the right of the image, where the character goes when ignoring its animation.
Scrolling in the timeline display everything properly, the armature is animated where it should, but selecting or editing any bone transforms make the armature jump to rest pose/ignoring its action.

Hi, I'm running into a very similar issue, so will describe here: I'm in a EDIT file, I have linked a rigged character from a RIG file, and some actions of it from a ANIM file. I place the actions on NLA tracks ect.. I did that on a test scene and no problem, here on the EDIT file where I will render, when entering or exiting pose mode, or when selecting any bone, the character goes in A pose/rest pose mode (like if it ignored the bottom NLA track/action, except the top action where I just move the Traj ctrl.) and moving one frame in the timeline un-bugs it, the character get into pose again. This is a full show-stopper as any bone I select, OR move, make the armature ignore its action and teleport far away. Attached is a screenshot where you can see the Traj rig controler on the left of the image, having jumped back into its real position, while the transform gizmo is still bugged on the right of the image, where the character goes when ignoring its animation. Scrolling in the timeline display everything properly, the armature is animated where it should, but selecting or editing any bone transforms make the armature jump to rest pose/ignoring its action.
Author

Ok I deleted the linked library (the character) and re-appended it, the issue is gone, but another one appeared, the NLA tracks added as overides initially in the test scene, that I appended (so armature & actions are still linked, but NLA tracks are local as overides) these NLA tracks cannot be edited, rename or delete doesn't work, moving strips can only be done in each of these tracks, no strip can go out or come in of these tracks.

Basically there's some odd thingshappening when we append a collection, that has linked armature & overides. It either starts mishaving, or its NLA tracks are believed by blender to be linked, athought they're local.

Ok I deleted the linked library (the character) and re-appended it, the issue is gone, but another one appeared, the NLA tracks added as overides initially in the test scene, that I appended (so armature & actions are still linked, but NLA tracks are local as overides) these NLA tracks cannot be edited, rename or delete doesn't work, moving strips can only be done in each of these tracks, no strip can go out or come in of these tracks. Basically there's some odd thingshappening when we append a collection, that has linked armature & overides. It either starts mishaving, or its NLA tracks are believed by blender to be linked, athought they're local.
Author

Hum, it actually seems to be a broader bug in blender, because now that I deleted all overides on the armature, remade the whole NLA track setup, I have a similar issue (an animation jumping to defaut pose when clicking one element tied o it) but on a RGB curve plugged into an animated MixRGB, on a model that has no connection to the armature, not even in the same scene.
If I click the non-animated RGB curve point, it sets the MixRGB value to "1", but it's animated and written as 0.634 or whatever the animated value is at that point.
HAd the same issue with a shapekey too I think, basically a bunch of random things starts to "visually jump" out of the values they actually have as they're animated, into a "default" value, as soon as they're clicked. And moving in the timeline even just one frame displays it again correctly.

Hum, it actually seems to be a broader bug in blender, because now that I deleted all overides on the armature, remade the whole NLA track setup, I have a similar issue (an animation jumping to defaut pose when clicking one element tied o it) but on a RGB curve plugged into an animated MixRGB, on a model that has no connection to the armature, not even in the same scene. If I click the non-animated RGB curve point, it sets the MixRGB value to "1", but it's animated and written as 0.634 or whatever the animated value is at that point. HAd the same issue with a shapekey too I think, basically a bunch of random things starts to "visually jump" out of the values they actually have as they're animated, into a "default" value, as soon as they're clicked. And moving in the timeline even just one frame displays it again correctly.
Author

Ok the bug came back on the armature, it's really serious as it makes blender unviable for animation production. I don't get how blender studio can make short films with this issue, I'm not doing anything special, literally just animating an armature, and that triggers that "pose" jump bug. The first case basically everything was different, the only common point is that it's an Autorig pro armature, but everything else is different, so it looks like a core blender bug.
Now it does it on this linked character + actions on Nla tracks, but the first time the character was local and had just a simple action directly playing without nla tracks. Also two different blender version, 3.4 & 3.5. will test on 3.6 & beta builds but already did this last time.
This puts me in a very problematic position professionally rigth now, the whole cinematic rest on being able to animate this character in context of all the shots in that scene..

Ok the bug came back on the armature, it's really serious as it makes blender unviable for animation production. I don't get how blender studio can make short films with this issue, I'm not doing anything special, literally just animating an armature, and that triggers that "pose" jump bug. The first case basically everything was different, the only common point is that it's an Autorig pro armature, but everything else is different, so it looks like a core blender bug. Now it does it on this linked character + actions on Nla tracks, but the first time the character was local and had just a simple action directly playing without nla tracks. Also two different blender version, 3.4 & 3.5. will test on 3.6 & beta builds but already did this last time. This puts me in a very problematic position professionally rigth now, the whole cinematic rest on being able to animate this character in context of all the shots in that scene..
Author

More attempts at diagnosing the bug, it "jumps" what's animated to whatever value is at frame 429, whatever being the current frame. So if I move keyframes around, it will snap erratically the bone to whatever value is at frame 429. I'm at frame 505, it displays the frame 429 value. Now tetsing, I'm at frame 199, it still "jumps" erratically at whatever value is at frame 429. So basically the frame 429 is cursed and whatever animated property I interact with (bone, shade node, shapekay... I think.) will jump to frame 429.
I trapped the frame 429 with an absurd visually recognisable value, and yes whatever I do the bone will jump to that identifiable position in space, no matter what current frame is active, in the past or future from frame 429...
I tested on different bones, added a rotation that only exist on frame 429, and wherever I am on the timeline, if I click on one bone, the whole character armature will take the value it would have at frame 429 (the stupid visually identifiable value I trapped there for testing.)

image

I dunno it's really confusing, maybe we should delete frame 429, it's cursed. what is going on....

More attempts at diagnosing the bug, it "jumps" what's animated to whatever value is at frame 429, whatever being the current frame. So if I move keyframes around, it will snap erratically the bone to whatever value is at frame 429. I'm at frame 505, it displays the frame 429 value. Now tetsing, I'm at frame 199, it still "jumps" erratically at whatever value is at frame 429. So basically the frame 429 is cursed and whatever animated property I interact with (bone, shade node, shapekay... I think.) will jump to frame 429. I trapped the frame 429 with an absurd visually recognisable value, and yes whatever I do the bone will jump to that identifiable position in space, no matter what current frame is active, in the past or future from frame 429... I tested on different bones, added a rotation that only exist on frame 429, and wherever I am on the timeline, if I click on one bone, the whole character armature will take the value it would have at frame 429 (the stupid visually identifiable value I trapped there for testing.) ![image](/attachments/4db08bf9-7134-43e0-b0b0-b159270cb292) I dunno it's really confusing, maybe we should delete frame 429, it's cursed. what is going on....
550 KiB
Author

Tried to have only the linked character collection in a new scene, bug persists. Moving in the timeline shows the animations correctly, but the transform gizmos are actually never elsewhere than on this frame 429 value, I scroll to play the animation correctly, the gismo stays tehre on that frame 429 value, it's crazy. If I click anywhere on the armature it jumps to that frame 429 value, no matter where I am on the timeline....
image

Tried to have only the linked character collection in a new scene, bug persists. Moving in the timeline shows the animations correctly, but the transform gizmos are actually never elsewhere than on this frame 429 value, I scroll to play the animation correctly, the gismo stays tehre on that frame 429 value, it's crazy. If I click anywhere on the armature it jumps to that frame 429 value, no matter where I am on the timeline.... ![image](/attachments/9ec226d4-4fc7-4d1a-9ad3-55499b2df872)
Author

Copy pasting the armature in a blank file doesn't bring the issue there in this new file, so it's bound to the file, not the armature (it syas linked with all its Nla tracks once copy pasted in a new file, and doesn't have the bug). It was created in blender 3.3 by another department in the studio, like the file where the very similar bug appeared at the beginning of this thread.

Copy pasting the armature in a blank file doesn't bring the issue there in this new file, so it's bound to the file, not the armature (it syas linked with all its Nla tracks once copy pasted in a new file, and doesn't have the bug). It was created in blender 3.3 by another department in the studio, like the file where the very similar bug appeared at the beginning of this thread.
Author

Ok appending the scene in a new file doesn't bring the bug along, so it's rooted in the blender file, not in a particular scene inside.
I think I should be able to save the situation like that, the whole cinematic is called from that scene so everythign is brought along in this new file. Just have to recreate a bunch of scenes to host the collections.
But I really think it will come back as it's already the second time on totally different usecases.

Ok appending the scene in a new file doesn't bring the bug along, so it's rooted in the blender file, not in a particular scene inside. I think I should be able to save the situation like that, the whole cinematic is called from that scene so everythign is brought along in this new file. Just have to recreate a bunch of scenes to host the collections. But I really think it will come back as it's already the second time on totally different usecases.
Author

Ok the bug came back, now interacting with the armature sends it to whatever pose it has on frame 468. Something is definitely broken with linking characters, or even just actions on armature in blender.
And appending these scenes to a new blender file is not a good solution, as it's a lot of work and the bug eventually triggers again a few more days down the line.

Ok the bug came back, now interacting with the armature sends it to whatever pose it has on frame 468. Something is definitely broken with linking characters, or even just actions on armature in blender. And appending these scenes to a new blender file is not a good solution, as it's a lot of work and the bug eventually triggers again a few more days down the line.
Author

So deleting all scenes does solve the bug. Even if all these scenes have no relation to this armature, as it only exists in this remaining scene.
So basically blender doesn't seem to allow animating armature while having multiple scenes in the file. That's a massive issue and triggered this bug twice on two very different usecase (local armatures in many different scenes/collections, and now one single linked armature in one single scene, with more scenes on the side for environments models.)
It's pretty nasty because it triggers very erratically, at some point, and then the file is done for, only deleting everything solves it, but then that actually solves nothing.

So deleting all scenes does solve the bug. Even if all these scenes have no relation to this armature, as it only exists in this remaining scene. So basically blender doesn't seem to allow animating armature while having multiple scenes in the file. That's a massive issue and triggered this bug twice on two very different usecase (local armatures in many different scenes/collections, and now one single linked armature in one single scene, with more scenes on the side for environments models.) It's pretty nasty because it triggers very erratically, at some point, and then the file is done for, only deleting everything solves it, but then that actually solves nothing.
Author

Like even deleting all animation data from the armature, and recreating some from scratch, keeps the bug. Any click puts bones into the pose/value at frame 468, even with all anim data scrapped beforehand. Only deleting all scenes seems to remove the bug.

So after a lot of tests I think it's just a limitation of blender, having multiple scenes in a blend file, and animating a character, is just not possible because of these pose jumping bugs that will happen.

So the only option to work professionnally in blender might be to have your rig in a file, then linking them into individual files for each anim type/shot, and then link this collections as instances into your Cut/edit file with the rest of your film, environments, cameras ect...
So these anims can have their transforms placed/animated at the correct spot in the world, visibility animated for the shots cuts, the cloth can be simulated in the anim scenes without the cuts, and if retiming is needed it's likely possible to add an overide to the anim collection to display the nla, and slide the animation there for retime.

Will have to reorganize my project with this pipeline hoping I'm not losing too much work & flexibilty, likely it will be a pain not to be able to work on anim & cameras in real time.

Like even deleting all animation data from the armature, and recreating some from scratch, keeps the bug. Any click puts bones into the pose/value at frame 468, even with all anim data scrapped beforehand. Only deleting all scenes seems to remove the bug. So after a lot of tests I think it's just a limitation of blender, having multiple scenes in a blend file, and animating a character, is just not possible because of these pose jumping bugs that will happen. So the only option to work professionnally in blender might be to have your rig in a file, then linking them into individual files for each anim type/shot, and then link this collections as instances into your Cut/edit file with the rest of your film, environments, cameras ect... So these anims can have their transforms placed/animated at the correct spot in the world, visibility animated for the shots cuts, the cloth can be simulated in the anim scenes without the cuts, and if retiming is needed it's likely possible to add an overide to the anim collection to display the nla, and slide the animation there for retime. Will have to reorganize my project with this pipeline hoping I'm not losing too much work & flexibilty, likely it will be a pain not to be able to work on anim & cameras in real time.
Author

So I spent an hour nuking data one by one, and out of thousands of blocks, I found 3 that if deleted, make the bug vanish.
One is a material, one is a object-mesh with this material, and one is a object-empty with a constraint (no relation to the material)
They are all actually linked, via the shader editor, as the texture coordinates for this mesh's material point to the empty object, and the emtpy is constrained on the spine bone of the armature.

So there is a nasty bug when having a material reference something that's contained on an armature, animations/actions will start to jump to a very specific frame, maybe days after you've accumulated work, without triggering the bug.

What's strange is that the initial version of that bug, from this thread, had no similarities I believe, the bug vanished as long as the armature was outside any collection, and there was no constraint like this.

I've attached the Blend file where the bug is still alive inside, with everything except these 3 data blocks (as it's a big projet under NDA.)
Anyone should be able to confirm, like the first one I shared earlier in the thread.

image

So I spent an hour nuking data one by one, and out of thousands of blocks, I found 3 that if deleted, make the bug vanish. One is a material, one is a object-mesh with this material, and one is a object-empty with a constraint (no relation to the material) They are all actually linked, via the shader editor, as the texture coordinates for this mesh's material point to the empty object, and the emtpy is constrained on the spine bone of the armature. So there is a nasty bug when having a material reference something that's contained on an armature, animations/actions will start to jump to a very specific frame, maybe days after you've accumulated work, without triggering the bug. What's strange is that the initial version of that bug, from this thread, had no similarities I believe, the bug vanished as long as the armature was outside any collection, and there was no constraint like this. I've attached the Blend file where the bug is still alive inside, with everything except these 3 data blocks (as it's a big projet under NDA.) Anyone should be able to confirm, like the first one I shared earlier in the thread. ![image](/attachments/fd1a314b-0d94-4c9c-a2eb-4ff66445ef94)

Sorry for late response, I was bit confused by the posts and seeing that issue is confirmed, I thought it's not something I handled. In any case I would recommend to create new issue, unless the cause is same.

Sorry for late response, I was bit confused by the posts and seeing that issue is confirmed, I thought it's not something I handled. In any case I would recommend to create new issue, unless the cause is same.
Author

Hi Richard, thanks for your answer.
As the bug happened on a different project/usecase, and I had a new blend file, I posted a new thread for it last week:

#109804 (comment)

But I do think the root cause must be the same, as it behaves exactly in the same way, pose mode only displaying one specific frame values, making it impossible to edit the anim, only to view it by fixing the armature with a timeline-scrub.
I feel that something breaks the armatures when they're "called" by something else, be it a constraint, a collection instance, or maybe even other factors.
The creator of AutoRig Pro said on his end, closing the image viewer also fixed the bug, on the first file only (105873.blend) but not on my end. It doesn't seem to be the environment as it does it anywhere and on factory settings too.

Thanks again.

Hi Richard, thanks for your answer. As the bug happened on a different project/usecase, and I had a new blend file, I posted a new thread for it last week: https://projects.blender.org/blender/blender/issues/109804#issuecomment-975130 But I do think the root cause must be the same, as it behaves exactly in the same way, pose mode only displaying one specific frame values, making it impossible to edit the anim, only to view it by fixing the armature with a timeline-scrub. I feel that something breaks the armatures when they're "called" by something else, be it a constraint, a collection instance, or maybe even other factors. The creator of AutoRig Pro said on his end, closing the image viewer also fixed the bug, on the first file only (105873.blend) but not on my end. It doesn't seem to be the environment as it does it anywhere and on factory settings too. Thanks again.
Author

Hi @iss I've just had a breakthought with that bug, the root cause is Cycles persistant data !! The bug appeared again today as I'm nearing the end of this project, so I felt discouraged, but I decided to keep diagnosing once again, even if there was no visible cause like last times (empty constrained on a bone of the armature, or armture instanciated in a collection) The bug seemed to come from nowhere this time. But I hunted for the "cursed frame" by having the character move in a straight line, I could identify which frame the armature was "snapping" erratically onto, and I reallzed it was the specific frame I did a render with Cycles last. I had switched to EEVEE since resolving the bug by removing the empty parenting.

So I did various tests and I could confirm that any frame rendered with Cycles persistant data, would "bake-in" the armature values, so anywhere on the timeline the armature would snap to that pose (of the last render) when entering pose mode or selecting a bone.

Doing 1 render with EEVEE purges the bug (and the persistant data I assume) and unticking persistant data & re-rendering also purges the bug ! Otherwise the bug remains even week later, even if working in another scene in eevee and coming back to that Cycles scene ect...

So TL;DR: persistant data "corrupts" armatures and makes them display the last render's frame pose whenever entering pose mode anywhere on the timeline.

Here is an updated bug file that I updated to verify all what I describe above:

Thanks !!

(at least I have a workaround now, just lost a lot of time figuring all this, since january earlier this year !)

Hi @iss I've just had a breakthought with that bug, the root cause is Cycles persistant data !! The bug appeared again today as I'm nearing the end of this project, so I felt discouraged, but I decided to keep diagnosing once again, even if there was no visible cause like last times (empty constrained on a bone of the armature, or armture instanciated in a collection) The bug seemed to come from nowhere this time. But I hunted for the "cursed frame" by having the character move in a straight line, I could identify which frame the armature was "snapping" erratically onto, and I reallzed it was the specific frame I did a render with Cycles last. I had switched to EEVEE since resolving the bug by removing the empty parenting. So I did various tests and I could confirm that any frame rendered with Cycles persistant data, would "bake-in" the armature values, so anywhere on the timeline the armature would snap to that pose (of the last render) when entering pose mode or selecting a bone. Doing 1 render with EEVEE purges the bug (and the persistant data I assume) and unticking persistant data & re-rendering also purges the bug ! Otherwise the bug remains even week later, even if working in another scene in eevee and coming back to that Cycles scene ect... So TL;DR: persistant data "corrupts" armatures and makes them display the last render's frame pose whenever entering pose mode anywhere on the timeline. Here is an updated bug file that I updated to verify all what I describe above: Thanks !! (at least I have a workaround now, just lost a lot of time figuring all this, since january earlier this year !)
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105873
No description provided.