Bone drivers do not copy when duplicated #49182

New Issue

Wayne Dixon · 2016-08-28T09:22:40+02:00

Wayne Dixon commented

2016-08-28 09:22:40 +02:00

System Information
Mac OSX 10.9.5 and NVIDIA GeForce GTX 470

Blender Version
Broken: 2.77 (sub 3)
Worked: ?

If a bone has any driver (on constraint or property) and it is duplicated (shift D in edit mode or "symmetrize") the drivers are not copied.

Bone constraints, however, copy perfectly and also try to find the correct .L or .R target if applicable.
This would save a lot of time if the drivers worked in the same way.

**System Information** Mac OSX 10.9.5 and NVIDIA GeForce GTX 470 **Blender Version** Broken: 2.77 (sub 3) Worked: ? If a bone has any driver (on constraint or property) and it is duplicated (shift D in edit mode or "symmetrize") the drivers are not copied. Bone constraints, however, copy perfectly and also try to find the correct .L or .R target if applicable. This would save a lot of time if the drivers worked in the same way.

Wayne Dixon commented

2016-08-28 09:22:40 +02:00

Changed status to: 'Open'

Wayne Dixon commented

2016-08-28 09:22:40 +02:00

Added subscriber: @WayneDixon

blender-admin commented

2016-08-28 09:22:40 +02:00

#87415 was marked as duplicate of this issue

Joshua Leung self-assigned this 2016-08-28 14:30:29 +02:00

Joshua Leung commented

2016-08-28 14:33:14 +02:00

This is definitely feature request territory, so I've reclassified this as such.

I agree that this sort of thing would be really handy. However, it's not done now because it's not trivial. With constraints, you've got the set of constraints per bone stored on the bones themselves, while with drivers, there's only a big list of them per datablock. It's doable, but just not dead-easy to do, hence why it hasn't been done.

This is definitely feature request territory, so I've reclassified this as such. I agree that this sort of thing would be really handy. However, it's not done now because it's not trivial. With constraints, you've got the set of constraints per bone stored on the bones themselves, while with drivers, there's only a big list of them per datablock. It's doable, but just not dead-easy to do, hence why it hasn't been done.

Joshua Leung was unassigned by Sybren A. Stüvel

2020-11-09 18:31:30 +01:00

Sybren A. Stüvel commented

2020-11-09 18:31:30 +01:00

Added subscriber: @JoshuaLeung

Demeter Dzadik commented

2021-08-25 14:53:12 +02:00

Added subscriber: @Mets

Demeter Dzadik commented

2021-08-25 14:53:12 +02:00

Even if this were done, it would be nice not to just hack it in for this one case but to actually have something that is consistent across all of Blender. There are already quite some inconsistencies when it comes to what I would describe as "object content drivers", that is, drivers that are on shape keys/materials/bones/custom properties.

Duplication of modifiers and constraints are also possible, so if we want to support driver duplication for bones, these should be supported as well. It would be nice if shape keys and custom properties could also be duplicated, and the same would apply there.

This task only mentioned duplication, so just tackling this would already be nice, but there are other cases where the resulting state of drivers is hard to predict:

Renaming bones, constraints, modifiers or key blocks will preserve the drivers on them, but renaming custom properties does not.
Renaming bones or custom properties does not preserve data paths of drivers that are relying on them, but renaming constraints, key blocks and modifiers does.
Deleting any object contents does not delete their corresponding drivers, which can be confusing sometimes, and result in console spam. There is a good way to clean these up with the graph editor, but it's not super clear or intuitive to new users, so maybe worth considering tackling this as a long-term, although separate goal.

Even if this were done, it would be nice not to just hack it in for this one case but to actually have something that is consistent across all of Blender. There are already quite some inconsistencies when it comes to what I would describe as "object content drivers", that is, drivers that are on shape keys/materials/bones/custom properties. - **Duplication** of modifiers and constraints are also possible, so if we want to support driver duplication for bones, these should be supported as well. It would be nice if shape keys and custom properties could also be duplicated, and the same would apply there. This task only mentioned duplication, so just tackling this would already be nice, but there are other cases where the resulting state of drivers is hard to predict: - **Renaming** bones, constraints, modifiers or key blocks will preserve the drivers on them, but renaming custom properties does not. - **Renaming** bones or custom properties does not preserve data paths of drivers that are relying on them, but renaming constraints, key blocks and modifiers does. - **Deleting** any object contents does not delete their corresponding drivers, which can be confusing sometimes, and result in console spam. There is a good way to clean these up with the graph editor, but it's not super clear or intuitive to new users, so maybe worth considering tackling this as a long-term, although separate goal.

Delano762 commented

2021-09-20 18:35:28 +02:00

Added subscriber: @Delano762

Delano762 commented

2021-09-20 18:50:36 +02:00

Wanted to add three things:

This issue applies to object constraints as well.
This can be replicated just by using the "Copy Constraints to Selected Objects/Bones" option between objects/bones, as shown in the attached video. At this moment, it is impossible to copy constraints along with their drivers - you can copy constraints, but if you want the drivers too, you are forced to copy the drivers manually, one by one.
I believe #87415 is a duplicate issue.
2021-09-20 18-23-48.mp4

Wanted to add three things: 1. This issue applies to object constraints as well. 2. This can be replicated just by using the *"Copy Constraints to Selected Objects/Bones"* option between objects/bones, as shown in the attached video. At this moment, it is impossible to copy constraints along with their drivers - you can copy constraints, but if you want the drivers too, you are forced to copy the drivers manually, one by one. 3. I believe #87415 is a duplicate issue. [2021-09-20 18-23-48.mp4](https://archive.blender.org/developer/F10516421/2021-09-20_18-23-48.mp4)

Pauan commented

2021-09-25 22:15:41 +02:00

Added subscriber: @pauanyu_blender

Anna Celarek commented

2021-12-03 10:08:01 +01:00

Added subscriber: @AnnaCelarek

Anna Celarek commented

2021-12-03 10:24:33 +01:00

I have 3 major use cases:

Mirror bones from the finished .L rig to .R
then usually I copy all drivers by hand and change .L to .R in their driver path
Duplicate bones into similar position (e.g. in a chain)
Duplicate constraints to bones with similar function
for 2. and 3. usually there's no editing or renaming of the drivers, just straight forward copy paste.

It would really save a lot of time if this copying happened automatically.

I have 3 major use cases: 1. Mirror bones from the finished .L rig to .R then usually I copy all drivers by hand and change .L to .R in their driver path 2. Duplicate bones into similar position (e.g. in a chain) 3. Duplicate constraints to bones with similar function for 2. and 3. usually there's no editing or renaming of the drivers, just straight forward copy paste. It would really save a lot of time if this copying happened automatically.

Cigitia commented

2022-05-05 00:25:32 +02:00

Added subscriber: @Cigitia

Sybren A. Stüvel commented

2022-11-24 15:08:42 +01:00

Added subscribers: @NahuelBelich, @dr.sybren, @mano-wii, @filedescriptor, @VLC

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bone drivers do not copy when duplicated #49182