It's still gives some slowdown when painting a locked
key in the solid view, but since shape key is now longer
being re-used by DM.
but this change should still give some degree of speedup
propagating delta onto the keyblock if i remember the
code correct.
show diffuse option not correctly calculated on opening a file.
Make sure we call pbvh_show_diffuse_color_set after building the pbvh so
vertex data are available to it.
So, turned out after all we need a foreachmapped helper for loops as well... :/
CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a
bad working solution (see D478). So I fallback to a code similar to CDDM one.
Probably not nice for performances, but loops and subsurf are not matching well...
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D478
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!
* 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 here is that "show diffuse" option does not respect its intended
purpose which is to be used only for masking.
There are a couple of caveats here:
Dyntopo and multires -always- have mask data enabled, and thus as soon
as one goes to dyntopo mode or adds a multires modifier he would get the
default grey color instead.
Matcaps would break when nodes asked for a diffuse material color (this
was broken before too). Solved by adding global material state for when
matcaps are enabled. Also matcaps don't always played well with VBOs
off.
Added a few more missing updates for mask operators to notify
show_diffuse property as changed. This was also needed on rebuilding
dyntopo pbvh.
Also make zero mask color duller again after artist feedback.
This commit does various changes for matcaps:
One is taking advantage of drawing with pbvh (which would only happen
with dyntopo previously) and drawing with partial redraw during
sculpting.
The second one is support for masks. To make this work in the special
case of multires, which uses flat shading, I use the only available flat
shaded builtins in OpenGL 2.0 which are color and secondary color.
Abusing colors in that way is also essential for flat shading to work if
we are to use pbvh draw in multires, since it is the color that is being
interpolated flatly, not the normal (which can only interpolated
smoothly). The pbvh drawing code for multires used last triangle
element's normal to compute the shading which would only produce smooth
results. This could change if we did the shading in the vertex shader
for flat shaded primitives, but this is more complex and makes it harder
to have one shader to rule the mole.
Also increased the brightness of the default diffuse color for
sculpting. This should be useful since artists like to tweak the
lighting settings and it will give them the full dynamic range of the
lights, but also it helps with correct brightness of sculpted matcaps.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D435
Factorized a bit the code here, think it's more readable now... No performance enhancement though.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D259
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.
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
this means in editmode with wire draw, face and vertex normals don't have to be calculated at all.
in most cases the normals are not used so add a flag that makes calculating them only for functions that need them.
also fix face normal calculation for CDDM, was using quad calculation for ngons too.
Also construct orco uv layer when converting curve to a mesh.
This makes it possible to preserve automatically generated coordinates
("use uv for mapping" option) when using constructive modifiers or
converting curve to the mesh.
With cycles nothing special is needed to preserve texture mapping
after such operations, in blender internal you'll need to change
texture mapping from Generated to UV.
This feature is useful on it's own and also would help in potential
switch 3d viewport to always use DM to draw objects, which would
help making drawing more thread-safe.
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.
many modifiers were calculating normals, when those normals were ignored by the next modifier.
now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback.
Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
Textured dyntopo draw was leaving 2d textures enabled when it shouldn't.
Root of the issue was figured out by Campbell, actual place where
2D textures left enabled found by self.
Also, simplified fix is suggested by Campbell (mine was 2 lines longer! :)
