This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
This is only an indirect fix, in fact: this commit adds a public API to check
the maximum number of a given layer type (`CustomData_layertype_layers_max()`),
and uses it to forbid too much layer creation in `CustomData_merge()`.
This only affects UVs/VCol data though, but merge behavior in itself is not a bug
actually, how user managed to get thousands of different UV layer names remain
rather mysterious...
Don't use a dedicated node layer but use temporary int layer instead.
Works like a charm as long as we are careful resetting the layer when
needed (after pbvh clearing and always after bmesh has been filled in
undo)
Tip by Campbell, thanks!
Tessellated split normals CDlayer had no swap func, hence ugly little test_index_face()
could not rotate its values correctly when rotating tessellated faces...
Extra-reported in T39735.
* Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf).
EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit.
* Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it
(tessellation, rna access, etc.).
* Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable
split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding
this option is now incoherent, will be addressed in a separate commit.
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D365
Issue is caused by the race condition between getting custom data layers
from target's derived mesh (for vertices and faces) and releasing this
derived mesh from other threads.
When one releases the derived mesh it'll free temporary data from it,
and it'll also update data layers mapping.
General rule for threading is that no one is ever allowed to modify
data he doesn't own. This means that no temp layers are to be allocated
in derived mesh and making it so `CustomData_free_temporary()` doesn't
update mapping if nothing was freed will solve the race condition.
It is still possible to do other improvements, namely detect which
additional data/layers are to be present in derived mesh and create
it as a part of `object_handle_update()`, but this is to be solved
separately.
This simply mimics code used for loopnormals, to enable py scripts to generate and access (temporary)
a tangent 3D vector and bitangent sign for each loop. Together with the split normals, this allow
to recreate a complete tangent space for normal mapping (bitangent = bitangent_sign * cross(normal, tangent)).
Expects all faces to be tri or quads.
Reviewed By: Brecht, campbellbarton
Differential Revision: https://developer.blender.org/D185
(which is also "[#36749] Joining objects with more than one uv map depends on list order")
Thanks Bastien Montagne and Brecht van Lommel for reviewing and some advice.
Now add asserts to make sure this layer is only added once the modifier stack has been calculated.
this saves normal layer being calculated whenver vertex normals need updating.
weights, it assumed all weights were 1. This gave very different results with the
new bevel modifier due to slightly different vertex group interpolation.
