| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
0b5a0d84 caused regression since edit-mesh BVH wasn't cached,
each shrink-wrap modifier created its own BVH.
|
|
|
|
|
|
|
|
Used ** arguments unnecessarily,
also replace BLI_linklist_apply with while loop.
|
|
|
|
|
|
All callers pass in valid number
|
|
Would have prevented previous error going unnoticed.
|
|
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.
|
|
|
|
Use BLI_bvhtree_find_nearest_to_ray for vertex snapping,
avoids doing screen-space lookup on each vertex.
|
|
Flag mix-up and uninitialized var.
|
|
|
|
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.
|
|
|
|
By default watertight intersections are used,
For callbacks where its not needed,
BLI_bvhtree_ray_cast_ex can be called without the BVH_RAYCAST_WATERTIGHT flag.
Fixes T45286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
