backward compatibility issue: old files break all addons that use render layer socket identifiers due to naming convention change. #96239

New Issue

michael campbell · 2022-03-08T15:53:32+01:00

michael campbell commented

2022-03-08 15:53:32 +01:00

System Information
Operating system: Windows-10-10.0.19042-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12

Blender Version
Broken: version: 2.79
Worked: (newest version of Blender that worked as expected)

Short description of error
Back in the days (some time between 2.73 and 2.79), it appears that some sockets of the Render Layer node had the identifier different from the name.

This can be seen for example with the DiffDir socket which in old files (2.73) had the identifier named 'Diffuse Direct' and in new files it is layered 'DiffDir'.

This makes it impossible to use socket identifiers reliably. This is worsened by the fact that socket identifiers are read only, so can't be upgraded by the addons.

It's not feasable for addons to use the socket.name because this will break functionality on non render layer nodes....and in my case is a substantial amount of work to update many thousands lines of code.

Could these be automatically renamed to match the current standard during the versioning checks on file load?

Exact steps for others to reproduce the error

Open the classroom benchmark scene
Go to Scripting Workspace
Run this script:

for socket in bpy.context.scene.node_tree.nodes['Render Layers'].outputs:
    print(socket.identifier)

The result will be inconsistent if we compare with new files:

Old File	New File
Z	Depth
Diffuse Direct	DiffDir
Diffuse Color	DiffCol
Glossy Direct	GlossDir
Glossy Color	GlossCol
Diffuse Indirect	DiffInd
Glossy Indirect	GlossInd
Transmission Direct	TransDir
Transmission Indirect	TransInd
Transmission Color	TransCol
Subsurface Direct	SubsurfaceDir
Subsurface Indirect	SubsurfaceInd
Subsurface Color	SubsurfaceCol

**System Information** Operating system: Windows-10-10.0.19042-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12 **Blender Version** Broken: version: 2.79 Worked: (newest version of Blender that worked as expected) **Short description of error** Back in the days (some time between 2.73 and 2.79), it appears that some sockets of the `Render Layer` node had the `identifier` different from the `name`. This can be seen for example with the `DiffDir` socket which in old files (2.73) had the identifier named `'Diffuse Direct'` and in new files it is layered `'DiffDir'`. This makes it impossible to use socket identifiers reliably. This is worsened by the fact that socket identifiers are read only, so can't be upgraded by the addons. It's not feasable for addons to use the socket.name because this will break functionality on non render layer nodes....and in my case is a substantial amount of work to update many thousands lines of code. Could these be automatically renamed to match the current standard during the versioning checks on file load? **Exact steps for others to reproduce the error** - Open the classroom benchmark scene - Go to `Scripting` `Workspace` - Run this script: ``` for socket in bpy.context.scene.node_tree.nodes['Render Layers'].outputs: print(socket.identifier) ``` The result will be inconsistent if we compare with new files: |Old File| New File |---|--- |Z|Depth |Diffuse Direct|DiffDir |Diffuse Color|DiffCol |Glossy Direct|GlossDir |Glossy Color|GlossCol |Diffuse Indirect|DiffInd |Glossy Indirect|GlossInd |Transmission Direct|TransDir |Transmission Indirect|TransInd |Transmission Color|TransCol |Subsurface Direct|SubsurfaceDir |Subsurface Indirect|SubsurfaceInd |Subsurface Color|SubsurfaceCol

michael campbell commented

2022-03-08 15:53:32 +01:00

Added subscriber: @3di

Germano Cavalcante commented

2022-03-08 19:23:53 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-03-08 19:23:53 +01:00

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

Germano Cavalcante commented

2022-03-08 19:23:53 +01:00

Thanks for the report, but please try to make the triaging team's work a little easier by giving a little more context and steps to reproduce the error.

Since you mentioned DiffDir I assume you are referring to the Render Layers node with the Cycles engine in context, am I right?

When was this node's identifier called Diffuse Direct?

From what I can see it is called DiffDir since version 2.79:

>>> C.scene.node_tree.nodes['Render Layers'].outputs['

                                                      AO']
                                                      Alpha']
                                                      Color']
                                                      Depth']
                                                      DiffCol']
                                                      DiffDir']
                                                      DiffInd']
                                                      Diffuse']
                                                      Emit']
                                                      Env']
                                                      GlossCol']
                                                      GlossDir']
                                                      GlossInd']
                                                      Image']
                                                      IndexMA']
                                                      IndexOB']
                                                      Indirect']
                                                      Mist']
                                                      Normal']
                                                      Reflect']
                                                      Refract']
                                                      Shadow']
                                                      Spec']
                                                      SubsurfaceCol']
                                                      SubsurfaceDir']
                                                      SubsurfaceInd']
                                                      TransCol']
                                                      TransDir']
                                                      TransInd']
                                                      UV']
                                                      Vector']

So how old is this "backward compatibility issue"?

*(A guideline for making a good bug report can be found at https:*wiki.blender.org/wiki/Process/Bug_Reports )//

Thanks for the report, but please try to make the triaging team's work a little easier by giving a little more context and steps to reproduce the error. Since you mentioned `DiffDir` I assume you are referring to the `Render Layers` node with the `Cycles` engine in context, am I right? When was this node's identifier called `Diffuse Direct`? From what I can see it is called `DiffDir` since version 2.79: ``` >>> C.scene.node_tree.nodes['Render Layers'].outputs[' AO'] Alpha'] Color'] Depth'] DiffCol'] DiffDir'] DiffInd'] Diffuse'] Emit'] Env'] GlossCol'] GlossDir'] GlossInd'] Image'] IndexMA'] IndexOB'] Indirect'] Mist'] Normal'] Reflect'] Refract'] Shadow'] Spec'] SubsurfaceCol'] SubsurfaceDir'] SubsurfaceInd'] TransCol'] TransDir'] TransInd'] UV'] Vector'] ``` So how old is this "backward compatibility issue"? *(A guideline for making a good bug report can be found at https:*wiki.blender.org/wiki/Process/Bug_Reports )//

michael campbell commented

2022-03-08 19:54:20 +01:00

Hi, I'm not sure of the blender version in which this change occurred, but the issue is there in the benchmark classroom scene. Yes, as mentioned in the report, I'm referring to the render layers node, EEVEE wasn't about at the time and the Blender Render engine is no longer in Blender, so yes I'm referring to Cycles 👍 Sorry I thought this was obvious, particularly as I mentioned this is apparent in the classroom benchmark scene which uses cycles.

Also, in your print above you're printing out the socket names, this is not related to what was said in the report.

Please use:

import bpy
 
for socket in bpy.context.scene.node_tree.nodes['Render Layers'].outputs:
    print(socket.identifier)

Hi, I'm not sure of the blender version in which this change occurred, but the issue is there in the benchmark classroom scene. Yes, as mentioned in the report, I'm referring to the render layers node, EEVEE wasn't about at the time and the Blender Render engine is no longer in Blender, so yes I'm referring to Cycles 👍 Sorry I thought this was obvious, particularly as I mentioned this is apparent in the classroom benchmark scene which uses cycles. Also, in your print above you're printing out the socket names, this is not related to what was said in the report. Please use: ``` import bpy for socket in bpy.context.scene.node_tree.nodes['Render Layers'].outputs: print(socket.identifier) ```

michael campbell commented

2022-03-08 19:57:50 +01:00

Just to confirm, if you open the classroom benchmark scene, and run the code I gave above, you should be able to see the issue 👍

If you then run the same code in a new scene, you'll notice the socket identifiers now match the socket names (the new naming convention for socket identifiers).

Just to confirm, if you open the classroom benchmark scene, and run the code I gave above, you should be able to see the issue 👍 If you then run the same code in a new scene, you'll notice the socket identifiers now match the socket names (the new naming convention for socket identifiers).

Germano Cavalcante commented

2022-03-08 22:54:28 +01:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Germano Cavalcante commented

2022-03-08 22:54:28 +01:00

Added subscriber: @brecht

Germano Cavalcante commented

2022-03-08 22:54:28 +01:00

~~This seems to be intentional seen c74c72101e.~~
~~@brecht, since you are the author of the commit, how to proceed here, confirm this backward compatibility break as a bug or is it more of a Known Issue?~~
EDIT: the problem is older

~~This seems to be intentional seen c74c72101e.~~ ~~@brecht, since you are the author of the commit, how to proceed here, confirm this backward compatibility break as a bug or is it more of a Known Issue?~~ **EDIT:** the problem is older

michael campbell commented

2022-03-08 22:59:17 +01:00

@mano-wii thanks. That commit seems only related to custom passes. This report is entirely about the built in passes. So custom passes should remain untouched by suggested versioning renaming.

Germano Cavalcante commented

2022-03-09 13:44:34 +01:00

Removed subscriber: @brecht

Hans Goudey commented

2022-03-09 22:24:56 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-03-09 22:24:56 +01:00

Not sure if I understand the report correctly, but I don't think I would consider it a bug. While it's generally nice to avoid changing identifiers to provide a stable Python API, there will be some changes necessary in different versions of Blender, this is expected.

michael campbell commented

2022-03-09 22:42:57 +01:00

@HooglyBoogly Isn't the purpose of the versioning checks to ensure old files work with new standards? What potential issues do you see?

Hans Goudey commented

2022-03-09 22:54:00 +01:00

Yes, changes are usually versioned. That's not always possible though. And since this happened many years ago, I don't think we would address it with new versioning now.

michael campbell commented

2022-03-09 23:01:22 +01:00

It's a shame because it would have no negative consequences beyond what's expected with versioning changes (backward compatibility), and would immediately get a ton of addons working no doubt. I was talking to someone the other day who's still trapped on an old version of blender because the addon developers haven't updated their addons.

For me I've already coded the workaround now, but it was a massive amount of work, which I'd guess many addon developers would avoid in favour of discontinuing their addon.

This one's particularly nasty because the identifiers are read only, removing the possibility of updating the offending properties to the current standard from within the addon.

It's a shame because it would have no negative consequences beyond what's expected with versioning changes (backward compatibility), and would immediately get a ton of addons working no doubt. I was talking to someone the other day who's still trapped on an old version of blender because the addon developers haven't updated their addons. For me I've already coded the workaround now, but it was a massive amount of work, which I'd guess many addon developers would avoid in favour of discontinuing their addon. This one's particularly nasty because the identifiers are read only, removing the possibility of updating the offending properties to the current standard from within the addon.

michael campbell commented

2022-03-09 23:03:32 +01:00

Perhaps someone could update the benchmark scenes you provide as a lesser than ideal alternative?

michael campbell commented

2022-03-10 18:10:03 +01:00

I'm probably not getting my point across very well. Addon developers should modify addons to meet api changes, but if it's a versioning issue such as this that's not addressed in blenders versioning checks, it means they effectively have to build addons that will work with files from every version of blender. It's an unrealistic proposition to trudge through every blend data convention change and then develop multiple functions to cater for them all. In this case one function to rename socket identifiers to the current standard will save a huge amount of effort and unfathomable bugs for countless developers I'd imagine.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

backward compatibility issue: old files break all addons that use render layer socket identifiers due to naming convention change. #96239