This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
This previously caused a bug in T74283, that should be fixed now.
Differential Revision: https://developer.blender.org/D6695
This reverts commit f2b95b9eae.
Fix T74283: modifier display lost when moving object in edit mode.
The cause is not immediately obvious so better to revert and look at this
carefully.
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
Differential Revision: https://developer.blender.org/D6695
Using a struct here allows to change given parameters to the callbacks
without having to edit all callbacks functions, which is always noisy
and time consuming.
The FPS here is measured based on a timestamp from when depsgraph
was previously evaluated.
Allows to ease investigating performance improvements/regressions
which are not related on animation system but on modifications on
a single frame (such as transforming vertex in edit mode).
FreeStyle line styles were not part of the dependency graph, and
blacklisted from the Copy-on-Write system. As a result, animated
FreeStyle properties would not be updated by the animation system,
resulting in T72213. There was an explicit call to run the animation
system on the original datablocks, but that was (for good reasons)
removed in D5394.
This commit adds the FreeStyleLineStyle datablocks to the dependency
graph and allows them to be handled by the CoW system. As a result
- the UI now updates properly when properties are animated, and
- animated property values are actually used when rendering.
This commit includes @Sergey's patch P1222, which unifies two bits of
code that did the same thing: check whether datablock type is covered by
copy-on-write.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D6609
Was caused by recent animation backup added to depsgraph as a part of
another bugfix.
This commit effectively disables the animation backup, restoring bug
related on handlers, but makes it possible to interact with objects
again.
Will re-iterate over handlers+animated properties.
It was possible to have object copy-on-write happening during
action's copy-on-write, which was causing access to a freed
memory from animation backup.
Solves crash reported in T73029.
The issue was caused by special handling of animation update after
manual edits in frame_post handler: to avid loss of manual edits
done on top of animated property. This was done as a separate pass
for non-animation update after frame_post did modifications.
This caused some other side-effect: non-modified animated property
was re-setting to the value which is used in the viewport.
Idea of this solution is simple: preserve values which came from
animation update through copy-on-write process. The actual process
of this is a bit involved: need to decode RNA path and do it twice
since f-curve might point to a sub-data which pointer will change.
Since this is only done for non-active depsgraph (aka depsgraph
used for render pipeline) this is probably fine since all this
extra overhead is just a fraction of overall render process.
Differential Revision: https://developer.blender.org/D6330
This commit restores old metaball workaround which was forcing their
update from a single thread.
The root of the issue comes to the fact that metaball evaluation needs
to access metaballs from duplilists, so they are properly polygonized
with corresponding motherball which is outside of duplilist.
In a more ideal world this will be implemented in a way that will not
require iterating over all duplilists, but only through the ones which
actually contain metaballs for the given motherball. In practice this
ends up in a huge refactor in both relations builder (which meeds to
see whether there are metaballs in duplilists without actually
creating duplilist as it can not be done prior scene is evaluated)
and in metaballs area which need to use new relations information.
Additionally, metaball evaluation must become thread-safe, which is
currently not a case with dupli-object matrices. There might be issues
deeper in polygonization code which I am not aware of.
Having this forced single-thread evaluation is same as Blender 2.79
was doing.
Think it's better to have slower but simpler solution than to invest
time in refactoring area which requires deeper design changes.
Reviewed By: dfelinto
Differential Revision: https://developer.blender.org/D6539
Remove this pointer since it's linking Mesh data back to the object,
where a single edit-mesh may have multiple object users,
causing incorrect assumptions in the code.
Resolves dangling pointer part of the T72667 crash,
although there are other issues which still need to be fixed.
In EDBM_op_finish and EDBM_update_generic,
full Main lookups have been added which should be replaced with mesh
argument or the update tagging moved elsewhere.
Was caused by 6183688c35 (thanks ronsn for nailing it down!).
The issue is that order of copy-on-write operations is not defined, so
can not use flags set by that operation to make decision.
Was cause by recent fix for T65134 which assigned original object's
proxy_from to an evaluated pointer.
This is because motion path depsgraph does not include proxies, so
the pointer in an evaluated object was kept pointing to an original
object.
Found this while looking into T70463, solves the high spinning times
mentioned in T70463#791026.
Sounds logical that iterating over an array to modify a single property
is faster than doing it in threads. But strangely, doing it for both
nodes and its components is still faster in threads here.
Gives extra speedup with a file mentioned in the report.
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D6017
Evaluation is not entirely cheap even in the case when there is nothing tagged
in the scene. This is because of all the calculation of pending operations,
cleating runtime flags and so on.
This commit makes it so time operation is tagged for update prior to early exit
check. Improves playback speed in a scene without anything animated.
Maniphest Tasks: T70463
Differential Revision: https://developer.blender.org/D6002
Current frame is stored in a scene, and scene might have multiple view
layers. The inactive view layers were not informed about scene's frame
being changed, so when user switched back to view after changing scene
frame it was in an inconsistent state between current scene frame and
animation.
Now we tag scene for time changes, so dependency graph can catch up
and do proper update.
Currently tagging is from quite generic place. Probably better approach
would be to tag from where frame is actually being assigned. Downside
of this is that it's easy to miss some places.
Reviewers: brecht, mont29
Reviewed By: brecht
Maniphest Tasks: T66378
Differential Revision: https://developer.blender.org/D5332
The issue was caused by modifications to planar track tagging clip for
copy-on-write, which was invalidating its cache and forcing current
frame in 3D viewport to be re-load.
Ideal solution would be to share movie cache across original and
evaluated movie clips which will reduce memory usage. However, doing
such ownership changes so close to the code freeze is not something
comfortable to do.
Make sure particle system edit never points to a modifier or particle system
which becomes inactive.
This is needed because copy-on-write will change pointers of them and those
pointers are supposed to be restored from particle system evaluation. But
since the particle system is disabled it never updates pointers.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5180
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
This change makes it so sound handles are created for evaluated scene,
sequencer and speakers. This allows to have properly evaluated animation
on them.
For the viewport playback sound uses regular dependency graph.
For the final render sound uses dependency graph created for render pipeline,
which now also contains sequencer and sound datablocks.
All the direct sound update calls are replaced with corresponding dependency
graph recalc tag.
This is how it worked in 2.79 and it is how it is expected to be working.
Avoids unintended icons update during animation playback.
Fixes T64318: Update of material icons during animation 2x performance penalty
Tagging original ID introduces a conflict of interest when a separate
graph is created and is tagging objects to be re-evaluated with its
context.
This is part of the problem in T63111: tags within a temporary dependency
graph affects viewport and vice versa, which makes logic to wrongly
consider that something did change in the scene and that baking is to
be redone.
This effectively reverts db3bfd0, but this time everything seems to
be updating fine in the viewport.
This change makes it so a minimal dependency graph which only includes
compositor and sequencer is built for the render pipeline purposes.
Tricky part here is that it's only compositor itself and sequencer who
to use this dependency graph and IDs from it. Render engines are still
to be provided original IDs because:
- They will create dependency graph for the given scene, and currently
it is not possible to create dependency graph from CoW scene.
- IDs from the compositor/sequencer dependency graph are "stripped",
as in, they wouldn't have all view layers, collections or objects
required for proper final render.
This creates annoying mess of mixing evaluated and original scene
access in various parts of the pipeline.
Fixes T63927: Compositing nodes - drivers don't really work
Reviewers: brecht
Maniphest Tasks: T63927
Differential Revision: https://developer.blender.org/D4911
