Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoshua Leung <aligorith@gmail.com>2012-07-22 20:14:57 +0400
committerJoshua Leung <aligorith@gmail.com>2012-07-22 20:14:57 +0400
commite58104c515b5ab7f16f103518a1d8b28bc64dc63 (patch)
treef0bd99b69e462c3e82b401b4d69ac6fceae00c1a /source/blender/blenkernel/intern/scene.c
parentdae8e9fbb2a19d35e5074e3ee161a3b3111792a0 (diff)
Bugfix [#32017] Infinite recursion in depsgraph material/node driver handling
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)
Diffstat (limited to 'source/blender/blenkernel/intern/scene.c')
-rw-r--r--source/blender/blenkernel/intern/scene.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/source/blender/blenkernel/intern/scene.c b/source/blender/blenkernel/intern/scene.c
index d9afd1eefb4..185bee86f69 100644
--- a/source/blender/blenkernel/intern/scene.c
+++ b/source/blender/blenkernel/intern/scene.c
@@ -1018,6 +1018,11 @@ void BKE_scene_update_tagged(Main *bmain, Scene *scene)
DAG_ids_flush_tagged(bmain);
scene->physics_settings.quick_cache_step = 0;
+
+ /* clear "LIB_DOIT" flag from all materials, to prevent infinite recursion problems later
+ * when trying to find materials with drivers that need evaluating [#32017]
+ */
+ tag_main_idcode(bmain, ID_MA, FALSE);
/* update all objects: drivers, matrices, displists, etc. flags set
* by depgraph or manual, no layer check here, gets correct flushed