The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
It's cause by degenerate triangle having normals set to (0,0,0) which may not be compressed like it should.
This fix the problem in the final indirect lighting evaluation which might be costly.
The issue was caused by updates being flushed for all scenes, while actual update
was only called for an active one.
Not sure why do we need to flush updates for all scenes, so now we only flush
scenes which are updated.
New dependency graph is tacking root bone into account when building the graph.
This is required in order to get proper dependencies between bones. so we can
reliably use bones as targets from the same rig (and even indirect relations
via external objects). This forces us to tag relations for update when we change
root IK chain bone.
Since relations rebuild is not fully trivial operation, we only do it for
the new dependency graph. In the future it'll be nice to avoid whole graph
rebuild for such cases, but that's mentioned as a TODO.
This situation happens when a file with a text effect sequencer strip is
loaded in Blender < 2.76 and saved. This destroys the effect data, causing
a crash in Blender ≥ 2.76.
d2f748a222 prevented the crash when opening such a file, but accessing
the strip still caused a crash. This commit fixes that by actually
initialising the invalid strip. Of course this still causes data loss, but
that already happened by opening & overwriting the file in Blender < 2.76.
This makes no sense to add theses. In cycles, each volume node is computed separatly. In eevee only the combined parameters are evaluated and phase should be averaged in this case.
Using an arbitrary face as the source of the UV data is mostly fine, as
vertices on seams will generally map to different parts of the texture
that have the same color.
This is regarding fed853ea78
Clearing of custom bones outline's line thickness was not done at proper
point, wireframe drawing never changes line thickness, only solid draw
with outline does...
Last fix only accounted for direct changes to the RB settings, but
failed for, say, object transformations. This fix accounts for any
change that might invalidate the RB cache.
