BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
- Use the object referenced in `BMEditMesh` as the `ghash` key to save the bvhtrees in cache;
- Create a boundbox around edit_mesh to test the snap before creating bvhtree;
- Save the `edit_mesh`s bvhtree in the mesh bvh_cache;
This is a part of the D3504.
The release of these arrays should be the programmer's discretion since these arrays can continue to be used.
Only the expanded functions `bvhtree_from_mesh_edges_ex` and `bvhtree_from_mesh_looptri_ex` are currently being used in blender (in mesh_remap.c), and from what I could to analyze, these changes can prevent a crash.
changes in BLI_kdopbvh:
- `BLI_bvhtree_find_nearest_to_ray` now takes is_ray_normalized and scale argument.
- `BLI_bvhtree_find_nearest_to_ray_angle` has been added (use for perspective view).
changes in BLI_bvhutils:
- `bvhtree_from_editmesh_edges_ex` was added.
changes in math_geom:
- `dist_squared_ray_to_seg_v3` was added.
other changes:
- `do_ray_start_correction` is no longer necessary to snap to verts.
- the way in which the test of depth was done before is being simulated in callbacks.
Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
Own regression caused by fix for T46067,
edit-mode bvh only contained unselected faces.
This commit adds support for an edit-mode bvh containing all faces.
You can now use lower-level '_ex' versions of bvh creators to only use part of
the mesh's elements in the BVH, and/or create bvh from non-DM sources.
Needed for transfer data.
Note edges extend version of bvh creator is not added here, not needed so far.
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.
