Certain drivers fail to copy when copying a full scene #66641

New Issue

James Hopkins · 2019-07-10T04:19:57+02:00

James Hopkins commented

2019-07-10 04:19:57 +02:00

System Information
Operating system: Linux-5.1.16-arch1-1-ARCH-x86_64-with-arch 64 Bits
Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.26

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-03 19:06, hash: cc667854a9

Short description of error
When copying a scene with drivers using certain camera functions (unsure what, if any, other parameters are affected) the copied object's drivers will still target the original scene's driver's bones- unlike every other driver and parent object. Possibly only related to the camera object. In the .blend file provided the copied camera's "orthographic scale" driver and "passpartout" driver fail to update to the current scene's objects and instead refer to the original scene.

Exact steps for others to reproduce the error
Copy scene with drivers applied to camera object, select copied bone(s) and pose them, fail to update camera. Can be manually corrected.

system-info.txt

camera-driver-bug-cc.blend

**System Information** Operating system: Linux-5.1.16-arch1-1-ARCH-x86_64-with-arch 64 Bits Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.26 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-03 19:06, hash: `cc667854a9` **Short description of error** When copying a scene with drivers using certain camera functions (unsure what, if any, other parameters are affected) the copied object's drivers will still target the original scene's driver's bones- unlike every other driver and parent object. Possibly only related to the camera object. In the .blend file provided the copied camera's "orthographic scale" driver and "passpartout" driver fail to update to the current scene's objects and instead refer to the original scene. **Exact steps for others to reproduce the error** Copy scene with drivers applied to camera object, select copied bone(s) and pose them, fail to update camera. Can be manually corrected. [system-info.txt](https://archive.blender.org/developer/F7580456/system-info.txt) [camera-driver-bug-cc.blend](https://archive.blender.org/developer/F7580457/camera-driver-bug-cc.blend)

James Hopkins commented

2019-07-10 04:19:57 +02:00

Added subscriber: @JamesHopkins-3

blender-admin commented

2019-07-10 04:19:57 +02:00

#47828 was marked as duplicate of this issue

Sybren A. Stüvel commented

2019-07-10 11:10:05 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2019-07-10 11:10:05 +02:00

I copied the active scene from your example file (chose Full Copy), but can't reproduce the issue. The "sliders" still manipulate the camera in the same scene. Maybe re-test if this is still an issue in the most recent daily build?

James Hopkins commented

2019-07-10 22:45:57 +02:00

In #66641#717154, @dr.sybren wrote:
I copied the active scene from your example file (chose Full Copy), but can't reproduce the issue. The "sliders" still manipulate the camera in the same scene. Maybe re-test if this is still an issue in the most recent daily build?

I downloaded my example file to test on today's current Windows build and the problem remains the same. I did not download the latest blender 2.8 build for Linux but did create a more concise example .blend file to demonstrate (hopefully) the problem. The main problem, that I'm finding, is that the parameters for the Object Data are not updating to the copied object when copying over to a full scene. When I manually copy the object (camera) and bone object, the drivers correctly update. This appears to be the case for all Object Data sliders, but I have not extensively tested that, nor if it happens to non-camera objects.

The .blend attached has four bones, the two left bones manipulate the X and Y position of the camera, and the other two bones manipulate the X and Y shift on the camera's Object Data. When copied from a full scene copy, the shift object drivers fail to update to the new scene's bones and instead refer to the original scene's bone object. (should be Armature.001, instead it is Armature on the copied scene)

I am sorry if my original explanation was vague or unclear, as I had only uploaded the original blend file and did not strip out unnecessary elements. Some bones in the original file do work as intended, and I did not properly point that out I feel. I hope this blend file is repeatable on your end.

driver-bug-cc.blend

> In #66641#717154, @dr.sybren wrote: > I copied the active scene from your example file (chose Full Copy), but can't reproduce the issue. The "sliders" still manipulate the camera in the same scene. Maybe re-test if this is still an issue in the most recent daily build? I downloaded my example file to test on today's current Windows build and the problem remains the same. I did not download the latest blender 2.8 build for Linux but did create a more concise example .blend file to demonstrate (hopefully) the problem. The main problem, that I'm finding, is that the parameters for the Object Data are not updating to the copied object when copying over to a full scene. When I manually copy the object (camera) and bone object, the drivers correctly update. This appears to be the case for all Object Data sliders, but I have not extensively tested that, nor if it happens to non-camera objects. The .blend attached has four bones, the two left bones manipulate the X and Y position of the camera, and the other two bones manipulate the X and Y shift on the camera's Object Data. When copied from a full scene copy, the shift object drivers fail to update to the new scene's bones and instead refer to the original scene's bone object. (should be Armature.001, instead it is Armature on the copied scene) I am sorry if my original explanation was vague or unclear, as I had only uploaded the original blend file and did not strip out unnecessary elements. Some bones in the original file do work as intended, and I did not properly point that out I feel. I hope this blend file is repeatable on your end. [driver-bug-cc.blend](https://archive.blender.org/developer/F7585220/driver-bug-cc.blend)

Sybren A. Stüvel commented

2019-07-11 11:19:51 +02:00

This is why a minimal example is so important (and it still isn't minimal, it has twice the number of bones necessary to show the problem, no need to do both X and Y).

I can confirm the bug though. It appears that drivers on objects are updated to point to the copied targets correctly, but drivers on object data are still pointing to the original targets.

To reproduce the bug:

Make a Full Copy of the scene.
Select the camera in the new scene.
Run this code:

print(C.object.animation_data.drivers[1].driver.variables[0].targets[0].id)
print(C.object.data.animation_data.drivers[1].driver.variables[0].targets[0].id)

Both should print <bpy_struct, Object("Armature.003")>, but the 2nd one prints <bpy_struct, Object("Armature")> instead.

This is why a *minimal* example is so important (and it still isn't minimal, it has twice the number of bones necessary to show the problem, no need to do both X and Y). I can confirm the bug though. It appears that drivers on objects are updated to point to the copied targets correctly, but drivers on object data are still pointing to the original targets. To reproduce the bug: - Make a Full Copy of the scene. - Select the camera in the new scene. - Run this code: ``` print(C.object.animation_data.drivers[1].driver.variables[0].targets[0].id) print(C.object.data.animation_data.drivers[1].driver.variables[0].targets[0].id) ``` Both should print `<bpy_struct, Object("Armature.003")>`, but the 2nd one prints `<bpy_struct, Object("Armature")>` instead.

Sybren A. Stüvel self-assigned this 2019-10-01 12:47:07 +02:00

Bastien Montagne commented

2019-10-01 14:48:19 +02:00

Added subscriber: @mont29

Sybren A. Stüvel was unassigned by Bastien Montagne

2019-10-01 14:48:19 +02:00

Bastien Montagne self-assigned this 2019-10-01 14:48:19 +02:00

Bastien Montagne commented

2019-10-01 14:48:19 +02:00

Will steel that one and commit a dirty band-aid that should fix that case and many other similar ones, but the whole 'make single user' (and scene copy) code needs a complete rewrite at some point to get a sane behavior…