Page MenuHome

Scripted driver expressions not working in material nodes
Closed, ArchivedPublic

Description

System Information
OS X 10.10.1
ATI Radeon HD 4850 512 MB

Blender Version
Broken: 2.76 48f7dd6
Worked: unknown

Short description of error
Scripted driver expressions can be used to animate objects in various ways, but they do not work for material node values.

For example, we can make an object rotate back and forth using the expression: #cos(frame*pi/30)
but we can't use such an expression to make a pulsating glow on a material by using that same expression on an Emission Shader's strength.

To use a simpler example, we can use the single-variable expression #frame to increment some value each frame. It doesn't really matter what the expression is - driver expressions aren't working in material nodes.

They are working in compositing nodes, from what I have observed.

Exact steps for others to reproduce the error

  1. Create an object and a material for it.
  2. In one of the material's nodes (for example an Emission Shader's strength) type in a scripted expression as the value. ("#frame" will do)
  3. Play the animation and see that it doesn't work.

Here is a .blend where the object is animating just fine, but the material is not animating even though the same expression is being used. There is no change in the render, and the node's value does not change as animation is played. The emission strength value remains at -0.5 no matter what expression is inserted. (Before saving the file it showed as the default 1, but after saving and re-loading it shows as -0.5)

Details

Type
Bug

Event Timeline

Seth L. (quantumanomaly) set Type to Bug.
Seth L. (quantumanomaly) created this task.
Seth L. (quantumanomaly) raised the priority of this task from to Needs Triage by Developer.
Sergey Sharybin (sergey) closed this task as Archived.
Sergey Sharybin (sergey) claimed this task.

This is limitation of old dependency graph. unfortunately, which isn't really easy to solve without doing extra drivers recalculations which will slow things down. This is supported in the new dependency graph so it makes sense to invest time in finishing new depsgraph rather than trying to stretch old one even further.

Thanks for the report, but closing it now.

Got it - thank you for the explanation! Looking forward to when this becomes possible. :-)