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.
There were couple of reasons why it wasn't safe for usage from
multiple threads.
First of all, it was trying to cache BVH in derived mesh, which
wasn't safe because multiple threads might have requested BVH
tree and simultaneous reading and writing to the cache became a
big headache.
Solved this with RW lock so now access to BVH cache is safe.
Another issue is causes by the fact that it's not guaranteed
DM to have vert/edge/face arrays pre-allocated and when one
was calling functions like getVertDataArray() array could
have been allocated and marked as temporary. This is REALLY
bad, because NO ONE is ever allowed to modify data which
doesn't belong to him. This lead to situations when multiple
threads were using BVH tree and they run into race condition
with this temporary allocated arrays.
Now bvhtree owns allocated arrays and keeps track of them, so
no race condition happens with temporary data stored in the
derived mesh. This solved threading issues and likely wouldn't
introduce noticeable slowdown. Even when DM was keeping track
of this arrays, they were re-allocated on every BVH creation
anyway, because those arrays were temporary and were freed
with dm->release() call.
We might re-consider this a bit and make it so BVH trees are
allocated when DM itself is being allocated based on the DAG
layout, but that i'd consider an optimization and not something
we need to do 1st priority.
Fixes crash happening with 05_4g_track.blend from Mango after
the threaded object update landed to master.
Developer note:
BVHTREE_FROM_FACES was being used for both edit-mesh and derived-mesh
bvh-trees, this could cause index lookup errors in editmode.
Fix by adding a new type for editmesh so theres no confusion.
Casting a ray onto an editmesh was building a derivedMesh, raytree, then freeing for every ray-cast.
Noticed while using ruler+snapping in editmode.
Instead of attempting to align the MFace and edit-mesh tessfaces, just use editmesh for ray-casting.
- add examples for custom-data access
- group BMesh types logically in docs
- added missing docstrings
needed to add grouping functionality to sphinx for this.
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete.
This uses similar convention to RNA.
* use face/loop/edge/vert as a prefix for functions.
* use 'elem' as a prefix too for functions that can take any type with a BMHeader.
* changed from camel case to underscore separated (like RNA).
bvhtree_ray_tri_intersection now using isect_ray_tri_epsilon_v3 with FLT_EPSILON. All devs I asked (incuding ones in physics/painting areas) were rather OK with this change, and better to do it now, with more than one month to detect regressions, if any!
- some merges added lines in multiple times
- removed some NULL checks that were only in bmesh
- enable cycles by default (was disabled because it used not to work)
- make formatting match
