| Age | Commit message (Collapse) | Author |
|---|
|
This prevents zero-leafs bvhtrees from being recalculated multiple times.
|
|
|
|
loose edges
|
|
DerivedMesh.
Differential Revision: https://developer.blender.org/D3227
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
Add `bvhtree_from_mesh_edges_ex` and callbacks to nearest_to_ray (Similar to the other functions of this code)
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
|
|
|
|
* More code changes pointed by Brecht in codereview.
* Some user interface improvements.
* Updating brush settings now also updates canvas preview.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The goodies:
* Curves can be used as normal dynamic effectors too with
the new "curve" field shape.
* Group visualization has optional duplication counts for
each object in the specified group.
* Object & group visualizations, which are done without
taking the dupliobject's global position into account
(unless the whole group is used). This is much nicer than
the previous behavior, but I added a "Use Global Location"
option for those who want to use it the old way.
* The active particle system's particles are now drawn a
with theme coloured outline instead of pure white.
* Added object aligned velocity factors (buttons categorized
and re-organized too).
Bug fixes:
* Absorption didn't work as the ui toggle button was forgotten.
* Some other force field ui tweaks.
* Crash after adding children and changing trails count.
* Display types "cross" and "axis" crashed.
* Particles weren't drawn with correct coloring.
* Billboards didn't update properly in viewport to camera
location changes.
* Particle rotation wasn't recreated correctly from point cache.
* Changing particles amount crashed sometimes.
* Some files with child hair crashed on loading.
* Compiler warning fixes.
* Adding boids crashed on frame 1;
|
|
+bvhtree cache (if the derived model doenst gets destroyed then the same BVHtree can be used)
this was needed to allow shrinkwrap constraint to be usable.
It has been ready for a long time.. but only got merged now, for 2.49.
|
|
neighbour, non-recursive now, faster than kdtree.c implementation normaly, divided into 2 sources: generla structure in blenlib, mesh/derivedmesh depending interface stuff in blenkernel
|
