Page MenuHome

Breaking shader node changes
Confirmed, NormalPublicTO DO


There are a number of proposed changes to shader nodes that break the Python API, mainly for add-ons that import and export shaders.

We need to make a decision to either:

  • Make these breaking changes in 3.2 or 3.3, and then do them all together with good communication so scripts only need to be updated once.
  • Postpone all breaking changes to 4.0, and see which parts of these patches can be non-breaking. For example we could have new general Mix/Combine/Separate nodes in addition to the existing ones.


Event Timeline

Brecht Van Lommel (brecht) changed the task status from Needs Triage to Confirmed.Mar 7 2022, 2:16 PM
Brecht Van Lommel (brecht) created this task.

Is there any way the Python API could be detoured to avoid breaking changes? E.g. "Fac" in the API aliased to "Factor"?

It would be a shame to have more duplicate code for Mix/Combine/Separate nodes

The problem is that some scripts use .name instead of the .identifier, and worse, that node.inputs["Factor"]" actually use the name instead of the identifier currently.

@Charlie Jolly (charlie), @Hans Goudey (HooglyBoogly), @Hallam Roberts (MysteryPancake), @Ethan-Hall (Ethan1080), @Clément Foucault (fclem)

I propose we do the following:

  • For Blender 3.2, add new Mix and Combine/Separate nodes and convert existing nodes in .blend files. Keep the old nodes available in the Python API but hidden from the menus.
  • Postpone other changes to another release where we make more breaking changes to shader nodes that. For example in the context of new textures nodes or improvements to the principled BSDF, that are likely to happen before 4.0.

That's rather conservative, but I think it's worth taking API compatibility a bit more seriously.