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
My previous fix for uninitialized texture coordinates was not working well,
and in fact there was a bigger issue with GLSL drawing and missing attributes
with immediate draw mode. Now it will explicitly pass zero rather than having
it use whatever value was set last.
Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.
Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.
--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt
