Along with some minor cleanup and simplifications.
Reviewers: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D903
layer index was being obtained for loop data types but we referenced
Tessface data types
NULLing those out since only the data offsets are used in edit mode and
address sanitizer complains about freed memory access.
Also minor comment in texpainting
Indeed, constructive modifiers are highly likely to modify CDLayers like vgroups or vcols!
See vertexgroup2.blend file ({F93770}) in T40523, especially obvious with subsurf modifier.
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
Show that modifier may not be supported in dyntopo rather than sculpt
mode in general. This is useful information since users may confuse the
two. Multires for instance is surely supported in sculpt mode, but not
in dyntopo.
Warn when a modifier does not support optimal drawing and mask/hidden
parts display.
User report was that hidden parts became visible after adding a new
modifier subdivision. Subdivision was added with the Ctrl+number keys.
First part of the fix was to make sure we add a multires instead of the
subsurf modifier in sculpt mode with the PageUp/Down Ctrl+number keys.
We can't really stop users from having added a subsurf modifier already.
We could be "smart" and convert subsurf to mulrires upon entering sculpt
mode maybe but that can easily backfire - or users may actually want
that. For now, just warn that the modifier won't support Hiding/Masking
and optimal drawing.
Sculpt mode drawing fails after deleting a subsurf modifier
in sculpt mode and undoing.
This was quite difficult to spot. Main cause was that mesh data was not
synchronized properly between undo and sculpt code because we generated
a pbvh on derivedmesh invalidation without really refreshing the rest of
the data. This could result in undo and drawing operating on different
data.
To solve this and avoid bad level calls I had to move quite some code
around. Crazyspace is now moved to blenkernel, as did some sculpt calls
that make sure sculpt data are properly refreshed.
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.
* 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
The variables are considered invalid unless DM_update_materials is
called prior to use. Only use case currently is
mesh drawing. This helps with excessive allocation on the stack during
GPUObject creation, but may help elsewhere in the future as well.
Own bug from rBc691551249f3. Now at least I understand why `test_index_face()` is needed for tessellated quads!
Added a bunch of comments to explain the issue, as it's far from an obvious one...
We loose some performances, but it's still much quicker than org code.
The main idea is to store (during tessellation) or recreate (during tessdata update) a tessfaceverts-to-loops mapping, and then update all tessdata
in one pass, instead of calling `BKE_mesh_loops_to_mface_corners` repeatedly for all tfaces!
Differential Revision: https://developer.blender.org/D226
Reviewed by Campbell, thanks a lot!
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
