Keying sets for armatures in library overrides break if unrelated objects are changed in source file #95601

New Issue

Stellarator Tokamak · 2022-02-08T09:14:01+01:00

2022-02-08 09:14:01 +01:00

System Information
Blender 3.0.1 with an Nvidia GTX2080, Windows 10
system-info.txt

Problem

In particular, the "Target ID-Block" field of keyring entries for bones on an armature is corrupted when objects in source file (not related to armature in any way) are renamed.

Real world example of why this is a problem: If you are using a rigged character in a scene, and need to make even a small tweak in your character file, the keying sets in your scene will all break.

I've made a pair of minimal files to reproduce the error.

This is a little inconsistent, behaving a little differently each time I do it, even when I do the exact same series of steps. It seems to only work if there are a few objects in the collection, as shown in the test files.

Reproduction
bug character.blend

bug scene.blend

Repro steps with test files "bug character.blend" and "bug scene.blend", which are a notional character, and scene with linked character, respectively:

Have both files in same directory, obviously.
Open "bug scene.blend" and create a keying set. Select "Armature", go into pose mode, select the bone, and add its "location" to keying set.
Hit "i" to insert a keyframe, and observe that it works as expected.
You can save and reload "bug scene.blend" and observe that the keying set still works as expected.
Open "bug character.blend" and rename the object "QQQ" to "PPP", and save.
Re-open "bug scene.blend". There will be a notice that the source file has changed.
Hit "i" to insert a keyframe. You should get the error "keying set failed to insert any keyframes" and if you look at the keying set, you will see that "Target ID-Block" field is empty, or has garbage text in it, or has another object's name in it, or possibly still contains the name "Armature", but attempting to insert keyframes still gives that error.

If you do this with two concurrent instances of blender, (one with character file and one with scene file open) so that you can just use the "revert" function on the scene file, blender will sometimes crash, or will seem fine but crash with an "EXCEPTION_ACCESS_VIOLATION" when you try to insert a keyframe, or when you try to select a path in the keying set, etc.

This is how the bogus name in the Target ID-Block looks like:
{F12855111 size=full}

**System Information** Blender 3.0.1 with an Nvidia GTX2080, Windows 10 [system-info.txt](https://archive.blender.org/developer/F12854711/system-info.txt) **Problem** In particular, the "Target ID-Block" field of keyring entries for bones on an armature is corrupted when objects in source file (not related to armature in any way) are renamed. Real world example of why this is a problem: If you are using a rigged character in a scene, and need to make even a small tweak in your character file, the keying sets in your scene will all break. I've made a pair of minimal files to reproduce the error. This is a little inconsistent, behaving a little differently each time I do it, even when I do the exact same series of steps. It seems to only work if there are a few objects in the collection, as shown in the test files. **Reproduction** [bug character.blend](https://archive.blender.org/developer/F12854709/bug_character.blend) [bug scene.blend](https://archive.blender.org/developer/F12854710/bug_scene.blend) Repro steps with test files "bug character.blend" and "bug scene.blend", which are a notional character, and scene with linked character, respectively: * Have both files in same directory, obviously. * Open "bug scene.blend" and create a keying set. Select "Armature", go into pose mode, select the bone, and add its "location" to keying set. * Hit "i" to insert a keyframe, and observe that it works as expected. * You can save and reload "bug scene.blend" and observe that the keying set still works as expected. * Open "bug character.blend" and rename the object "QQQ" to "PPP", and save. * Re-open "bug scene.blend". There will be a notice that the source file has changed. * Hit "i" to insert a keyframe. You should get the error "keying set failed to insert any keyframes" and if you look at the keying set, you will see that "Target ID-Block" field is empty, or has garbage text in it, or has another object's name in it, or possibly still contains the name "Armature", but attempting to insert keyframes still gives that error. If you do this with two concurrent instances of blender, (one with character file and one with scene file open) so that you can just use the "revert" function on the scene file, blender will sometimes crash, or will seem fine but crash with an "EXCEPTION_ACCESS_VIOLATION" when you try to insert a keyframe, or when you try to select a path in the keying set, etc. This is how the bogus name in the Target ID-Block looks like: {[F12855111](https://archive.blender.org/developer/F12855111/image.png) size=full}

Stellarator Tokamak commented

2022-02-08 09:14:01 +01:00

Added subscriber: @AdrianPreston

Philipp Oeser commented

2022-02-08 12:50:39 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-02-08 12:50:39 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-02-08 12:50:39 +01:00

Can confirm.

This is how the bogus name in the Target ID-Block looks like:

Was not able to reproduce a crash though.
Not sure if loosing the Target ID-Block is somewhat a known limitation (even though the block that has gone missing is not the one having been renamed)

Can confirm. This is how the bogus name in the Target ID-Block looks like: ![image.png](https://archive.blender.org/developer/F12855111/image.png) Was not able to reproduce a crash though. Not sure if loosing the Target ID-Block is somewhat a known limitation (even though the block that has gone missing is not the one having been renamed)

Stellarator Tokamak commented

2022-02-08 18:30:07 +01:00

It is possible that it's a deeper issue, and the renaming thing is just triggering it. I say this because my rigged character files trigger this same behavior 100% of the time even when the source file is not changed. I've just been unable to get a minimal test case to upload, because I can't make it happen with simple test "characters" like this cube-and-bone setup, so I can't get you repro steps. But t DOES happen outside of just this renaming case.

Not being a developer, I'll butt out now.

It is possible that it's a deeper issue, and the renaming thing is just triggering it. I say this because my rigged character files trigger this same behavior 100% of the time even when the source file is not changed. I've just been unable to get a minimal test case to upload, because I can't make it happen with simple test "characters" like this cube-and-bone setup, so I can't get you repro steps. But t DOES happen outside of just this renaming case. Not being a developer, I'll butt out now.

Bastien Montagne commented

2022-02-14 11:49:01 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2022-02-14 11:49:01 +01:00

This is a critical missing piece of code in our 'foreach_id' code, that exists basically since forever... not related directly to overrides, as usual those simply expose an underlying defect. ;)

The fix is simple, but backporting it to the older LTS releases is going to be... interesting.

This is a critical missing piece of code in our 'foreach_id' code, that exists basically since forever... not related directly to overrides, as usual those simply expose an underlying defect. ;) The fix is simple, but backporting it to the older LTS releases is going to be... interesting.

blender-admin commented

2022-02-14 12:05:11 +01:00

This issue was referenced by 3a9a37d6dc

This issue was referenced by 3a9a37d6dccb0a981b1fad0cda977b4a445341a1

Bastien Montagne commented

2022-02-14 12:07:46 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue

2022-02-14 12:07:46 +01:00

Bastien Montagne self-assigned this 2022-02-14 12:07:46 +01:00

blender-admin commented

2022-02-21 11:40:35 +01:00