This is a continuation of rB39f005eae8eed8b939579aff8c9a05a4f50e5e38
Now all the fields where we check for object type in RNA (like
rna_Curve_object_poll) will have a safe guard for when this isn't the
case. For example when loading files that has missing object libraries
and all missing objects are replaced with empties (placeholders).
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5425
A regression since 64c8d72ef1.
The solution is to force modifier evaluation for an evaluated
object, and let it to copy binding data back to original when
is being evaluated for binding.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4642
This was wrong and violating design to force modifiers to query
evaluated objects and IDs. It is up to the caller to make sure
the object is properly evaluatable.
Effectively, reverting changes from de491abf99 (and possibly
other related changes).
The general idea of this change is to have a runtime data pointer
in the ModifierData, so it can be preserved through copy-on-write
updates by the dependency graph.
This is where subdivision surface modifier can store its topology
cache, so it is not getting trashed on every copy-on-write which
is happening when moving a vertex.
Similar mechanism should be used by multiresolution, dynamic paint
and some other modifiers which cache evaluated data.
This fixes T61746.
Thing to keep in mind, that there are more reports about slow
subdivision surface in the tracker, but that boils down to the
fact that those have a lot of extraordinary vertices, and hence
a lot slower to evaluated topology.
Other thing is, this speeds up oeprations which doesn't change
topology (i.e. moving vertices).
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T61746
Differential Revision: https://developer.blender.org/D4541
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
BLI should always comes first, before DNA, BKE etc. And
`BLI_utildefines.h` should come before any other BLI (since it's some
sort of system include really, among other things...).
Thisi should help to reduce the noise in patches when adding stuff
like uint64_t members to DNA structs... ;)
`BKE_modifier_get_evaluated_mesh_from_evaluated_object()` used by
modifiers needing access to other objects' geometry probably skipped out
of the radar when cage and final evaluated meshes were added to
BMEditMesh? In any case, we do not need to duplicate (and then free!) a
temp mesh from editdata anymore, and we can even add instead a parameter
to get cage instead of final. Also makes modifiers code a bit simpler.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Fix T58237: Exporters: Curve Modifier not applied when "apply modifiers" are selected.
Fix T58856: Python: "to_mesh" broken in 2.8.
...And many other cases... ;)
Thing is, we need target IDs to always be evaluated ones (at least I
cannot see any case where having orig ones is desired effect here).
Depsgraph/Cow system ensures us that when modifiers are evaluated by it,
but they can also be called outside of this context, e.g. when doing
binding, or object conversion...
So we need to ensure in modifiers code that we actually are always
working with eval data for those targets.
Note that I did not touch to physics modifiers, those are a bit touchy
and rather not 'fix' something there until proven broken!
We had two different ways of doing it, SurfaceDeform and LaplacianDeform
would do it through a special modifier stack evaluation triggered from
binding operator, while MeshDeform would do it through a regular
depsgraph update/eval (also triggered from its binding op).
This enforces the later to search back for orig modifier data inside
modifier code (to apply binding on that one, and not on useless CoW
one).
Besides the question of safety about modifying orig data from threaded
despgraph (that was *probably* OK, but think it's bad idea in general),
it's much better to have a common way of doing that kind of things.
For now it remains rather dodgy, but at least it's reasonably consistent
and safe now.
This commit also fixes a potential memleak from binding process of
MeshDeform, and does some general cleanup a bit.
This fixes/clarifies Surface Deform evaluation code that does the
binding, since that part should only be called outside of depsgraph
evaluation, with orig data-blocks and not CoW ones.
Now we have a decent amount of asserts and checks to ensure eveything
works as expected.
Also had to add a special case to get target's mesh in binding case,
since often target's evaluated mesh is not available, in that case (and
in that case only), we can actually compute that mesh (because we are
out of depsgraph evaluation).
Modifiers stack only get COW/evaluated IDs, so no need to go auery again
DEG for those. Further more, now unified handling of EditBMesh case (was
done on case-by-case basis in a few modifiers, not all for some reason).
We are still missing the ability to get final and cage deformed meshes
when in Edit mode though, this is to be defined/implemented in depsgraph.
This fix applying the following modifiers:
* Boolean (working already)
* Array
* Mesh Deform
* Surface Deform
* Vertex Weight Proximity
This function was to return evaluated mesh. So it should get the evaluated
object at all times. So in this case it makes more sense to simply pass the
depsgraph (or in this case the ModifierEvalContext that contains both the
depsgraph and the flag.
Solution discussed with Bastien Montagne.
The modifier performed the 'bind' operation not in the bind operator,
but delayed in the mesh evaluation. This saved the result in a CoW copy
instead of in the actual modifier data. The binding operator now follows
the same approach as Mesh Deform: it forces the modifiers to run on the
real (non-CoW) data, making it possible for the modifier to store the
binding data.
This commit also ports the usage of DerivedMesh to Mesh.
The contents of the ModifierEvalContext struct are constant while iterating
over the modifier stack. The struct thus should be only created once, outside
any loop over the modifiers.
Makes the follow changes:
- Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers.
- Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary
- Update the rest of Blender to be aware and make use of these new functions
The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed.
Reviewers: campbellbarton, sergey, mont29
Subscribers: sybren
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3155
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
