Age | Commit message (Collapse) | Author |
|
Was only used by subsurf in the past years, it is unlikely
other modifiers will every need this any time soon.
|
|
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/collision.c
|
|
Differential Revision: https://developer.blender.org/D3668
|
|
Also, fix missing cleanup of Object.runtime when copying Object
datablocks!
|
|
|
|
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.
|
|
|
|
|
|
Because some modifiers' actual code is in BKE... Also renamed to more
BKE-valid name BKE_modifier_get_evaluated_mesh_from_object.
|
|
Rename only.
|
|
|
|
This also changes signature of modifier copy callback, first (source)
parameter is now a const, which is saner anyway!
|
|
|
|
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
|
|
|
|
Found by Dr. Sybren while working on modifiers port.
|
|
|
|
|
|
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
|
|
|
|
Vertex group remapping utility function,
now shared between object join and array modifier cap-ends.
Weights which don't exist are removed.
D3092 by @Foaly
|
|
|
|
Makes it easier to add or remove fields needed to update relations.
|
|
|
|
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
|
|
|
|
D2912 by @Zuorion
|
|
This was dangerous to do such calculations, and now it is solvable by making
dependency graph more granular in this case. Removing the workaround also saves
us a hassle of passing lots of extra arguments down the evaluation routines.
In theory, we can also remove EvaluationCOntext from constraints evaluation as
well now. But probably better to wait with such removal for now.
This commit effectively reverts 1130c53. Will do a proper fix in dependency
graph itself.
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
This way the code is more decoupled from the way where depsgraph is stored.
|
|
|
|
Was looping three times over the source mesh's vertices to get min/max
along all three axes... Nothing critical, but still!
|
|
|
|
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/depsgraph.c
source/blender/blenkernel/intern/library_query.c
|
|
Better to have clear way to tell whether flag is parameter for
BKE_library_foreach_ID_link(), parameter for its callback function, or
return value from this callback function.
|
|
|
|
|
|
|
|
leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
|
|
|
|
since some IDs (objects) are not 'refcounted' while others (textures) are...
Partial merge from id-remap branch.
|