Stretch To constraints are broken on file reopening #127017

New Issue

Mark Raynsford · 2024-08-31T15:05:02+02:00

Mark Raynsford commented

2024-08-31 15:05:02 +02:00

TL;DR:

Since validity of the constraints can change depending on the values of their ID pointers (e.g. targets), the remapping code needs to "somehow' update/re-check the constraints as part of its post-process updates.

Currently this happens in editor code area, when e.g. targets or other properties are edited (mainly through RNA and the property update callback system).

Proposed Solution

Immediate 'simple' solution:

Move constraint_tag_update and whole related code into BKE.
Add another 'post-process' callback in remapping code, similar the the existing libblock_remap_data_postprocess_obdata_relink one, to call constraint_tag_update.
This will result in potentially (too) many calls to this constraint_tag_update function - to be confirmed.

Proper, longer-term solution:
a. Split constraint check/updates into two steps, an efficient and simple call to mark current status as dirty, and an actual 'ensure valid' code path only called 'when needed'.
b. 'foreach id' handler for constraints checks if old and new ID are different, and accordingly tag the constraint as dirty, and the object as needing constraints status updates.

Technical Details of the Issue

The constraints in liboverride data are marked as valid, and therefore evaluated, while they should be invalid (and not evaluated). Here is what happens when applying liboverrides:

liboverrides are applied by selectively assigning values from old, local liboverride data to a new, temporary copy of the reference linked data.
When assigning the target to these StretchTo constraints, RNA update calls constraint_tag_update, which finds that the owner ID and the target ID are currently different, so it considers the constraint as valid.
Then LibOverride apply code swap the two IDs, such that the new, updated liboverride now uses the same address as the old liboverride, and frees that old deprecated data. So now, the owner ID and the target ID are the same. But the constraint has already been checked as valid, and no re-check is performed.

Original Report:

System Information
Operating system: Linux
Graphics card: AMD Radeon RX 5600

Blender Version
Broken: Blender 4.2.1 LTS, 396f546c9d, 2024-08-20
Worked: None

Short description of error

Stretch To constraints on linked armatures are broken on file reopening.

Exact steps for others to reproduce the error

This issue was originally discussed as an issue with the Human Generator addon (https://github.com/OliverJPost/HumGen3D/issues/110), however it doesn't seem to be the fault of the addon. The model and rig included in the file is the output of the Human Generator 3D addon, but I've verified that the problem happens without the addon being present in the system (and the included blend should contain no references to the addon).

The steps required are as follows:

Create a new blend and delete all objects, leaving only the Scene Collection.
Link following objects in the attached BlenderLibraryOverrideBug.blend file into the new blend: Jeffery_RIGIFY, HG_Body, HG_Eyes, HG_TeethLower, HG_TeethUpper
Select the Jeffery_RIGIFY armature, and Make library override.
Save the file and reopen it.

You'll be greeted with the horrors in the image:

https://ataxia.io7m.com/2024/08/31/stretch.png

It makes an artistic statement, but it's not really what I wanted.

# TL;DR: Since validity of the constraints can change depending on the values of their ID pointers (e.g. targets), the remapping code needs to "somehow' update/re-check the constraints as part of its post-process updates. Currently this happens in `editor` code area, when e.g. targets or other properties are edited (mainly through RNA and the property update callback system). # Proposed Solution 1. Immediate 'simple' solution: * [ ] Move `constraint_tag_update` and whole related code into BKE. * [ ] Add another 'post-process' callback in remapping code, similar the the existing `libblock_remap_data_postprocess_obdata_relink` one, to call `constraint_tag_update`. * This will result in potentially (too) many calls to this `constraint_tag_update` function - to be confirmed. 2. Proper, longer-term solution: a. Split constraint check/updates into two steps, an efficient and simple call to mark current status as dirty, and an actual 'ensure valid' code path only called 'when needed'. b. 'foreach id' handler for constraints checks if old and new ID are different, and accordingly tag the constraint as dirty, and the object as needing constraints status updates. # Technical Details of the Issue The constraints in liboverride data are marked as valid, and therefore evaluated, while they should be invalid (and not evaluated). Here is what happens when applying liboverrides: 1. liboverrides are applied by selectively assigning values from old, local liboverride data to a new, temporary copy of the reference linked data. 2. When assigning the target to these StretchTo constraints, RNA update calls `constraint_tag_update`, which finds that the owner ID and the target ID are currently different, so it considers the constraint as valid. 3. Then LibOverride apply code swap the two IDs, such that the new, updated liboverride now uses the same address as the old liboverride, and frees that old deprecated data. So now, the owner ID and the target ID are the same. But the constraint has already been checked as valid, and no re-check is performed. --------------------------- # Original Report: **System Information** Operating system: Linux Graphics card: AMD Radeon RX 5600 **Blender Version** Broken: Blender 4.2.1 LTS, 396f546c9d, 2024-08-20 Worked: None **Short description of error** Stretch To constraints on linked armatures are broken on file reopening. **Exact steps for others to reproduce the error** This issue was originally discussed as an issue with the Human Generator addon (https://github.com/OliverJPost/HumGen3D/issues/110), however it doesn't seem to be the fault of the addon. The model and rig included in the file is the output of the Human Generator 3D addon, but I've verified that the problem happens without the addon being present in the system (and the included blend should contain no references to the addon). The steps required are as follows: - Create a new blend and delete all objects, leaving only the Scene Collection. - Link following objects in the attached `BlenderLibraryOverrideBug.blend` file into the new blend: `Jeffery_RIGIFY`, `HG_Body`, `HG_Eyes`, `HG_TeethLower`, `HG_TeethUpper` - Select the `Jeffery_RIGIFY` armature, and `Make library override`. - Save the file and reopen it. You'll be greeted with the horrors in the image: https://ataxia.io7m.com/2024/08/31/stretch.png It makes an artistic statement, but it's not really what I wanted.

BlenderLibraryOverrideBug.blend

33 MiB

Mark Raynsford added the

labels 2024-08-31 15:05:03 +02:00

Mark Raynsford referenced this issue

2024-08-31 15:07:12 +02:00

Overridden objects removed when reopening a file. #127015

Pratik Borhade commented

2024-09-04 11:03:04 +02:00

Hi, thanks for the report. Can confirm after library override. AFAICS, HG_Eyes object's mesh data is corrupted (I ran mesh.validate()).
Apart from that, resyncing library override resolves the issue for an instance.
Not sure if this is a blender bug or somewhere in mesh/rig or corrupted data. @mont29 any idea?

Hi, thanks for the report. Can confirm after library override. AFAICS, `HG_Eyes` object's mesh data is corrupted (I ran `mesh.validate()`). Apart from that, resyncing library override resolves the issue for an instance. Not sure if this is a blender bug or somewhere in mesh/rig or corrupted data. @mont29 any idea?

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Stretch To constraints are broken on file reopening #127017

TL;DR:

Proposed Solution

Technical Details of the Issue

Original Report: