Page MenuHome

Library Overrides: Shader drivers stop working after save and reload
Confirmed, NormalPublicTO DO

Description

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

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2020-11-02 08:33, hash: rBd49c71e96e55

Short description of error
Shader drivers seem to stop working after a file with a library override is saved and reloaded. This can be fixed by running Resync Library Override Hierarchy on the collection every time the file is opened.

Exact steps for others to reproduce the error

  • File:
  • Link the CH-plane collection to a fresh file and Make Library Override.
  • Enter Material Preview in the 3D viewport.
  • On the armature's only bone, find the "transparency" custom property and change it. It works.
  • Save your file and reload it. The transparency custom property no longer works.
  • Resync the collection and it works again.

CC @Bastien Montagne (mont29)

TEMPORARY WORKAROUND:

For now it is possible to work around this by relaying the information through an intermediate custom property on the material:

  • Add a custom property to the material datablock and move the currently existing driver to it.
  • Use a driver that copies the value of the newly added material custom property into the node tree.

For some more details and an example file see comments below.

Event Timeline

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "To Do".Nov 4 2020, 4:27 PM

This is expected currently, as node trees are not overridable yet.

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Nov 5 2020, 1:09 PM

For now it is possible to work around this by relaying the information through a custom property on the material:

  • Add a custom property to the material and move the currently existing driver to it.
  • Use a driver that reads the material's custom property from the node tree.

This works because overrides on datablock custom properties are supported, and references from a datablock to itself are effectively always implicitly and automatically overridden due to the way things work internally, even if actual overrides aren't implemented for that property (this is why the intermediate property must be on the material itself).

Note: If you open the shader editor on the overridden material it would seem like the values don't update, but the actual dependency graph is correct and Eevee & Cycles react to the value changes.

I thought I had a bug, so I checked this task and if I understand correctly overrides in material node trees is still incomplete, am I correct ? It works in some files, and not in others (same character though, which is unexpected). Should I report it ? (I am using 2.92)

NodeTrees are definitely not supported currently by overrides, and are indeed a known TODO, no bug here.

This is a pair of test files (created in 2.92) that demonstrate the workaround. Opening matoverride1-user.blend should display a green cube if everything works; yellow means it's broken.

It seems the workaround was broken recently in 2.93 and master, so I added a temporary fix for that. It would have to be reverted once this is supported properly.

Some tips noticed while making this simplified test file:

  • Enabling Library Overridable on the intermediate custom property is not required.
  • The material should be linked to Object rather than Data.

@Alexander Gavrilov (angavrilov) It seems it still is broken in 2.93 beta wether the material is linked to object or data

Taras (tako) rescinded a token.

So to be clear there is currently no workaround to make linked material overrides work in 2.93?

So to be clear there is currently no workaround to make linked material overrides work in 2.93?

Make it link to OBJ and make the material local. Put all the fancy stuff inside a group node.

So to be clear there is currently no workaround to make linked material overrides work in 2.93?

Make it link to OBJ and make the material local. Put all the fancy stuff inside a group node.

It's not very practical for my case unfortunately as it's for assets that will be ultimately exported to gltf (and the exporter doesn't export group nodes). I could workaround it with scripting but haven't come up with an efficient way to achieve that just yet. I think working linked material overrides would be extremely useful for both even for small scale projects.

Yeah it's really a pain. LOs have a long way to go still.

@Alexander Gavrilov (angavrilov) That test is also a bit weird. When i open it in bl.293 and start moving the empty color change works. As soon as i select the cube and then the empty again it stops working.

I noticed it used 2 drivers, 1 custom prop on material named proxy to drive the other. I moved the driver directly to the location of the empty.

However i noticed the driver kept shower part of that proxy when i open driver editor window. When i use edit driver, the small popup does not show proxy.

Something else i noticed is that the driver jumps back to Scripted Expression and doesnt hold its Average Value with is set in the lib.blend file

It also returns an error on opening the file. But as long as the empty is selected it still works. After that i noticed the driver is reset to scripted value and it wont hold anything else, it will keep reverting to scripted value.

WARN (bke.anim_sys): C:\b\buildbot-worker-windows\windows_291\blender.git\source\blender\blenkernel\intern\anim_sys.c:2926 BKE_animsys_eval_driver: invalid driver - (null)[0]

EDIT2
The only way i can keep it work is using "is library overridable" check in that custom prop. I dont see such an option for drivers though when added in a different manner

EDIT3
Though that "is library overridable" does work. On reopening the file, i do need to use resync ovreride each and everytime i open the user.blend file

Well, just commenting that I checked and drivers in materials now seem to work without any workarounds in 3.1 master. I didn't check node groups, those may well still be broken.