It was a missing fcurve evaluation in scene update function which lead to
materials only being updated on frame change.
Added the same exception as we've got for the scene animation. It only
runs when there're materials tagged for the update, so wouldn't expect
speed regressions or so.
Issue was caused by cache limitor removing viewer image buffer
from the memory during compositing. Now made it so all viewer
images are persistent in the memory.
This solves the crash mentioned above and also makes it so
render/compo results are never lost.
Further tweaks are possible, but pretty much happy now, at
least no stoppers for work are there.
Same as mballs and curves it was only to work around DAG stupidness
which hopefully was fixed in one of the previous commits.
From quick tests everything works fine, if something is broken now
poke me to find a proper solution.
There were couple of reasons why it wasn't safe for usage from
multiple threads.
First of all, it was trying to cache BVH in derived mesh, which
wasn't safe because multiple threads might have requested BVH
tree and simultaneous reading and writing to the cache became a
big headache.
Solved this with RW lock so now access to BVH cache is safe.
Another issue is causes by the fact that it's not guaranteed
DM to have vert/edge/face arrays pre-allocated and when one
was calling functions like getVertDataArray() array could
have been allocated and marked as temporary. This is REALLY
bad, because NO ONE is ever allowed to modify data which
doesn't belong to him. This lead to situations when multiple
threads were using BVH tree and they run into race condition
with this temporary allocated arrays.
Now bvhtree owns allocated arrays and keeps track of them, so
no race condition happens with temporary data stored in the
derived mesh. This solved threading issues and likely wouldn't
introduce noticeable slowdown. Even when DM was keeping track
of this arrays, they were re-allocated on every BVH creation
anyway, because those arrays were temporary and were freed
with dm->release() call.
We might re-consider this a bit and make it so BVH trees are
allocated when DM itself is being allocated based on the DAG
layout, but that i'd consider an optimization and not something
we need to do 1st priority.
Fixes crash happening with 05_4g_track.blend from Mango after
the threaded object update landed to master.
Graph traversal which is based on counting parents which are still
to be updated fails in cases there are cycles in the graph.
If there are cyclic dependencies in the scene all the objects from
the cycles will be updated in a single thread now one by one. This
makes blender behave the same way as it was before multi-threaded
DAG landed to master.
This needed to tweak depsgraph a bit so now dag_check_cycle() sets
is_acyclic field of DAG forest if there are cycles in the graph.
TODO: It might be possible to save some time on evaluation when
all the tagged objects were updated in multi-threaded DAG
traversal.
This is a regression since threaded dependency graph landed to master.
Root of the issue goes to the loads of graph preparation being done
even if there's nothing to be updated.
The idea of this change is to use ID type recalc bits to determine
whether there're objects to be updated. Generally speaking, we now
check object and object data datablocks with DAG_id_type_tagged()
and if there's no such IDs tagged we skip the whole task pool creation
and so,
The only difficult aspect was that in some circumstances it was possible
that there are tagged objects but nothing in ID recalc bit fields.
There were several different circumstances when it was possible:
* When one assigns object->recalc flag directly DAG flush didn't
set corresponding bits to ID recalc bits. Partially it is fixed
by making it so flush will set bitfield, but also for object
types there's no reason to assign recalc flag directly. Using
generic DAG_id_type_tag works almost the same fast as direct
assignment, ensures all the bitflags are set properly and for the
long run it seems it's what we would actually want to.
* DAG_on_visible_update() didn't set recalc bits at all.
* Some areas were checking for object->recalc != 0, however it is was
possible that object recalc flag contains PSYS_RECALC_CHILD which
was never cleaned from there.
No idea why would we need to assign such a flag when enabling
scene simplification, this is to be investigated separately.
* It is possible that scene_update_post and frame_update_post handlers
will modify objects. The issue is that DAG_ids_clear_recalc is called
just after callbacks, which leaves objects with recalc flags but no
corresponding bit in ID recalc bitfield. This leads to some kind of
regression when using ID type tag fields to check whether there objects
to be updated internally comparing threaded DAG with legacy one.
For now let's have a workaround which will preserve tag for ID_OB
if there're objects with OB_RECALC_ALL bits. This keeps behavior
unchanged comparing with 2.69 release.
First of all, it was needed to have that set scenes fix which
was done recently so curve is being evaluated properly on file
load.
And last but not least, also needed to tag DAG node to evaluate
path regardless to curve datablock settings so curve length is
always known.
This solves threading conflict which happens when having
multiple objects using Curve Deform modifier with the same
curve datablock. This conflict was caused by the fact that
curve_deform_verts() used to temporary override curve's
flags to make it path is there.
Actually, it was setting CU_FOLLOW flag temporary which
was only used where_on_path() (only in terms that this
temporary assignment only affected this function) but it
is now commented out for a while, so no reason to set
this flag temporary, If it's ever to be done, we'll need
to pass flags as an additional function argument.
For the path creation i've extended DegNode structure
which now holds extra bits which indicates what additional
data depending on the graph topology is to be evaluated.
Currently this is only used to indicate that curve needs
path to be evaluated regardless to cu->flag state. This
is so Curve Deform modifier is always happy.
In the future this flag might also be used to indicate
whether bmesh verts are to update (see recent commit to
3-vertex parent crash fix) or to indicate that the object
is the motherball etc.
This goes back to ancient era again and such a call isn't
safe for threading and really DAG is to make it sure display
list for dependencies is always there.
BKE_curve_bevel_make() is only used from object_handle_update()
friends and never called directly. This means if there's no
display list ready for the bevel object it's something wrong
happened with DAG.
In fact, this check goes back to ancient era and from tests
it appears this check is no longer needed.
It was some kind of workaround for DAG glitch in 2009
(commit hash 8c5c7ebb0) and according to the comment
was needed to make select outline show immediately.
After some tests it appears DAG behaves almost fine now
(just needed to make it so layer is flushed properly to
the set scene) and no reason to have rather confusing
call in the code.
We do keep it when typing an new directory name in the directory text field.
Reviewed By: brecht, billrey
Differential Revision: https://developer.blender.org/D188
It is better to keep the profile as it is perpedicular
to the edge, and then project it onto a given plane
at the corners. Also fixed the interpolation to a
different number of segments when the profile is not
round.
Issue was in GP draw code: line thickness was not initiated properly (and a null one makes OGL draw a unity-width line).
Also tweaked threshold (when to start a new, width-different OGL linestrip), to make it inversaly proportional to thickness
(so that now, it's 0.2 for a thickness of 1, 0.1 for a thickness of 2, etc.), avoids too big steps when using large thickness.
Gives up to 15% speedup scenes with voronoi-based textures (up to 25% with volumes) on Haswell. The performance change for other CPUs is much smaller: 1-2%.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D203
This simply mimics code used for loopnormals, to enable py scripts to generate and access (temporary)
a tangent 3D vector and bitangent sign for each loop. Together with the split normals, this allow
to recreate a complete tangent space for normal mapping (bitangent = bitangent_sign * cross(normal, tangent)).
Expects all faces to be tri or quads.
Reviewed By: Brecht, campbellbarton
Differential Revision: https://developer.blender.org/D185
Sergey Sharybin
Campbell Barton
Andrew Buttery
Marcus von Appen
Antony Riakiotakis
Howard Trickey
Bastien Montagne
Sv. Lockal
Thomas Dinges
Brecht Van Lommel