Now the bevel tool, modifier, and internal operator have a material
slot # parameter that the user can set. If left at default of -1,
behavior is as current -- bevel face material is taken from the
closest original face (this may be ambiguous). If material slot
is >= 0, it gives the material slot index number for the material
to use.
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,
