Page MenuHome

Convert Proxy to Override: Local constraints aren't saved
Closed, ResolvedPublicDESIGN


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: rB9a7da1242d9f

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.

Event Timeline

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?

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:

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Nov 18 2020, 7:52 PM
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "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.

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.

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[0] ==['CH-pastor.5_proxy'].pose.bones["root"]
C.object.proxy.pose.bones[0] ==['RIG-pastor.5'].pose.bones["ORG-Thigh.L"][0] ==['Data_RIG-pastor'].bones["P-root"]

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

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).

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:

  • 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 (mont29) changed the subtype of this task from "Bug" to "Design".Nov 24 2020, 3:03 PM

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 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 :)

@Luciano Muñoz Sessarego (looch) 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...