Effect of Collection order on Linking with scaled proxy armature #72197

New Issue

Konstantins Visnevskis · 2019-12-05T13:26:50+01:00

2019-12-05 13:26:50 +01:00

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

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449

Short description of error
Internal collection order affects result of linking. Probably losing parenting.

Exact steps for others to reproduce the error

Create a new empty scene, link the "link_Collection" Collection from each provided file.
Make proxy for each object's Armature.
Scale each Armature in Object mode.
Move the bone of each Armature in pose mode.
One of skinned objects doesn't inherit coordinate scale.
The only difference between files is the non-hierarchical (within the same parent level) order of collections.

test-geo-first.blend

test-arm-first.blend

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.30 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449` **Short description of error** Internal collection order affects result of linking. Probably losing parenting. **Exact steps for others to reproduce the error** - Create a new empty scene, link the "link_Collection" Collection from each provided file. - Make proxy for each object's Armature. - Scale each Armature in Object mode. - Move the bone of each Armature in pose mode. - > One of skinned objects doesn't inherit coordinate scale. The only difference between files is the non-hierarchical (within the same parent level) order of collections. [test-geo-first.blend](https://archive.blender.org/developer/F8191322/test-geo-first.blend) [test-arm-first.blend](https://archive.blender.org/developer/F8191323/test-arm-first.blend)

Konstantins Visnevskis commented

2019-12-05 13:26:50 +01:00

Added subscriber: @KonstantinsVisnevskis

Konstantins Visnevskis commented

2019-12-05 13:29:09 +01:00

Tested in 2.81 with the same result.

Konstantins Visnevskis changed title from ~~Linking collection order~~ to Effect of Collection order on Linking

2019-12-05 14:07:01 +01:00

Jacques Lucke commented

2020-01-08 11:48:37 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-01-08 11:48:37 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Jacques Lucke commented

2020-01-08 11:48:37 +01:00

It seems to work for me in the current build. Maybe I'm doing something wrong because I don't know too much about the whole proxy linking etc.
Can you check if the same issue still exists in the latest builds from https://builder.blender.org/download/ ?

It seems to work for me in the current build. Maybe I'm doing something wrong because I don't know too much about the whole proxy linking etc. Can you check if the same issue still exists in the latest builds from https://builder.blender.org/download/ ?

Konstantins Visnevskis commented

2020-01-08 14:26:31 +01:00

Hi, the mismatch is still there.
Here's the file linking the files above as per description:
linked.blend
Edit3: Enter pose mode and move bone on the left object. The geometry doesn't match motion scale, which doesn't happen on the right object.

The problem seems to be worse as in some cases changing collection order does not restore proper object relationship in linked data and the geometry flies all over the place. Strangely - that happens only on viewport redraws inside pose mode. Once in object mode viewport redraws seem to be fine. And once making everything local or appending instead of linking everything goes back to normal.
Unfortunately the files are under NDA. I'll try to extract the problem in some time.
Edit: this seems to be related but another bug, as the problem initially reported remains after exiting pose mode.
Edit2: My bad - it's on the geometry recalc, not a viewport redraw. So this is the same problem.

Hi, the mismatch is still there. Here's the file linking the files above as per description: [linked.blend](https://archive.blender.org/developer/F8266022/linked.blend) Edit3: Enter pose mode and move bone on the left object. The geometry doesn't match motion scale, which doesn't happen on the right object. The problem seems to be worse as in some cases changing collection order does not restore proper object relationship in linked data and the geometry flies all over the place. Strangely - that happens only on viewport redraws inside pose mode. Once in object mode viewport redraws seem to be fine. And once making everything local or appending instead of linking everything goes back to normal. Unfortunately the files are under NDA. I'll try to extract the problem in some time. Edit: this seems to be related but another bug, as the problem initially reported remains after exiting pose mode. Edit2: My bad - it's on the geometry recalc, not a viewport redraw. So this is the same problem.

Jacques Lucke commented

2020-01-08 14:38:21 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Konstantins Visnevskis commented

2020-01-08 15:51:44 +01:00

After a bit of shifting around - a probable workaround seems to be to link with unchecked "Instance Collections"
(then select rig in Outliner to make proxy, as it's usually hidden to avoid doubling).
That way, although a bit messy, everything seems to work, so there's probably some conflict with parenting when instancing.

After a bit of shifting around - a probable workaround seems to be to link with unchecked "Instance Collections" (then select rig in Outliner to make proxy, as it's usually hidden to avoid doubling). That way, although a bit messy, everything seems to work, so there's probably some conflict with parenting when instancing.

Philipp Oeser commented

2020-01-15 19:46:27 +01:00

Added subscribers: @mont29, @lichtwerk

Philipp Oeser commented

2020-01-15 19:46:27 +01:00

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

Philipp Oeser commented

2020-01-15 19:46:27 +01:00

Can confirm.
Also no expert in the proxy stuff, maybe @mont29 would know more?
Looks like a bug to me...

(Overrides seem to behave better than proxies here btw)
T72197_overrides.zip

Can confirm. Also no expert in the proxy stuff, maybe @mont29 would know more? Looks like a bug to me... (Overrides seem to behave better than proxies here btw) [T72197_overrides.zip](https://archive.blender.org/developer/F8280433/T72197_overrides.zip)

Philipp Oeser changed title from ~~Effect of Collection order on Linking~~ to Effect of Collection order on Linking with scaled proxy armature

2020-01-15 19:47:47 +01:00

Philipp Oeser commented

2020-01-23 11:06:27 +01:00

@KonstantinsVisnevskis: to me it looks like D6651: Fix #72083: Object.proxy_collection is been set to linked target object even when target is not a collection fixes this, can you confirm?

@KonstantinsVisnevskis: to me it looks like [D6651: Fix #72083: Object.proxy_collection is been set to linked target object even when target is not a collection](https://archive.blender.org/developer/D6651) fixes this, can you confirm?

Philipp Oeser commented

2020-01-23 11:26:04 +01:00

In #72197#856542, @lichtwerk wrote:
@KonstantinsVisnevskis: to me it looks like D6651: Fix #72083: Object.proxy_collection is been set to linked target object even when target is not a collection fixes this, can you confirm?

note you have to do "Make Proxy" again (with the patch)... in linked.blend this was already done (without the patch)

> In #72197#856542, @lichtwerk wrote: > @KonstantinsVisnevskis: to me it looks like [D6651: Fix #72083: Object.proxy_collection is been set to linked target object even when target is not a collection](https://archive.blender.org/developer/D6651) fixes this, can you confirm? note you have to do "Make Proxy" again (with the patch)... in `linked.blend` this was already done (without the patch)

Philipp Oeser commented

2020-01-23 11:45:11 +01:00

Sorry for the noise, spoke too soon, not resolved by D6651...

Sorry for the noise, spoke too soon, **not** resolved by [D6651](https://archive.blender.org/developer/D6651)...

Sybren A. Stüvel commented

2020-03-02 18:07:05 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-03-02 18:07:05 +01:00

Changed status from 'Confirmed' to: 'Needs User Info'

Sybren A. Stüvel commented

2020-03-02 18:07:05 +01:00

@KonstantinsVisnevskis I can't reproduce this issue in current master (409074aae5). I downloaded all the attached files, opened your linked.blend and toyed around with the proxied armature's bone of the left object. Seems to be fine to me.
However, I'm reluctant to just mark this as resolved as Jacques also couldn't reproduce.

@KonstantinsVisnevskis I can't reproduce this issue in current master (409074aae5). I downloaded all the attached files, opened your `linked.blend` and toyed around with the proxied armature's bone of the left object. Seems to be fine to me. However, I'm reluctant to just mark this as resolved as Jacques also couldn't reproduce.

Konstantins Visnevskis commented

2020-03-02 22:31:30 +01:00

Did a test with builder.blender.org - blender-2.83-7b8db971d42f-linux64.tar.xz.
Ok, so:

I download all three files in a single folder,
Opened "linked.blend"
Entered pose mode on right armature. Scaling the bone works as expected (the box scales along).
Entered pose mode on the left armature. Scaling the bone immediately offsets the box that should follow along in-place.
Exiting pose mode and moving the armature moves the box back where it should be.

For me it happens on two different machines - windows and Linux.
Should I test some particular version? I'm not sure where to look for 409074aae5.

Did a test with builder.blender.org - blender-2.83-7b8db971d42f-linux64.tar.xz. Ok, so: - I download all three files in a single folder, - Opened "linked.blend" - Entered pose mode on right armature. Scaling the bone works as expected (the box scales along). - Entered pose mode on the left armature. Scaling the bone immediately offsets the box that should follow along in-place. - Exiting pose mode and moving the armature moves the box back where it should be. For me it happens on two different machines - windows and Linux. Should I test some particular version? I'm not sure where to look for 409074aae5.

Philipp Oeser commented

2020-03-03 10:42:40 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Philipp Oeser commented

2020-03-03 10:42:40 +01:00

Hm, weird, I can still reproduce this ( ee7034949f )

Hm, weird, I can still reproduce this ( ee7034949f )

Sybren A. Stüvel commented

2020-03-03 11:02:09 +01:00

#72197-unable-to-reproduce.mp4

I can't reproduce this with either my own (b454a12233) or today's (fe7c4fb4a2) buildbot build. Let me know what I'm doing wrong.

[#72197-unable-to-reproduce.mp4](https://archive.blender.org/developer/F8384734/T72197-unable-to-reproduce.mp4) I can't reproduce this with either my own (b454a12233) or today's (fe7c4fb4a2) buildbot build. Let me know what I'm doing wrong.

Philipp Oeser commented

2020-03-03 11:16:50 +01:00

Indeed weird, looks like this here:
#72197.webm

Indeed weird, looks like this here: [#72197.webm](https://archive.blender.org/developer/F8384746/T72197.webm)

Konstantins Visnevskis commented

2020-03-03 12:09:42 +01:00

@dr.sybren Yeah, doing what you do in the recording produces what @lichtwerk shows with fe7c4fb4a2 for me. (Also did Load Factory preferences to be sure)

Edit: This behavior was first caught in a studio, where it happened on many machines to many people.

@dr.sybren Yeah, doing what you do in the recording produces what @lichtwerk shows with fe7c4fb4a2 for me. (Also did Load Factory preferences to be sure) Edit: This behavior was first caught in a studio, where it happened on many machines to many people.

Sybren A. Stüvel commented

2020-03-10 11:17:33 +01:00

Changed status from 'Confirmed' to: 'Needs User Info'

Sybren A. Stüvel commented

2020-03-10 11:17:33 +01:00

@KonstantinsVisnevskis can you try starting Blender with blender -t 1 thefile.blend? That way only a single thread is used during the dependency graph evaluation. If this solves the issue, it's likely a threading issue (for example caused by a missing relation in the depsgraph).

@KonstantinsVisnevskis can you try starting Blender with `blender -t 1 thefile.blend`? That way only a single thread is used during the dependency graph evaluation. If this solves the issue, it's likely a threading issue (for example caused by a missing relation in the depsgraph).

Konstantins Visnevskis commented

2020-03-10 11:50:01 +01:00

Hi,
./blender -t 1 linked.blend
unfortunately gives the same result.

Hi, ./blender -t 1 linked.blend unfortunately gives the same result.

Sybren A. Stüvel commented

2020-03-10 12:56:55 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Sybren A. Stüvel commented

2020-03-10 12:56:55 +01:00

That's too bad. I'll have to leave further investigation to @lichtwerk, as he can actually reproduce the issue.

Sybren A. Stüvel self-assigned this 2020-05-11 13:52:43 +02:00

Sybren A. Stüvel commented

2020-05-11 13:52:43 +02:00

I have found a way to reproduce.

Philipp Oeser commented

2020-05-11 14:19:46 +02:00

@dr.sybren : thx taking over (this somewhat slipped under the radar...)

Sybren A. Stüvel commented

2020-05-11 19:37:35 +02:00

Added subscribers: @Sergey, @brecht

Sybren A. Stüvel commented

2020-05-11 19:37:35 +02:00

@KonstantinsVisnevskis The problem can be worked around by making the armature collection visible in the library file.

In the example files, the armature is hidden. In various dupli-handling places in Blender there are loops over the visible objects in a collection, for example in DepsgraphRelationBuilder::build_collection(), and there are some other places where visibility plays a role.

Here is a little overview of the hierarchy in the library file test-arm-first.blend, and the main blend file:

The library file:	The main file:
{F8528597 size=full}	{F8528600 size=full}

In the library file the armature collection is hidden, but its proxy in the main blend file is visible. @Sergey @brecht before I spend more hours on this, is this a supported situation to begin with? Or should the visibility of the armature collection in the library file be managed with the eye icon instead?

@KonstantinsVisnevskis The problem can be worked around by making the armature collection visible in the library file. In the example files, the armature is hidden. In various dupli-handling places in Blender there are loops over the visible objects in a collection, for example in `DepsgraphRelationBuilder::build_collection()`, and there are some other places where visibility plays a role. Here is a little overview of the hierarchy in the library file `test-arm-first.blend`, and the main blend file: |The library file:|The main file:| | -- | -- | |{[F8528597](https://archive.blender.org/developer/F8528597/image.png) size=full}|{[F8528600](https://archive.blender.org/developer/F8528600/image.png) size=full}| In the library file the armature collection is hidden, but its proxy in the main blend file is visible. @Sergey @brecht before I spend more hours on this, is this a supported situation to begin with? Or should the visibility of the armature collection in the library file be managed with the eye icon instead?

Brecht Van Lommel commented

2020-05-11 19:50:56 +02:00

I would not spend any time on fixing old proxy issue like this at all, and focus on overrides instead. Especially as I guess the simple solution here is to just enable that collection in the original file.

I think this should be marked as low priority known issue. Visibility handling of proxies could probably be improved here, but eventually proxies will be obsolete anyway.

I would not spend any time on fixing old proxy issue like this at all, and focus on overrides instead. Especially as I guess the simple solution here is to just enable that collection in the original file. I think this should be marked as low priority known issue. Visibility handling of proxies could probably be improved here, but eventually proxies will be obsolete anyway.

Konstantins Visnevskis commented

2020-05-12 13:15:30 +02:00

Enabling showing armature in the viewport indeed seems to avoid the issue (it was hidden to avoid seeing two armatures after creating a proxy, which now seems not to be there).

If linking will be dropped entirely it seems indeed not worth investing effort.
If it won't - there seems to be more issues with character linking behaving in alike fashion and this is merely the one I managed to isolate, hoping they might be related.

As for overrides, when last tested, due to driver/shapekey (and possibly custom property) issues overrides weren't ready for characters yet. Though seem awesome otherwise.

Enabling showing armature in the viewport indeed seems to avoid the issue (it was hidden to avoid seeing two armatures after creating a proxy, which now seems not to be there). If linking will be dropped entirely it seems indeed not worth investing effort. If it won't - there seems to be more issues with character linking behaving in alike fashion and this is merely the one I managed to isolate, hoping they might be related. As for overrides, when last tested, due to driver/shapekey (and possibly custom property) issues overrides weren't ready for characters yet. Though seem awesome otherwise.

Sybren A. Stüvel commented

2020-05-19 15:38:38 +02:00

In #72197#929704, @KonstantinsVisnevskis wrote:
If linking will be dropped entirely it seems indeed not worth investing effort.

It won't. It's the proxy system that is slated for removal. This will happen some point after the library overrides are developed far enough to be a suitable replacement.

> In #72197#929704, @KonstantinsVisnevskis wrote: > If linking will be dropped entirely it seems indeed not worth investing effort. It won't. It's the proxy system that is slated for removal. This will happen some point after the library overrides are developed far enough to be a suitable replacement.

Sybren A. Stüvel removed their assignment 2020-11-02 16:37:50 +01:00

Bastien Montagne commented

2022-05-19 08:48:08 +02:00

Changed status from 'Confirmed' to: 'Archived'

Bastien Montagne closed this issue

2022-05-19 08:48:08 +02:00

Bastien Montagne commented

2022-05-19 08:48:08 +02:00

Time to archive this task, proxies have now been fully removed from Blender.

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

Effect of Collection order on Linking with scaled proxy armature #72197