Issue wascaused by the famous OpenMP crap in MSVC2013,
so only way is to use openmp threading if number of BVH
nodes is high enough.
Made it 8 for now, which seems to work rather fine on my
laptop and adult dragon from sintel. But maybe it's to be
adjusted a bit more.
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.
Some tools used view vector while others used the area normal.
Area Normal -is- useful and it will have to be incorporated to the
system better, but I'd like to do it in a way that is well
collaborating with sculpt plane calculation too, because it will have
to be slightly more expensive, i.e normal calculated before the plane,
never together, so only front to the area normal influence can be kept.
Currently sculpt plane takes into consideration view vector, but that
can produce an unwanted normal/plane at glancing angles on mesh edges.
Another issue that arises here is whether we do an actual calculation of
sculpt normal for each symmetry pass or we just flip the initial (former
is more expensive but more correct)
Returning to object mode reactivates any generative modifiers
and this can lead to a polycount explosion.
For now just improve the warning when entering dyntopo with generative
modifiers. I would like to add the ability spawn options to apply or
remove the modifiers too, however separate undo stack system comes back
with a vengeance here, since it won't allow restoring the application/
also may invalidate all sculpt undo in the undo stack prior to the
application (needs investigation).
2.70 for non Apple systems.
Also refactored the code that restores the previous openmp thread count.
The logic here was weird, mostly due to all the commit madness with
Apple openmp support. The restored thread count though should not depend
on the on/off state of threaded sculpting (since it has to do with
systems other than sculpting only). For OSX threads are restored to the
system thread count but Jens should recheck here.
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.
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.
Seems like custom data indices can be mangled when many layers are
present in the mesh, so use more strict calculation of offset (copied
over from BM_CD_LAYER_ID).
I was under the impression that all custom data would be deleted on
entering dyntopo, it seems this is not the case though.
It makes code more tidy (avoids having to call invalidation on a myriad
places). Also makes sure other invalidation cases (some mesh change,
e.g.) work as expected.
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!
- autodetect optimal default, which typically avoids HT threads
- can store setting in .blend per scene
- this does not touch general omp max threads, due i found other areas where the calculations are fitting for huge corecount
- Intel notes, some of the older generation processors with HyperThreading would not provide significant performance boost for FPU intensive applications. On those systems you might want to set OMP_NUM_THREADS = total number of cores (not total number of hardware theads).
