This patch does two things:
* Introduce a Seed to the random distribution method
* Bring in a new distribution method for the point scattering node
Patch Review: https://developer.blender.org/D9787
Note: This commit doesn't not handle doversion. Which means that users
need to manually update their files that were using the Point Distribute
node and reconnect inputs to the "Maximum Density" socket.
Original patch by Sebastian Parborg, with changes to not rely on the cy
libraries and overall cleanup.
Patch review by Jacques Lucke, besides help with the new "heap" system
that was required for this algorithm.
Based on Cem Yuksel. 2015. Sample Elimination for Generating Poisson Disk
Sample. Sets. Computer Graphics Forum 34, 2 (May 2015), 25-32
http://www.cemyuksel.com/research/sampleelimination/
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenlib` module. Not all warnings are
addressed in this commit.
No functional changes.
The knife code currently calls the `BLI_bvhtree_overlap` function that
tests the overlap between the mesh tree and an AABB that encompasses the
points projected in the clip_start, clip_end and or clip_planes of the
view.
This resulted in many false positives since the AABB is very large.
Often all the triangles "overlapped".
The solution was to create a new function that actually tests the
intersection of AABB with a plane.
Even not considering the clip_planes of the view, this solution is more
appropriate than using overlap.
Differential Revision: https://developer.blender.org/D8229
`BLI_task_parallel_range` counts the number of tasks depending on the
number of items.
In the case of `BLI_bvhtree_overlap` the number of items is always
between 2 and 16, which makes it always run in single thread.
So, set the maximum number of items per thread to 1.
In my tests the cloth collision system (which calls that function)
went from 0.80fps to 0.88fps.
Differential Revision: https://developer.blender.org/D6523
As you can see, here is testing the "children" of `node1`.
So bvhtree is `tree1`.
This problem has never been observed because usually `tree_type`
of `tree1` equals `tree_type` of `tree2`.
Although not using multithreading, the `thread` parameter in the
`BVHTree_OverlapCallback` callback always returned a value between the
"number of threads".
This parameter should always be 0 in such cases.
Also a `BLI_Stack` was created for each "thread" and used.
This small overhead is no longer seen.
Differential Revision: https://developer.blender.org/D6510
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
Simple find_nearest relies on a heuristic for efficient culling of
the BVH tree, which involves a fast callback that always updates the
result, and the caller reusing the result of the previous find_nearest
to prime the process for the next vertex.
If the callback is slow and/or applies significant restrictions on
what kind of nodes can qualify for the result, the heuristic can't
work. Thus for such tasks it is necessary to order and prune nodes
before the callback at BVH tree level using a priority queue.
Since, according to code history, for simple find_nearest the
heuristic approach is faster, this mode has to be an option.
This patch adds support for clip_planes (ie ignore what is behind a face)...
The idea is to first execute a raycast to get the polygon to which the mouse cursor points.
Then a snap test is done on the vertices or edges of the polygon.
Then with the normal and location obtained in raycast a new clip_plane is created and the snap over the whole scene is processed ignoring the elements behind the clip_plane.
Here 2 gif of how the previous patch would work on blender2.79:
{F497176}
{F497177}
Reviewers: mont29, campbellbarton
Reviewed By: campbellbarton
Subscribers: bliblubli
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2527
