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 only using first ID instead of all of them.
Might have been causing issues when updating motion paths of
multiple objects.
Spotted by Jack C, thanks!
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.
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
The `DEG_depsgraph_query.h` file uses the `ITER_BEGIN` and `ITER_END`
macros defined in `BLI_iterator.h` without including that header.
No functional changes.
It is possible to have action which is not nullptr but which have no
f-curves in it (for example, animate cube's location, then delete all
f-curves).
Such situation should not add time dependency as it could slow down
scene evaluation on frame change.
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.
It is not allowed to do tagging or updates while dependency graph is
in the middle of evaluation.
This is something what is simple to violate from python code. This
change adds some sanity checks.
The request to update view layer or dependency graph will raise an
exception in Python now, so it's easy for scripters to notice.
Tagging for update will do silent return unless running with debug
command line argument. This is because it's a bit tricky to know
which exact dependency graph corresponds to a context from which
an update tag was triggered.
Differential Revision: https://developer.blender.org/D6035
This is something which worked in Blender 2.79.
Need to do special trickery to ensure peoxy_from points to a
proper object.
Differential Revision: https://developer.blender.org/D6040
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
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
The idea is to ignore dependency which comes via rigid body solver.
Reviewers: mano-wii
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D5900
The title explains it all actually: this commit introduces special
dependency graph builder API which builds graph which is sufficient
to evaluate given set of IDs.
This change is two-fold:
- Ensure the result of the F-Curve evaluation is stored on the FCurve
object. This was done in 2.79 but lost when we moved to more granular
per-curve evaluation from the depsgraph.
- Flush this result from the CoW copy back to the original.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D5888
time change
followup to 815ca2310f, this one fixes the RNA_MeshLoopColor case, adds
RNA_VertexGroupElement and RNA_LatticePoint.
coop with @sergey, thx.
Fixes T68666
The static mesh issue described in T65816 has been resolved by @Sergey
in T60094.
This commit fixes the last bit of the puzzle, which was two-fold:
- A missing depsgraph update when setting `orig_object.data = new_mesh`
from Python. Thanks @Sergey for providing the fix :)
- Properly locking the interface while exporting. This prevents crashes
as described in T60094. The previous approach of calling
`BKE_spacedata_draw_locks()` was not enough.
This allows accessing it from drivers and using it in UI, as
demonstrated by adding it to the transform panel of 3D View.
As an aside, properly mark transform-related properties of Bone
read-only, as they can only be changed correctly in edit mode.
Allows to access dependency graphs created for render engines
to inform them about changes in .blend file structure from the
Python handlers.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5724
Currently unused, but will allow to keep of an owner of the depsgraph.
Could also simplify other APIs in the future by avoiding to pass bmain
explicitly to relation update functions and things like that.
This partially reverts commit 0b2d1badec
Post increment can deep-copy for C++ iterators, while in my own checks
GCC was able to optimize this to get the same output,
better follow C++ best practice and use pre-increment for iterators.
