Age | Commit message (Collapse) | Author |
|
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
|
|
|
|
|
|
As noted in a comment now, these functions only update a cache, so they
don't change the logical state of the mesh, which is "it will have the
data when necessary." Using a const argument will help const correctness
when accessing an object's evaluated mesh.
|
|
This node calculates a distance from each point to the closest position
on a target geometry, similar to the vertex weight proximity modifier.
Mapping the output distance to a different range can be done with an
attribute math node after this node.
A drop-down changes whether to calculate distances from points,
edges, or faces. In points mode, the node also calculates distances
from point cloud points.
Design task and use cases: T84842
Differential Revision: https://developer.blender.org/D10154
|
|
No functional changes
|
|
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
|
|
This patch changes the BVHCache implementation. It will use
a primitive array in stead of the ListBase. The locking is also
changed from a global lock to a per cache instance lock.
The performance of `gabby.blend` available on the cloud increased from 9.7
fps to 10.5 fps.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D7817
|
|
|
|
|
|
|
|
With this function it is easier to create and have control over editmeshes `BHVtree`s.
|
|
This is a step that allow using `bvh_cache` for `EditMeshe`s.
|
|
I'm not very fond of adding new types of bvhtrees.
But this is probably the most efficient solution.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
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.
|
|
Done using:
source/tools/utils_maintenance/c_sort_blocks.py
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3719
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|