the render branch.
When a material is linked in and has a light group override, this can now use
a local group in the scene file, by replacing the linked light group with a
local group that has the same name. A use case might be controlling the specular
highlight on linked character's eyes per scene.
Patch from render branch by Pablo Vazquez.
Conflicts resolved:
source/blender/blenloader/intern/readfile.c
source/blender/render/intern/source/convertblender.c
source/blender/render/intern/source/pipeline.c
Also addressed code inconsistency due to changes in the trunk revision 50628 (color
management with OCIO) and 50806 (UV project material). OCIO-related changes are marked
OCIO_TODO as in some other files modified in revision 50628.
Shader preview job localizes material without referencing it as a user,
so don't need to unreference itself as a user from this material.
Added BKE_material_free_ex function which could skip user dereferencing.
This also removed old hack with mtex users.
When initially coding this functionality, I was aware of the potential for
infinite recursion here, just not how frequently such setups are actually
used/created out in the wild (nodetree.ma_node -> ma -> ma.nodetree is all too
common, and often even with several levels of indirection!).
However, the best fix for these problems was not immediately clear. Alternatives
considered included...
1) checking for common recursive cases. This was the solution employed for one
of the early patches committed to try and get around this. However, it's all too
easy to defeat these measures (with all the possible combinations of indirection
node groups bring).
2) arbitrarily restricting recursion to only go down 2/3 levels? Has the risk
of missing some deeply chained/nested drivers, but at least we're guaranteed to
not get too bad. (Plus, who creates such setups anyway ;)
*3) using the generic LIB_DOIT flag (check for tagged items and not recurse down
there). Not as future-proof if some new code suddenly decides to start adding
these tags to materials along the way, but is easiest to add, and should be
flexible enough to catch most cases, since we only care that at some point those
drivers will be evaluated if they're attached to stuff we're interested in.
4) introducing a separate flag for Materials indicating they've been checked
already. Similar to 3) and solves the future-proofing, but this leads to...
5) why bother with remembering to clear flags before traversing for drivers to
evaluate, when they should be tagged for evaluation like everything else?
Downside - requires depsgraph refactor so that we can actually track the fact
that there are dependencies to/from the material datablock, and not just to the
object using said material. (i.e. Currently infeasible)
There was some bad recursion introduced recently that caused crashes
when a Material node is the same material as the material itself (e.g.,
if Material.001 has a node with Material.001).
This commit attempt to correct this by keeping track of the material
at the root of the node tree, and doesn't recurse further if it
encounters it again within the nodetree.
Joshua, please review!
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!!!
* Remove all code for Texture and Sequencer plugin system, this never worked in 2.5x / 2.6x and is therefore not needed anymore.
* DNA structures are kept, all read/writefile code is gone.
Conflicts resolved:
source/blender/blenkernel/intern/material.c
source/blender/blenkernel/intern/subsurf_ccg.c
source/blender/blenloader/intern/readfile.c
source/blender/editors/animation/anim_channels_defines.c
source/blender/makesrna/intern/rna_scene.c
Additional changes:
* Fix for recent changes of BKE_* function renaming.
* Fix for an "attempt to free NULL pointer" in BlenderStrokeRenderer::RenderStrokeRepBasic().
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
