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... ;)
This is what modifiers are to use to indicate that they depend
on a transformation of the object itself.
Currently should be no functional changes, but in the future
this will allow to easily change transform operation depending
on whether there is a simulation associated with the object.
`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.
Also update relations when modifier texture changes.
Basically same as rB6e00415a85a9, rBca2680aaeb1 but this time for
VertexWeight modifiers
Reviewers: sergey
Maniphest Tasks: T61185
Differential Revision: https://developer.blender.org/D4305
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!
When a modifier depends on some other object's position, then it also
depends in its own position, this has to be also told to depsgraph.
Fixes several modifiers where moving target would update the modifier,
while moving modified object itself would not.
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.
Some notes here:
* Proximity with non-mesh objects (like curve, see TEST_2 scene in
weightvg testfile) are not working currently. This is known TODO of COW
depsgraph project.
* Proximity modifier is slower, due to some other TODO pending on
BVHTree creation/caching for 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
Free code should not handle ID refcounting at all. This has to be done
at higher level, since in some case we want to free (temp) data that
actually did not refcount at all its IDs.
This change seems to be working OK, but as usual in that area, only
lots of testing in real-case situation will say whether there are some
hidden bugs or not.
Solves these security issues from T52924:
CVE-2017-12081
CVE-2017-12082
CVE-2017-12086
CVE-2017-12099
CVE-2017-12100
CVE-2017-12101
CVE-2017-12105
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
