Having a material reference an empty that's constrained on an armature, makes that armature bug. #109804

New Issue

LOIC BRAMOULLE · 2023-07-07T03:38:13+02:00

LOIC BRAMOULLE commented

2023-07-07 03:38:13 +02:00

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 531.79

Blender Version
Broken: version: 3.6.0, branch: blender-v3.6-release, commit date: 2023-06-27 08:08, hash: c7fc78b81ecb
Worked: (newest version of Blender that worked as expected)

Short description of error
If a material is connected to an armature, at some point when you animate on your project, the file will get "corrupted" and whenever you select a bone or enter pose mode, the armature will snap to an arbitrary frame's pose.

Exact steps for others to reproduce the error
Attached is a blender file where you can see the bug, entering pose mode or selecting a bone makes the armature jump to the frame 468 pose. And scrolling in the timeline, even just one frame, will "fix" temporarily the armature and display the real pose.

Deleting any of the objects linking the material to the armature solves the issue, or disconnecting the empty from the shader editor.

Also deleting the other scenes from the file, even if they have zero data inside them, removes the bug.
It's the second time I have this bug this year on totally different usecase, no common asset or process, same exact symptoms (anim erratically jumping when touched) but totally different triggers.

**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 531.79 **Blender Version** Broken: version: 3.6.0, branch: blender-v3.6-release, commit date: 2023-06-27 08:08, hash: `c7fc78b81ecb` Worked: (newest version of Blender that worked as expected) **Short description of error** If a material is connected to an armature, at some point when you animate on your project, the file will get "corrupted" and whenever you select a bone or enter pose mode, the armature will snap to an arbitrary frame's pose. **Exact steps for others to reproduce the error** Attached is a blender file where you can see the bug, entering pose mode or selecting a bone makes the armature jump to the frame 468 pose. And scrolling in the timeline, even just one frame, will "fix" temporarily the armature and display the real pose. Deleting any of the objects linking the material to the armature solves the issue, or disconnecting the empty from the shader editor. Also deleting the other scenes from the file, even if they have zero data inside them, removes the bug. It's the second time I have this bug this year on totally different usecase, no common asset or process, same exact symptoms (anim erratically jumping when touched) but totally different triggers. ![image](/attachments/f8e86fff-0c6b-4845-9f28-3457d4a70225)

LAST_LORDS_INTRO_bug_test_05.blend

2.4 MiB

image.png

665 KiB

LOIC BRAMOULLE added the

labels 2023-07-07 03:38:13 +02:00

LOIC BRAMOULLE commented

2023-07-07 17:14:04 +02:00

The bug came back today just after trying to add the constraint again, and when I reverted the scene to before re-adding the constraint, the bug was still there ! It really feels like a curse as it appears at an arbitrary point, can be triggered by potentially many different things (collections, constraints), and totally corrupts a project.
I'm a bit desperate as it must come from something deep inside blender's code, nothing seems to be able to tackle it on the front end manipulating blend file data, it will just reappear at a different time in a different case, and is a total showstopper, as armatures cannot be interacted with anymore.

The bug came back today just after trying to add the constraint again, and when I reverted the scene to before re-adding the constraint, the bug was still there ! It really feels like a curse as it appears at an arbitrary point, can be triggered by potentially many different things (collections, constraints), and totally corrupts a project. I'm a bit desperate as it must come from something deep inside blender's code, nothing seems to be able to tackle it on the front end manipulating blend file data, it will just reappear at a different time in a different case, and is a total showstopper, as armatures cannot be interacted with anymore.

LOIC BRAMOULLE commented

2023-07-07 17:32:00 +02:00

OK, I know why it came back today, I added a collection instance of this character to another scene, so this bug DOES come from at least constraints, and collections, and potentially other things. It is likely something fundamentally broken with blender armatures.

Steps to reproduce the bug in the above scene:
Well due to the nature of the bug there's no exact step as sometimes it triggers, sometimes not, it's really a massive pain, but if the character is instanciated in a collection in another scene, the bug does come back even WITHOUT the constraint, which is insane.

OK, I know why it came back today, I added a collection instance of this character to another scene, so this bug DOES come from at least constraints, and collections, and potentially other things. It is likely something **fundamentally broken with blender armatures.** Steps to reproduce the bug in the above scene: Well due to the nature of the bug there's no exact step as sometimes it triggers, sometimes not, it's really a massive pain, but if the character is instanciated in a collection in another scene, the bug does come back even WITHOUT the constraint, which is insane.

Iliya Katushenock commented

2023-07-07 18:03:57 +02:00

Hi, have you seen errors in console?

Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03
For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=0)

        BPY_driver_exec: restricted access disallows name 'yurediv', enable auto-execution to support

Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03
For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=1)

        BPY_driver_exec: restricted access disallows name 'yurediv', enable auto-execution to support

Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03
For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=2)

Hi, have you seen errors in console? ``` Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03 For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=0) BPY_driver_exec: restricted access disallows name 'yurediv', enable auto-execution to support Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03 For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=1) BPY_driver_exec: restricted access disallows name 'yurediv', enable auto-execution to support Error in PyDriver: expression failed: ((var1*self.yurediv.var_01)+(var2*self.yurediv.var_02))/self.yurediv.var_03 For target: (type=Object, name="CHARACTER", property=rotation_euler, property_index=2) ```

LOIC BRAMOULLE commented

2023-07-07 18:26:45 +02:00

Hi, yes that has no connexion I believe, it's a addon for adding a delay to a bone, the bug happens totally independantly, with or without the addon active/installed in the blender session, and happened before I installed the addon & applied it to a bone too.

If you delete the bone on the right side of the hips it should delete the error (that's where there is drivers on the rotation) and will have no effect on the bug.

Hi, yes that has no connexion I believe, it's a addon for adding a delay to a bone, the bug happens totally independantly, with or without the addon active/installed in the blender session, and happened before I installed the addon & applied it to a bone too. If you delete the bone on the right side of the hips it should delete the error (that's where there is drivers on the rotation) and will have no effect on the bug.

LOIC BRAMOULLE referenced this issue

2023-07-11 01:00:21 +02:00

Armature animation glitch when using collection instances across scenes #105873

LOIC BRAMOULLE commented

2023-07-31 20:57:35 +02:00

Ok the bug re-appeared, but this time there is no connexion between an empty and a bones, and no collection instances of this character, so as I guessed it can be triggered by a number of things.
I Managed to detect the "CURSED" frame, as it always changes each time the bug appears, this time it's frame 2004, (I have 2755 frames on this cinematic) and what's special about this frame ? Well, the last test render I did earlier this morning was on that frame !
SO currently tehre is something fundamentally broken in blender, that makes it so that your armatures will snap to the pose they have on the last render's frame. Which is crazy. but something must "bake-in" this armature values somewhere when rendering, and just entering pose mode or selecting a bone "Displays" these values again, until the timeline is interacted with.

Ok the bug re-appeared, but this time there is no connexion between an empty and a bones, and no collection instances of this character, so as I guessed it can be triggered by a number of things. I Managed to detect the "CURSED" frame, as it always changes each time the bug appears, this time it's frame 2004, (I have 2755 frames on this cinematic) and what's special about this frame ? Well, the last test render I did earlier this morning was on that frame ! SO currently tehre is something fundamentally broken in blender, that makes it so that your armatures will snap to the pose they have on the last render's frame. Which is crazy. but something must "bake-in" this armature values somewhere when rendering, and just entering pose mode or selecting a bone "Displays" these values again, until the timeline is interacted with.

LOIC BRAMOULLE commented

2023-07-31 21:04:00 +02:00

As a proof, so now my armature snaps to the pose it has on that frame. Maybe there's something wrong happening with the "preserve data", it feels like blender is only able to recall the bones values from this frame 2004 render, and the previous times I had the bug, it also snapped to a frame that was in the range of the recent renders.

As a proof, so now my armature snaps to the pose it has on that frame. Maybe there's something wrong happening with the "preserve data", it feels like blender is only able to recall the bones values from this frame 2004 render, and the previous times I had the bug, it also snapped to a frame that was in the range of the recent renders. ![image](/attachments/d24e6835-f3a4-4725-8038-ef8d03180b97)

image.png

2.3 KiB

LOIC BRAMOULLE commented

2023-07-31 21:15:57 +02:00

YES, confirmed, I did a new render, and the bug moved to that frame !!! so it is indeed something linked with rendering:

It is really a complex nebulous bug, it can be triggered by different things, but at it's core it seems that when redering, an armature pose is "Baked", and when that bug triggers, an armature becomes only able to display that pose, when entering pose mode or selecting a bones, and able to display the actual animation after the timeline has been interacted with (even moving a single frame)

YES, confirmed, I did a new render, and the bug moved to that frame !!! so it is indeed something linked with rendering: ![image](/attachments/1f985871-8e9c-453a-861d-5dac4949c419) It is really a complex nebulous bug, it can be triggered by different things, but at it's core it seems that when redering, an armature pose is "Baked", and when that bug triggers, an armature becomes only able to display that pose, when entering pose mode or selecting a bones, and able to display the actual animation after the timeline has been interacted with (even moving a single frame)

image.png

136 KiB

LOIC BRAMOULLE commented

2023-07-31 21:26:10 +02:00

Yes, if the last render is EEVEE, the bug does not appear anymore. If you render in Cycles, the armature will snap into the last renderd frame pose, no matter the frame you're on currently.

LOIC BRAMOULLE commented

2023-07-31 21:45:10 +02:00

OK FOUND THE SOURCE !!! it's Cycles persistant data !!! I was sure it was something core to blender, not auto-rig or any of my projects.

Persitant data actually bakes-in the armature pose to the rendered frame, and blender flips out and regurgitates these values in the viewport if entering pose mode or selecting a bone. deactivating persistant data (& re-rendering to purge them) OR rendering in EEVEE, makes the bug vanish (until persitant data is ticked again & a render bakes-in erratically the armature pose again.)

OK FOUND THE SOURCE !!! it's Cycles persistant data !!! I was sure it was something core to blender, not auto-rig or any of my projects. Persitant data actually bakes-in the armature pose to the rendered frame, and blender flips out and regurgitates these values in the viewport if entering pose mode or selecting a bone. deactivating persistant data (& re-rendering to purge them) OR rendering in EEVEE, makes the bug vanish (until persitant data is ticked again & a render bakes-in erratically the armature pose again.)

Richard Antalik commented

2023-08-02 00:33:04 +02:00

Thanks for new report and investigation. If I understand correctly, the issue is that when you render some frame, then switch to pose mode, it will cause armature to be in state of last rendered frame?

LOIC BRAMOULLE commented

2023-08-02 00:51:28 +02:00

Thanks Richard, yes that's it.
here is the updated file where I had the bug for the first time, I verified and it does come from persistant data, even if the file is from January 2023, the armature will be debugged only if the persistent datas are "erased" in some way: switch to eevee, untick them, remove a constraint on the armature, remove the armature from a collection, ect.. I think all these "reset" the persistant data, that when you open the file have the armature erratically take the last rendered frame pose.

The file I posted at the top of the thread too must exibit the exact same bug, it's when I encountered the bug on a second project.

Thanks again.

Loïc.

Thanks Richard, yes that's it. here is the updated file where I had the bug for the first time, I verified and it does come from persistant data, even if the file is from January 2023, the armature will be debugged only if the persistent datas are "erased" in some way: switch to eevee, untick them, remove a constraint on the armature, remove the armature from a collection, ect.. I think all these "reset" the persistant data, that when you open the file have the armature erratically take the last rendered frame pose. The file I posted at the top of the thread too must exibit the exact same bug, it's when I encountered the bug on a second project. Thanks again. Loïc.

first encounter case.blend

3.6 MiB

Richard Antalik commented

2023-08-02 01:03:11 +02:00

I am not sure if I can reproduce the issue with persistent data. Can you provide steps to reproduce? I had to add camera ro be able to render anything, but then switching to pose mode works as intended.

LOIC BRAMOULLE commented

2023-08-02 01:46:15 +02:00

Ah no need to render in theory, the bug is already present in the file, if you enter pose mode, select bones, move on the timeline, directly when opening the file. scrolling plays the animation (actual anim is on frames 1650-1850, but I added one keyframe at 2400 in order to spot the "cursed" frame, that is the frame that I rendered last back in january on this file, frame 2082.)

On both file people did confirm it, and AutoRig Pro creator reported that closing the image editor was also a way to remove it (as now we can guess it resets the persistent data ?)

Ah no need to render in theory, the bug is already present in the file, if you enter pose mode, select bones, move on the timeline, directly when opening the file. scrolling plays the animation (actual anim is on frames 1650-1850, but I added one keyframe at 2400 in order to spot the "cursed" frame, that is the frame that I rendered last back in january on this file, frame 2082.) On both file people did confirm it, and AutoRig Pro creator reported that closing the image editor was also a way to remove it (as now we can guess it resets the persistent data ?)

Richard Antalik commented

2023-08-02 02:21:15 +02:00

I understand, that the issue is present in the file, but I would still like to have steps to reproduce it from scratch. Especially since I am not able to.

AutoRig Pro creator
I was thinking about this being caused by addon somehow, but not sure how addon could do this. Do you have some link where this behavior is described?

I understand, that the issue is present in the file, but I would still like to have steps to reproduce it from scratch. Especially since I am not able to. > AutoRig Pro creator I was thinking about this being caused by addon somehow, but not sure how addon could do this. Do you have some link where this behavior is described?

LOIC BRAMOULLE commented

2023-08-02 02:52:26 +02:00

Ah ok, well on my workfiles where the bug is live (not these cleaned-up files) I just have to press f12 while being on any frame, and that's it the current frame is now "cursed" and that's now where the armature snaps. But I'm not sure what exactly provokes that, triggers the bug, as it probably does not trigger by default in vanilla blender, there must be something that makes the persistant data corrupt the armature. All the times I managed to 'cure' the bug, it did not reapear, until it did days later.
And I jus tried reopened the files where I encountered it for the third time yesterday, it's not there on one, and the other this time it does not change the "cursed" frame when re-rendeing, but it removes the bug. so still really confusing, but I tested really thoroughly yesterday and it "followed" the last rendered frame as long as persistent datda was on, on these files.

Ah ok, well on my workfiles where the bug is live (not these cleaned-up files) I just have to press f12 while being on any frame, and that's it the current frame is now "cursed" and that's now where the armature snaps. But I'm not sure what exactly provokes that, triggers the bug, as it probably does not trigger by default in vanilla blender, there must be something that makes the persistant data corrupt the armature. All the times I managed to 'cure' the bug, it did not reapear, until it did days later. And I jus tried reopened the files where I encountered it for the third time yesterday, it's not there on one, and the other this time it does not change the "cursed" frame when re-rendeing, but it removes the bug. so still really confusing, but I tested really thoroughly yesterday and it "followed" the last rendered frame as long as persistent datda was on, on these files.

LOIC BRAMOULLE commented

2023-08-02 02:54:59 +02:00

Autorig pro creator did not recall any of his like 40K+ users reporting this bug, I guess maybe because animators don't render so much, dunno, but I don't think I have much addon that could be tied to rendering, armatures.. it's possible though.

Richard Antalik commented

2023-08-15 05:57:53 +02:00

I would like to somehow close the investigation into this, and I am not sure, that repro steps from scratch will be possible, so I will close this issue and mention findings from this conversation in #105873

Richard Antalik closed this issue

2023-08-15 05:57:55 +02:00

Blender Bot added

and removed

labels 2023-08-15 05:57:57 +02:00

LOIC BRAMOULLE commented

2023-08-15 17:04:27 +02:00

ok thanks, yes it won't happen on a blank file in factory settings, but I'm sure it'll keep happening on my end as it plagued my projects this year. But knowing it comes from the persitant data makes it very easy to solve by re-rendering a frame without, to purge persitant data.

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

Having a material reference an empty that's constrained on an armature, makes that armature bug. #109804