Age | Commit message (Collapse) | Author |
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
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.
|
|
|
|
Free the BVH tree immediately along with the mesh, otherwise we might access
invalid mesh data.
Differential Revision: https://developer.blender.org/D4201
|
|
There is no point having operations that iterate over the whole
bit array as macros, so convert BLI_BITMAP_SET_ALL to a function.
Also, add more utilities for copying and manipulating masks.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D4101
|
|
|
|
Helps separate variable names from descriptive text.
Was already used in some parts of the code,
double space and dashes were used elsewhere.
|
|
|
|
|
|
|
|
|
|
multiple objects.
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
This prevents zero-leafs bvhtrees from being recalculated multiple times.
|
|
|
|
|
|
|
|
|
|
|
|
loose edges
|
|
Same issue as in DM-based on, so follow up of rBf3efa9e15f58...
|
|
|
|
Could lead to atempt to free NULL pointer, and/or memory leak.
|
|
BLI_bvhkdop functions were not made to work with zero-leaf trees.
Perhaps a better solution would be to modify BLI_bvhkdop to work with zero leaf trees.
But this solution of returning NULL was already used for bvhtrees of looptris.
|
|
DerivedMesh.
Differential Revision: https://developer.blender.org/D3227
|
|
- BKE_mesh_get_looptri_num -> BKE_mesh_runtime_looptri_len
- BKE_mesh_runtime_recalc_looptri -> BKE_mesh_runtime_looptri_recalc
- BKE_mesh_get_looptri_array -> BKE_mesh_runtime_looptri_ensure
|
|
|
|
This member currently doubles the value of `ray->radius` or is not even used.
|
|
|
|
|
|
with `bvhtree_from_mesh_get`.
|
|
This will help us have more control over bvhtrees that are cached.
|
|
This will allow greater control of the bvhtrees that are obtained, and helps identify problems.
It is also an additional step to unify the functions.
|
|
identifier type.
Reviewed By: @campbellbarton
Differential Revision: https://developer.blender.org/D3192
|
|
- When returning the number of items in a collection use BLI_*_len()
- Keep _size() for size in bytes.
- Keep _count() for data structures that don't store length
(hint this isn't a simple getter).
See P611 to apply instead of manually resolving conflicts.
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
Also remove duplicate & mismatching comments from grease-pencil header.
Keep comments close to implementation to avoid getting out of sync.
|
|
|
|
|
|
of bvhutils
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.
|
|
This could cause bugs in the memory release
|
|
~edge_num~ edges_num_active
Not always all the edges enter in the build
|
|
Add `bvhtree_from_mesh_edges_ex` and callbacks to nearest_to_ray (Similar to the other functions of this code)
|
|
This was a stupid mistake
|
|
Instead of reference the vertex first and test the bitmap afterwards. Test the bitmap first and reference the vertex after.
In a mesh with 31146 vertices and the entire bitmap disabled, the loop time is 243% faster
With all bitmap enabled, the time becomes 463473% faster!!!
One possible reason for this huge difference in peformance is that maybe the compiler is not putting the function "BM_vert_at_index" inline (I dont know if buildbot do this, but it's good to investigate).
|
|
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.
|