`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.
This ensures slide with `Correct UVs` enabled, keeps UV's (any loop custom-data) contiguous.
Adds 2 key functions `BM_vert_loop_groups_data_layer_create` and `BM_vert_loop_groups_data_layer_merge`
They work by collecting matching loop custom-data around the vertices loop-fan,
and merging the custom-data after edits are made.
Thanks to @mont29 for review!
Error in custom split normals work, non-autosmooth normals != vertex normals!
Loops from flat faces shall take normal of their face, not their vertex.
Tsst...
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.
Issue was, when requesting (building) lnors for a mesh that has
autosmooth disabled, one would expect to simply get vnors as lnors.
Until now, it wasn't the case, which was bad e.g. for normal projections
of loops in recent remap code (projecting along split loop normals
when you would expect projection along vertex normals...).
Also, removed the 'angle' parameter from RNA's `mesh.calc_normals_split`.
This should *always* use mesh settings (both autosmooth and smoothresh),
otherwise once again we'd get inconsistencies in some cases.
Will update fbx and obj addons too.
Org code by robschia (Roberto Schiavone), first review by campbellbarton (Campbell Barton),
final review and minor changes by mont29 (Bastien Montagne).
Reviewers: cambellbarton, mont29
Subscribers: mont29, campbellbarton
Maniphest Tasks: T40930
Differential Revision: https://developer.blender.org/D638
Triangulate with beautify caused a bug when there were existing edges
could make the bmesh-operator return an invalid face-map.
Now the beauty is calculated on the 2d-tri's resulting from polyfill,
its simpler and faster.
note, this is for C++ code which expects a cast, (will be added later)
also add a macro for nop-expressions (EXPR_NOP),
when we never want an expression to be evaluated, but it should still be valid.
