This is something where there is no single correct behavior,
sometimes it's needed to ignore the crease to make mesh more
smooth. But sometimes crease is to be considered after first
subdivision surface: for example, when adding extra subdivisions
for render-time displacement.
Made it an option whether modifier needs to take crease into
account or not.
Existing files should be openable in the 2.7 compatible way,
to re-create an old behavior the options is to be manually
disabled in the modifier settings.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4652
A regression since 64c8d72ef1.
The solution is to force modifier evaluation for an evaluated
object, and let it to copy binding data back to original when
is being evaluated for binding.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4642
Missing dependency, which made collission to access object transform
prior it was evaluated.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4636
Allows to preserve topology cache even when copy-on-write is
fully re-copying the object. For example, toggling edit mode
in and out does no longer causes full topology to be re-created.
This was wrong and violating design to force modifiers to query
evaluated objects and IDs. It is up to the caller to make sure
the object is properly evaluatable.
Effectively, reverting changes from de491abf99 (and possibly
other related changes).
BKE_mesh_new_nomain automatically added a CD_ORIGINDEX layer initialized to 0,
which was never filled in correctly. In 2.7 the equivalent function used to
modify the source derivedmesh and add valid original indices to it, but this
is no longer possible in the new design and was quite unpredictable anyway.
Now instead rely on mesh_calc_modifiers and the depsgraph to determine when
CD_ORIGINDEX should be added.
The issue was caused by mesh needed for dynamic paint brush being
stored in the modifier. That make it to be freed and set to NULL
when running copy-on-write.
Solved by moving the mesh to be stored in modifier's runtime data.
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
Stupid mistake in previous 'fixing' commit, I put the call computing
extra required source cddata masks into the callback used to get
destination (current object) cddata masks...
Source (i.e. other) mesh should not be modified in any case in modifier
evaluation case (this is forbidden by design and can lead to all kind of
threaded locks and crashes), and doing so even in operator case was
never a good idea either.
Now that we can specifically request needed data (poly and/or loop
normals) from evaluation code, we can finally get rid of those
computations inside data transfer/mesh remapping area.
This is hopefully the last remaining bit of this 'bad crashing code' in
datatransfer area.
The SubdivCCG structure was re-allocated, but the cached one in
the sculpt session was still pointing to an original one.
This is rather a workaround, but is least evil from what i can
currently think. Remember something similar was also required in
2.7 as well.
Definitely need to revision this change.
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
Now it will be simpler for code jsut wanting to preserve custom normals
around to set them, without having to add same boiler plate code all the
time around actual code.
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?
Not a bug, but supporting preservation of custom normals in that
specific modifier makes sense, in game pipeline contexts.
Could also ease work of IO add-ons that want to export
triangulated geometry...
In Blender face is for tesselated faces, that kind of miss-naming is a
pretty good way to shoot yourself in the foot at some point or another
(see T61979)...
Broken logic in rB181356edba04, thanks most likely to stupid naming
(face in Blender is for tessellated faces, use poly for BMesh polygons).
Cleanup to follow in next commit...
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 commit makes it so both Subdivision Surface and Multiresolution
modifiers are caching OpenSubdiv topology. This cuts down evaluation
time quite a bit, especially for meshes which don't have many extra
ordinary verticies.
Only working for animation. Other modifications like edit mode needs
more work to make topology cache preserved by copy-on-write.
Make Difference a default value for boolean modifier operation property.
Currently operation property of the boolean modifier is set to Intersect, which is the least frequently used boolean operation of the three available. It is also goes out of sync with Intersect (Boolean) tool, where Difference is a default operation.
Reviewers: mont29, brecht, sergey
Reviewed By: mont29, brecht, sergey
Subscribers: mont29, brecht, campbellbarton, sergey, billreynish
Tags: #modifiers
Differential Revision: https://developer.blender.org/D4340
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.
There is an issue of hair being completely messed up when
switching to a simulation view layer for Autumn.
Restoring back the code which was re-setting particles on
file load. This will re-set unbacked particles on file load
but this appears to be happening in 2.7 as well.
Can not reproduce bugs which were fixed in this area recently,
so maybe it's finally tackled (fingers crossed!).
`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
Fix T61289: Emitting particles from instances not working properly
The first issue has been re-introduced by a code which was dealing
with missing hair after opening the file. That was re-setting all
particle systems all the time because modifier flags were not copied
back to original. This made every modifier run to be seem as an
initial file open.
Now we copy flags back to an original modifier. But also we are
trying to not do any resets unless needed in that case. This way
we can preserve in-memory caches.
Other part of the change is related on re-setting particle system
if number of mesh elements changed. But we only do it if the
modifier has been already evaluated once.
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.
Was happening due to missing relation from geometry to
transform component. Did not happen in old dependency
graph because that one could never evaluate geometry
prior to transform.
