c960d1692f
Until now, there was never any code for making drivers on materials get recalculated when their dependencies were changed. However, since changing material colors with drivers is something that is quite common, a workaround was introduced to ensure that materials could still be driven (albeit with the relevant drivers rooted at object level). This worked well enough so far with traditional materials - though it was sometimes clunky and confusing for some users - and would have been ok to tide us over until the depsgraph refactor. The introduction of Cycles changed this, as it has in many other ways. Now that people use Cycles to render, they'll need to drive the material colors through the nested nodetree (and other things nested deeply within that). However, this is much more difficult to generate hacks to create the relevant paths needed to work around the problem. == This Commit... == * Adds a recursive driver calculation step to the BKE_object_handle_update() (which gets called whenever the depsgraph has finished tagging object datablocks for updates), which goes through calculating the drivers attached to the object (and the materials/nodetrees attached to that). This case gets handled everytime the object is tagged as needing updates to its "data" (OB_RECALC_DATA) * When building the depsgraph, every dependency that the drivers there have are treated as if they were attached to object.data instead. This should trick the depsgraph into tagging OB_RECALC_DATA to force recalculation of drivers, at the expense perhaps of modifiers getting recalculated again. == Todo == * The old workarounds noted are still in place (will be commented out in the next commit). This fix renders at least the material case redundant, although the textures case still needs a bit more work. * Check on whether similar hacks can be done for other datablock combinations * So far, only simple test cases have been tested. There is probably some performance penalty for heavy setups still (due to need to traverse down all parts of material/node hierarchy to find things that need updates). If there really is a problem here, we could try introducing some tags to limit this traversal (which get added at depsgraph build time). <--- USER TESTING NEEDED!!! |
||
|---|---|---|
| build_files | ||
| doc | ||
| extern | ||
| intern | ||
| release | ||
| source | ||
| CMakeLists.txt | ||
| COPYING | ||
| GNUmakefile | ||
| SConstruct | ||