| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Was introduced earlier today and did not turn out to be very useful
and clear.
|
|
The code would have break the first (deform only) modifiers
once the index is reached, but it will not prevent second
loop (over remaining modifiers) from run.
This was applying deform modifier twice in some conditions:
having single deform modifier and calculating deformed mesh
up to the first modifier (index=0).
|
|
Intention is to be used to create mesh at the state which is an input
to the multires modifier.
|
|
Make it obvious that this relates to being in sculpt mode.
ref T74489
Maniphest Tasks: T74489
Differential Revision: https://developer.blender.org/D7044
|
|
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
|
|
than mesh"
This reverts commit f2b95b9eae2ee913c99cff7595527b18d8b49d0a.
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
|
|
|
|
|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
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.
|
|
This code has been moved into the draw manager.
|
|
|
|
This is a workaround for T58473 to avoid likely event of ruining
sculpted data.
Differential Revision: https://developer.blender.org/D6244
|
|
The root of the issue goes to the discontinuity between the way how
mesh_calc_modifiers() and BKE_sculpt_multires_active() works.
At some point detection of original data usage by a modifier got
broken: the mesh_final based check is unreliable because deform-only
modifiers will create mesh_final for the connectivity information.
This made it so modifier stack evaluation would skip multires
evaluation, but the sculpt code will assume the multires is properly
applied.
This change makes it an explicit check about whether there are any
non-deform-only modifiers applied.
Pair programming and review together with Bastien, thanks!
|
|
There was a discontinuity between how deform-only modifiers are applied
for the case when result deform mesh is requested and when it is not.
Namely, the input mesh will always be guaranteed to present in the
former case, but not in the latter.
This change makes it so input mesh to deform-only modifiers is always
at consistent state.
Pair programming and review together with Bastien, thanks!
|
|
This way it might be used for sanity checks in RNA API as well.
|
|
Modifier stack evaluation would copy mesh settings other than mesh topology
automatically, outside of the individual modifier evaluation. This leads to hard
to understand code, and makes it unclear which settings are available in following
modifiers, and which only after the entire stack is evaluated.
Now every modifier is responsible to ensure the mesh it outputs preserves materials,
texture space and other settings, or alters them as needed.
Fixes T64739: incorrect texture space for various modifiers
Differential Revision: https://developer.blender.org/D5808
|
|
space issues"
This reverts commit e7a514369fe700dcc5a1fe433c8f709ed9595ded, it introduces
a bug in selection in edit mode.
Fixes T70103: can't select extruded Vertex
Ref T64739
|
|
Modifier stack evaluation would copy mesh settings other than mesh topology
automatically, outside of the individual modifier evaluation. This leads to hard
to understand code, and makes it unclear which settings are available in following
modifiers, and which only after the entire stack is evaluated.
Now every modifier is responsible to ensure the mesh it outputs preserves materials,
texture space and other settings, or alters them as needed.
Fixes T64739: incorrect texture space for various modifiers
Differential Revision: https://developer.blender.org/D5808
|
|
|
|
This also splits vertex access and allocation so it's possible
to copy coordinates into an existing array without allocating it.
|
|
|
|
enabled.
Code in modifier stack ensuring requested CDLayers are provided was not
working very well for polynors in several cases:
* We cannot share the orig mesh if we have to generate pnors/lnors;
* Generating pnors without lnors was not possible.
|
|
This saves memory and evaluation time for simple static meshes with e.g. a
subdivision surface modifier. If no CD_ORCO layer exists then we assume the
actual vertex coordinates are equal to the original undeformed coordinates.
|
|
|
|
|
|
This restores the code that updates the sculpt session and PBVH from dependency
graph evaluation.
|
|
Was happening when modifier stack detected that mesh is not deformed
and is not modified and attempted to share result across multiple
objects.
This was introduced in 2f77119.
Now functions which are supposed to return mesh owned by caller will
do so again. Shouldn't be a huge impact on memory print since the
data layers are referenced.
|
|
The idea is to share a mesh data-block as a result across all objects
which are sharing same original mesh and have no effective modifiers.
This mesh is owned by an original copy-on-written version of object data.
Tricky part is to make sure it is only initialized once, and currently a
silly mutex lock is used. In practice it only locks if the mesh is not
already there.
As an extra bonus, even viewport memory is also lower after this change.
Reviewers: brecht, mont29
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D4954
|
|
Fixes T65165: Weights are not displayed in "Weight Paint" with modifiers
|
|
Evaluation must never go to original objects and query them:
this is a huge violation of the entire idea of separating
state across viewports and render engines.
Allowed this to only happen for active dependency graph, where
we at least know order of dependency graph update and user
input.
|
|
|
|
Logic about computing of poly normals in final stage of modifier stack
evaluation was broken, giving also wrong loop normals.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Causes clang-format to give different results on a second run.
|
|
|
|
|
|
|
|
|
|
|
|
modifier.
A deform-only modifier that needs access to normals need a copy of
evaluated mesh with those normals updated, when it is not the first one
in the stack.
That issue had been partially fixed in Object mode a long time ago
(see T23673), but it was still broken for deform-only stacks cases.
And it was also completely missing from the Edit mode code
(`editbmesh_calc_modifiers()` function).
|
|
Use the term "AFTER" instead of "OFS" since it wasn't obvious these
macros operate on everything after the struct member passed.
Avoid casting to non-const types when only reading.
|
|
|
|
Ensure we do get poly normals if they are requested in given cddata mask.
|
|
This also fixes T62228.
However, datatransfer code is still doing bad things with its source,
still working on proper changes here.
|
|
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
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
