The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.
This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.
Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1127
`CustomData_bmesh_interp_n` was expecting the 'dest' arg not to have its offset applied.
This was a bit confusing since the source args have it applied,
and in some cases we only have the destination with the offset.
Titles says everything, just two notes:
* We have to actually transfer plain *normals*, not 'compressed' clnors,
so had to add pre/post process to transfer to make the conversions.
* Also added interpolation and advanced copy/mixing to CD_NORMAL, for same reasons.
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
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.
