Duplicating materials that use drivers on its inputs break driver reference to corresponding input on the duplicated materials #83914

New Issue

Juan Muñoz · 2020-12-18T00:03:44+01:00

Juan Muñoz commented

2020-12-18 00:03:44 +01:00

System Information
Operating system: Linux-5.9.14-arch1-1-x86_64-with-glibc2.32 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.45.01

Blender Version
Broken: version: 2.91.0, branch: makepkg, commit date: 2020-11-25 11:06, hash: b50598bc78
Worked: (newest version of Blender that worked as expected)

Short description of error
When using a driver on a material input, if that material gets duplicated (as in bpy.ops.material.new()) then the drivers for that material don't work anymore since the RNA path is defined like bpy.data.materials["materialName"].... but the "materialName" stays the same instead of changing to "materialName.001". This only happens when duplicating the material, renaming is not a problem. This problem renders all custom made materials that use drivers on its inputs to a one-time use scenario since the user would need to manually change all RNA paths to the new material name whenever the material need to be duplicated to have different parameters on different objects, for example.

Exact steps for others to reproduce the error

Open the provided test file testDrivers.blend, inside are two cubes.
Object Cube has a material testA that is a glossy shader inside a node group
Duplicate material testA, creating test.001 and so on.
Set the material of Cube.001 to the duplicated material
The material has a driver on the Roughness input, when changing that input, only the material testA works, testA.001...testA.nnn dont work.
testDrivers.blend

**System Information** Operating system: Linux-5.9.14-arch1-1-x86_64-with-glibc2.32 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.45.01 **Blender Version** Broken: version: 2.91.0, branch: makepkg, commit date: 2020-11-25 11:06, hash: `b50598bc78` Worked: (newest version of Blender that worked as expected) **Short description of error** When using a driver on a material input, if that material gets duplicated (as in bpy.ops.material.new()) then the drivers for that material don't work anymore since the RNA path is defined like bpy.data.materials["materialName"].... but the "materialName" stays the same instead of changing to "materialName.001". This only happens when duplicating the material, renaming is not a problem. This problem renders all custom made materials that use drivers on its inputs to a one-time use scenario since the user would need to manually change all RNA paths to the new material name whenever the material need to be duplicated to have different parameters on different objects, for example. **Exact steps for others to reproduce the error** 1. Open the provided test file testDrivers.blend, inside are two cubes. 2. Object Cube has a material testA that is a glossy shader inside a node group 3. Duplicate material testA, creating test.001 and so on. 4. Set the material of Cube.001 to the duplicated material 5. The material has a driver on the Roughness input, when changing that input, only the material testA works, testA.001...testA.nnn dont work. [testDrivers.blend](https://archive.blender.org/developer/F9515783/testDrivers.blend)

Juan Muñoz commented

2020-12-18 00:03:44 +01:00

Added subscriber: @lightdefender

Philipp Oeser commented

2020-12-18 11:57:44 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-12-18 11:57:44 +01:00

Wouldnt using self make sense here?
https://docs.blender.org/manual/en/latest/animation/drivers/drivers_panel.html#expressions

Maybe in conjunction with a Custom property on the material?
I'll see if I can set this up.

That being said, I doubt blender would remap references in the driver? How would it know which references to update?
For example if you reference some object which is the parent of you driven object in you driver, then you happen to reparent the driven object, would you expect blender to remap that in the driver?

Wouldnt using `self` make sense here? https://docs.blender.org/manual/en/latest/animation/drivers/drivers_panel.html#expressions Maybe in conjunction with a Custom property on the material? I'll see if I can set this up. That being said, I doubt blender would remap references in the driver? How would it know which references to update? For example if you reference some object which is the parent of you driven object in you driver, then you happen to reparent the driven object, would you expect blender to remap that in the driver?

Philipp Oeser commented

2020-12-18 12:40:25 +01:00

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

Philipp Oeser commented

2020-12-18 12:40:25 +01:00

There are more problems here the way this is set up:

you would run into a dependency cyle anyways, right? [already atm., there is one reported]
starting from your setup, this already breaks if you duplicate the nodegroup [dont have to duplicate the material]
- then there are two nodegroups referencing the same nodetree, the duplicated nodegroups' input wouldnt work correctly here already.

I think we would need a better usecase to be able to progress here [as in: what exactly are you trying to achieve? In your example usecase it would obviously be simpler to just connect the sockets with a real link instead of using a driver].
So will set to Needs Information from User, for now to avoid closing right away

There are more problems here the way this is set up: - you would run into a dependency cyle anyways, right? [already atm., there is one reported] - starting from your setup, this already breaks if you duplicate the nodegroup [dont have to duplicate the material] - then there are two nodegroups referencing the same nodetree, the duplicated nodegroups' input wouldnt work correctly here already. I think we would need a better usecase to be able to progress here [as in: what exactly are you trying to achieve? In your example usecase it would obviously be simpler to just connect the sockets with a real link instead of using a driver]. So will set to Needs Information from User, for now to avoid closing right away

Juan Muñoz commented

2020-12-18 12:49:27 +01:00

I will try using self with a Custom property too to see if that can circumvent this issue.

Still, I believe in these case the reference should be updated automatically, taking the example that you gave me, in the case that you describe that totally makes sense, but the case that I'm talking about would be more like if I have I took both the parent and child objects and duplicated them both, I would expect that the drivers would maintain the hierarchy. That being said, when speaking about objects maybe it doesn't make as much sense because that becomes subjective to what the users expected result could be. But when speaking about materials I would expect that if I take a material that has drivers on it and duplicate it, the new material would change parents because the nodes initially references are no longer contained within material x and now exist within x.001.

Maybe whenever bpy.ops.material.new() is run and the new material is a copy of an existing material that has drivers, then store the original name of the material and after its created update the references that match that material name?
Or maybe a second way to duplicate materials so that updating references becomes a choice? Because it really limits how materials can use drivers if whenever I need to duplicate that material to give it different colors for example, then I have to also have to remake all drivers.

Maybe I'm being subjective about this, feel free to close it if that's the case.

EDIT: I pressed send by accident

I will try using `self` with a Custom property too to see if that can circumvent this issue. Still, I believe in these case the reference should be updated automatically, taking the example that you gave me, in the case that you describe that totally makes sense, but the case that I'm talking about would be more like if I have I took both the parent and child objects and duplicated them both, I would expect that the drivers would maintain the hierarchy. That being said, when speaking about objects maybe it doesn't make as much sense because that becomes subjective to what the users expected result could be. But when speaking about materials I would expect that if I take a material that has drivers on it and duplicate it, the new material would change parents because the nodes initially references are no longer contained within material x and now exist within x.001. Maybe whenever bpy.ops.material.new() is run and the new material is a copy of an existing material that has drivers, then store the original name of the material and after its created update the references that match that material name? Or maybe a second way to duplicate materials so that updating references becomes a choice? Because it really limits how materials can use drivers if whenever I need to duplicate that material to give it different colors for example, then I have to also have to remake all drivers. Maybe I'm being subjective about this, feel free to close it if that's the case. EDIT: I pressed send by accident

Juan Muñoz commented

2020-12-18 13:07:04 +01:00

In #83914#1078103, @lichtwerk wrote:
There are more problems here the way this is set up:

you would run into a dependency cyle anyways, right? [already atm., there is one reported]

starting from your setup, this already breaks if you duplicate the nodegroup [dont have to duplicate the material]
-- then there are two nodegroups referencing the same nodetree, the duplicated nodegroups' input wouldnt work correctly here already.

I think we would need a better usecase to be able to progress here [as in: what exactly are you trying to achieve? In your example usecase it would obviously be simpler to just connect the sockets with a real link instead of using a driver].
So will set to Needs Information from User, for now to avoid closing right away

Here is a complete shader that I made using some drivers to control a few parameters (in this case using color inputs to control color ramp colors inside). If i want to have another instance of the material so it can have different colors then that wouldn't be possible because if I duplicate the material. Making another instance of the node group doesn't work because the path to the new nodegroup goes through the original material, because the RNA path for nodegroup inputs has to go through the material itself to identify it.

pottery_shader.blend

> In #83914#1078103, @lichtwerk wrote: > There are more problems here the way this is set up: > > - you would run into a dependency cyle anyways, right? [already atm., there is one reported] > - starting from your setup, this already breaks if you duplicate the nodegroup [dont have to duplicate the material] > -- then there are two nodegroups referencing the same nodetree, the duplicated nodegroups' input wouldnt work correctly here already. > > I think we would need a better usecase to be able to progress here [as in: what exactly are you trying to achieve? In your example usecase it would obviously be simpler to just connect the sockets with a real link instead of using a driver]. > So will set to Needs Information from User, for now to avoid closing right away Here is a complete shader that I made using some drivers to control a few parameters (in this case using color inputs to control color ramp colors inside). If i want to have another instance of the material so it can have different colors then that wouldn't be possible because if I duplicate the material. Making another instance of the node group doesn't work because the path to the new nodegroup goes through the original material, because the RNA path for nodegroup inputs has to go through the material itself to identify it. [pottery_shader.blend](https://archive.blender.org/developer/F9516385/pottery_shader.blend)

dupoxy commented

2020-12-19 06:18:21 +01:00

Added subscriber: @dupoxy

dupoxy commented

2020-12-19 06:18:21 +01:00

This is maybe releted to #55044 : Duplicating a node with a driver loses the driver

Philipp Oeser commented

2021-02-11 11:05:20 +01:00

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

Philipp Oeser commented

2021-08-16 14:32:11 +02:00

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

Philipp Oeser closed this issue

2021-08-16 14:32:11 +02:00

Philipp Oeser commented

2021-08-16 14:32:11 +02:00

Been looking at this again (sorry this slipped under the radar).
Think #55044 is unrelated (since we are not loosing the driver, just the reference is not updated).

Also have to admit that there might not be a nice solution afaics.
Thinking further, the root problem is really that when adding a driver variable, we cannot specify an ID Type (e.g. Material) without also defining a specific ID (a specific material).
This is similar to the issue of absolute keying set paths, see #86961 (A bug in a scene. "i" does not work for creating keyframes).

So the area could definitely improve, this is however not considered a bug at the moment.
Thy again reporting, but will have to archive for now.

Been looking at this again (sorry this slipped under the radar). Think #55044 is unrelated (since we are not loosing the driver, just the reference is not updated). Also have to admit that there might not be a nice solution afaics. Thinking further, the root problem is really that when adding a driver variable, we cannot specify an `ID Type` (e.g. Material) without also defining a specific ID (a specific material). This is similar to the issue of absolute keying set paths, see #86961 (A bug in a scene. "i" does not work for creating keyframes). So the area could definitely improve, this is however not considered a bug at the moment. Thy again reporting, but will have to archive for now.

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

Duplicating materials that use drivers on its inputs break driver reference to corresponding input on the duplicated materials #83914