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!
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
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
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.
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
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.
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.
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
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.
This is more like a band-aid than a real fix actually, real fix would be
to understand why rendering smoke requires auto texspace to be ON
(afaict, this was not the case in 2.7x)...
But I've already spent way too much time on this issue, at least now we
get better situation than before (i.e. smoke with adaptive domain works
well even when orig domain mesh has autospace flag disabled).
We should *never* prevent copying basic mesh CDLayers (vertices etc.),
that does not make sense.
I guess issue was not in old DM because geometry was duplicated anyway,
and in 'normal' modifier stack eval, probably because bare mesh was
awlays requested? But we should not have to be explicit here about it.
