It was a regression since 5d49eff. Not really sure about proper solution
here, so used a bit workaround-ish way for now.
Hopefully new cloth will be landed after this GSoC anyway.
Own regression since e08db08. CustomData_copy_data() would fail in cases
when mvert/medge/mloop/mpoly arrays were lazy allocated since that change.
Now made it so this layers are copying from own copy of the arrays.
Not sure if this still misses some CD to be copied, from quick glance
seems no, but some further testing wouldn't hurt at all.
The issue was caused by the temporary CD layers being allocated for subsurf
meshes, same as we've got back in 881fb43.
In the long run this temporary storage is to be re-considered, but it'll also
imply re-considering of the Derivedmesh interaction as well. For now let's
use a simpler solution which is forbidding modifiers to call getArray for other
objects' derivedMeshes but use an API calls which would allocate local copy of
the data preventing race condition of shared data in DM.
For now disable using linked edit mesh in the meshdeform modifier.
This is because editbmesh_get_derived_cage_and_final() might easily
conflict with the thread which evaluates object which is in the edit
mode for this mesh.
We'll support this case once granular dependency graph is landed.
* Merely a re-implementation of core split algorithm for BMesh, taking advantage of topological data available.
* This code needs valid loop indices, so added BM_LOOP support to BM_mesh_elem_index_ensure() & co.
Reviewers: campbellbarton
Reviewed By: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D366
We can't simply dupalloc cache_system (LaplacianSystem), it has quite a few allocated data we'd need to dupalloc as well,
not to mention (nl) context... Much safer to just set it to NULL in new copy imho!
This commit is to be backported to 2.70 release!
Issue was caused by undefined object update order and in some
cases NULL pointer will be de-referenced.
Added on-demand curve path calculation, just the same creepy call
of BKE_displist_make_curveTypes(). This violates DAG and might
end up in a difficult to troubleshoot race condition if there'll
be some issues with how dependencies are calculated in DAG, but
this is the easiest and safest way to solve the bug at this stage,
Goal of this commit is to support NGons for boolean modifier
(currently mesh is being tessellated before performing boolean
operation) and also solve the limitation of loosing edge custom
data layers after boolean operation is performed.
Main idea is to make it so boolean modifier uses Carve library
directly via it's C-API, avoiding BSP intermediate level which
was doubling amount of memory needed for the operation and which
also used quite reasonable amount of overhead time.
Perhaps memory usage and CPU usage are the same after all the
features are implemented but we've got support now:
- ORIGINDEX for all the geometry
- Interpolation of edge custom data (seams, crease)
- NGons support
Triangulation rule is changed now as well, so now non-flat
polygons are not being merged back after Carve work. This is
so because it's not so trivial to support for NGons and
having different behavior for quads and NGons is even more
creepy.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D274
Bevel needs the vertex normals to be correct and they are not
normally recalculated after a previous modifier, like mirror.
Adding 'dependsOnNormals' -> returns true to modifier info
for Bevel fixes the problem.
The laplacian modifiers (smooth and deform) use the OpenNL library,
which is not threadsafe due to the use of a global context variable.
Ideally this would be changed so that an explicit context can be
created for every caller of the OpenNL functions, but since OpenNL's
most recent version is from 2010 this is unlikely to happen.
As a workaround for now just use a mutex to prevent conflicting OpenNL
calls. Eventually OpenNL can be replaced by eigen or ceres.
Until now, the "vertex group" limit method in the modifier
only worked for "vertex only" bevels. With this change,
edges with both ends in a vertex group will be beveled
in the non-"vertex only" case.
Also changed the test for being in a vertex group from
"any nonzero weight" to "weight >= 0.5". This is because
cascaded bevels on disjoint vertex groups did not give
disjoint bevels, because weight interpolation would give
non-zero weights to newly created vertices in earlier bevels.
Chose 0.5 because that won't result from interpolation, but
still allows some dilution (e.g., cascaded bevels on the
same vertex group).
This commit introduces the ability to make the Build Modifier operate in reverse,
essentially allowing it to be used as a "deconstruction" effect.
(See D219 for more details about use cases for this)
Issue was caused by solidify modifier using original vertices bitfield
to store tags. This isn't thread-safe obviously. Now use bitmap to store
needed tags.
Reviewed by Campbell, thanks!
