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
Currently modifier stack assumes there are no poly normals data passed
around, so in case a modifier generates such data, it has to clean it up
after usage.
Whole handling of normals is a bit annoying and week currently, we can
probably enhance that once fully per-mesh item type cddata masks are in?
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... ;)
Turns out most of our 'local working copy' cases can use same set of
flags.
Note that this commit adds LIB_ID_COPY_CACHES to all our local meshes
copying, however this is no-op since that flag is unused during mesh
copying... We may want to add another set of flags without that one at
some point, but for now it would not be useful imho.
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.