Keying sets for armatures in library overrides break if unrelated objects are changed in source file #95601
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
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 & 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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
Asset System
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#95601
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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}
Added subscriber: @AdrianPreston
Added subscriber: @lichtwerk
Changed status from 'Needs Triage' to: 'Confirmed'
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)
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.
Added subscriber: @mont29
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 issue was referenced by
3a9a37d6dc
Changed status from 'Confirmed' to: 'Resolved'
This issue was referenced by
3a9619af80
This issue was referenced by
ff05921099