Convert Proxy to Override: Local constraints aren't saved #82758

New Issue

Demeter Dzadik · 2020-11-16T11:37:05+01:00

Demeter Dzadik commented

2020-11-16 11:37:05 +01:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2020-11-06 06:10, hash: 9a7da1242d

Short description of error
When adding additional constraints on a proxy armature, then converting that proxy to an override, and then saving and reloading the blend file, the additional constraints get lost.

Exact steps for others to reproduce the error

Download both files and put them in the same folder:
Open coffee_run.blend
Note the local Copy Transforms constraint on the rig's P-root bone.
Go to object mode.
Object -> Relations -> Convert Proxy to Override (in object mode, with the armature object as active)
Save and reload
Constraint is gone.

I can't seem to reproduce this on a fresh file, and what's even more confusing is if you delete all bones in the crowd.5.blend file except for P-root, the bug no longer happens.
coffee_run.blend
crowd.5.blend

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71 **Blender Version** Broken: version: 2.92.0 Alpha, branch: master, commit date: 2020-11-06 06:10, hash: `9a7da1242d` **Short description of error** When adding additional constraints on a proxy armature, then converting that proxy to an override, and then saving and reloading the blend file, the additional constraints get lost. **Exact steps for others to reproduce the error** - Download both files and put them in the same folder: - Open coffee_run.blend - Note the local Copy Transforms constraint on the rig's `P-root` bone. - Go to object mode. - `Object -> Relations -> Convert Proxy to Override` (in object mode, with the armature object as active) - Save and reload - Constraint is gone. I can't seem to reproduce this on a fresh file, and what's even more confusing is if you delete all bones in the crowd.5.blend file except for `P-root`, the bug no longer happens. [coffee_run.blend](https://archive.blender.org/developer/F9317006/coffee_run.blend) [crowd.5.blend](https://archive.blender.org/developer/F9300961/crowd.5.blend)

Demeter Dzadik commented

2020-11-16 11:37:05 +01:00

Added subscriber: @Mets

Germano Cavalcante commented

2020-11-17 16:17:45 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-11-17 16:17:45 +01:00

I'm having trouble reproducing this problem.
Even though I put the files in the same directory, when I open the file I am faced with hundreds of warnings starting with:

Info: Read library:  'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', '//..\..\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', parent '<direct>'
Warning: Cannot find lib 'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend'

To resolve this I go to Outliner -> Blend File, I run the operator to relocate the missing library.
All warnings appear to have been resolved after that.
But I can't follow the steps listed because P-root has no "local Copy Transforms constraint" :\

I don't know this area very well.
I could recreate the directory, but is there another way to reproduce the problem?

I'm having trouble reproducing this problem. Even though I put the files in the same directory, when I open the file I am faced with hundreds of warnings starting with: ``` Info: Read library: 'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', '//..\..\Work\CoffeeRun\lib\char\crowd\crowd.5.blend', parent '<direct>' Warning: Cannot find lib 'C:\Users\Work\CoffeeRun\lib\char\crowd\crowd.5.blend' ``` To resolve this I go to `Outliner -> Blend File`, I run the operator to relocate the missing library. All warnings appear to have been resolved after that. But I can't follow the steps listed because `P-root` has no "local Copy Transforms constraint" :\ I don't know this area very well. I could recreate the directory, but is there another way to reproduce the problem?

Demeter Dzadik commented

2020-11-18 14:35:39 +01:00

My bad, it seems one of the files I uploaded was the wrong one, sorry! I updated the file, the reproduction steps should be valid now - P-root should have a "Copy Transforms" bone constraint:

My bad, it seems one of the files I uploaded was the wrong one, sorry! I updated the file, the reproduction steps should be valid now - `P-root` should have a "Copy Transforms" bone constraint: ![image.png](https://archive.blender.org/developer/F9317011/image.png)

Germano Cavalcante commented

2020-11-18 19:52:16 +01:00

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

Germano Cavalcante commented

2020-11-18 19:52:16 +01:00

Thanks for updating the file, I can reproduce it now.
I'm not sure if this is really a bug in Blender or a problem in the file since, as has been said, it cannot be reproduced on a fresh file.
But I will take the risk and confirm it as a bug.

Thanks for updating the file, I can reproduce it now. I'm not sure if this is really a bug in Blender or a problem in the file since, as has been said, it cannot be reproduced on a fresh file. But I will take the risk and confirm it as a bug.

Demeter Dzadik commented

2020-11-19 11:36:46 +01:00

Indeed, at first I was trying to hunt down some setting that might trigger this to happen, but even just deleting most of the bones from the armature makes the issue go away which left me pretty confused.

Also just to note, this issue is not important for the studio, there are no (current) plans to convert old files from proxies to overrides - I was just making a demo video of the feature for the 2.91 release and ran into this, that's all.

Indeed, at first I was trying to hunt down some setting that might trigger this to happen, but even just deleting most of the bones from the armature makes the issue go away which left me pretty confused. Also just to note, this issue is not important for the studio, there are no (current) plans to convert old files from proxies to overrides - I was just making a demo video of the feature for the 2.91 release and ran into this, that's all.

Bastien Montagne commented

2020-11-24 11:16:14 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2020-11-24 11:16:14 +01:00

the order of bones in proxy and linked objects and armature is not the same ... Not sure how this happens and this will definitively break overrides.

C.object.pose.bones- [x] == bpy.data.objects['CH-pastor.5_proxy'].pose.bones["root"]
C.object.proxy.pose.bones- [x] == bpy.data.objects['RIG-pastor.5'].pose.bones["ORG-Thigh.L"]
C.object.data.bones- [x] == bpy.data.armatures['Data_RIG-pastor'].bones["P-root"]

So would consider this as 'not a bug/known issue'

the order of bones in proxy and linked objects and armature is not the same ... Not sure how this happens and this will definitively break overrides. `C.object.pose.bones- [x] == bpy.data.objects['CH-pastor.5_proxy'].pose.bones["root"]` `C.object.proxy.pose.bones- [x] == bpy.data.objects['RIG-pastor.5'].pose.bones["ORG-Thigh.L"]` `C.object.data.bones- [x] == bpy.data.armatures['Data_RIG-pastor'].bones["P-root"]` So would consider this as 'not a bug/known issue'

Germano Cavalcante commented

2020-11-24 13:56:38 +01:00

known issue is useful for keeping track of tasks and merge reports with similar problems.
Since we don't know what caused this unusual bone order, I think it is better to close the task (maybe related problems can be reported in the future and this will also be fixed).

`known issue` is useful for keeping track of tasks and merge reports with similar problems. Since we don't know what caused this unusual bone order, I think it is better to close the task (maybe related problems can be reported in the future and this will also be fixed).

Demeter Dzadik commented

2020-11-24 15:00:42 +01:00

Interesting! If parts of Blender will continue to rely on those indices being in sync though then this might still be worth hunting down, even if it's too late for existing armatures.

After some fiddling around with turning X-Mirror off and on while deleting and duplicating bones and switching between edit and object mode, I can sometimes get the indices to fall out of sync, although not sure of exact reproduction steps, but I think having more bones helps.
In this blend file: indicies_out_of_sync.blend

Run the script in the text editor to see the indices are in sync.
Enter edit mode
Delete the selected bones
Disable X-Mirror
Duplicate a bunch of bones
Enter object mode
Run the script again -> indices are now out of sync.

If this seems worthwhile let me know and I can either update this task or open a new one.

But on another note, I find it unfortunate that anything should rely on these indices rather than the bone's names, since the user can't control the bone order anyways. I think whatever relies on this will just end up behaving arbitrarily as far as the user in concerned.

Interesting! If parts of Blender will continue to rely on those indices being in sync though then this might still be worth hunting down, even if it's too late for existing armatures. After some fiddling around with turning X-Mirror off and on while deleting and duplicating bones and switching between edit and object mode, I can sometimes get the indices to fall out of sync, although not sure of exact reproduction steps, but I think having more bones helps. In this blend file: [indicies_out_of_sync.blend](https://archive.blender.org/developer/F9365638/indicies_out_of_sync.blend) - Run the script in the text editor to see the indices are in sync. - Enter edit mode - Delete the selected bones - Disable X-Mirror - Duplicate a bunch of bones - Enter object mode - Run the script again -> indices are now out of sync. If this seems worthwhile let me know and I can either update this task or open a new one. But on another note, I find it unfortunate that anything should rely on these indices rather than the bone's names, since the user can't control the bone order anyways. I think whatever relies on this will just end up behaving arbitrarily as far as the user in concerned.

Bastien Montagne commented

2020-11-24 15:03:52 +01:00

I'm more interested in hearing from other devs in #animation_rigging whether this is expected.

Difference in order between posebones and bones in Armature obdata may be expected (the former are in a flat list, the later in a recursive/tree-like set of lists), and is probably not an issue.

But reading again BKE_pose_rebuild, this function does not ensure any kind of deterministic order for the posebones. This is going to be a critical issue with overrides (unless we do a full name-based search in diffing code, but this will be expensive, even with the GHash integrated in poses). So I would suggest changing BKE_pose_channel_verify to ensure a consistent and predictive order of posebones in their list (should not be too hard of a change I think).

I'm more interested in hearing from other devs in #animation_rigging whether this is expected. Difference in order between posebones and bones in Armature obdata may be expected (the former are in a flat list, the later in a recursive/tree-like set of lists), and is probably not an issue. But reading again `BKE_pose_rebuild`, this function does not ensure any kind of deterministic order for the posebones. This is going to be a critical issue with overrides (unless we do a full name-based search in diffing code, but this will be expensive, even with the GHash integrated in poses). So I would suggest changing `BKE_pose_channel_verify` to ensure a consistent and predictive order of posebones in their list (should not be too hard of a change I think).

Luciano Muñoz Sessarego commented

2020-11-24 15:08:45 +01:00

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented

2020-11-24 15:08:45 +01:00

I mean if the result is losing the constrains created locally in the animation file then it is a bug.

If I understand it well, this could mean even not touching a bone involved in said constrain could cause that connection to be lost due to the reordering of the indices.

If that's the case then it should be fixed.

Sorry if I misunderstood the issue, just point it out if i did :)

I mean if the result is losing the constrains created locally in the animation file then it is a bug. If I understand it well, this could mean even not touching a bone involved in said constrain could cause that connection to be lost due to the reordering of the indices. If that's the case then it should be fixed. Sorry if I misunderstood the issue, just point it out if i did :)

blender-admin commented

2020-11-25 11:20:12 +01:00

This issue was referenced by fbdf1af355

This issue was referenced by fbdf1af3555027696df5b687c7fe8d345e4c39e9

Bastien Montagne commented

2020-11-25 11:34:32 +01:00

@LucianoMunoz override code expects matching order of bones in reference (linked) object pose and local (override) object pose. Just like for any collection (besides the very few that currently support insertion of local items, like constraints or modifiers). I'd say that this is a reasonable expectation...

Bastien Montagne commented

2020-11-27 16:20:16 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue

2020-11-27 16:20:16 +01:00

Bastien Montagne self-assigned this 2020-11-27 16:20:16 +01:00

Thomas Dinges added this to the 2.92 milestone 2023-02-08 16:15:43 +01:00

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

Convert Proxy to Override: Local constraints aren't saved #82758