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.
Regression caused by own changes to make texture paint more efficient
from workflow point of view.
Now the idea is to use vertex color outside of paint mode, so we don't
break any compatibility here.
For simple cases bitmasks were OK, but didnt work for vert/edge, vert/edge tests.
Tag verts instead, makes logic easier to follow and gives minor speedup.
Make sure we don't perform any implicit address space conversion.
A bit annoying, but less intrusive approaches (like using temp private
variable in .cl kernel) do not work correct here.
Using generic address space will help from code side here, but will
be somewhat slower due to extra things happening as far as i know.
So the error seems to be in cubic_tangent_factor_circle_v3(),
which was introduced with D2001.
I've tweaked the most obvious culprit here - the epsilon factor.
It used to be 10^-7, but I've reduced it down to 10^-5 now,
and it's looking a lot more stable now :)
---------
BTW, about the derivation of the magic 0.390464 factor I briefly subbed back
as a workaround for this bug, see:
http://www.whizkidtech.redprince.net/bezier/circle/
It's probably some numeric precision issue, but until we figure out exactly what's
going wrong here, let's just revert back to the hardcoded value that was used here
successfully for years without issues.
Remapping indirect usage of IDs is forbidden from user space, this is calling for
nice nightmare with libraries handling (and undo crash, among other things).
Not sure why I was 'laxist' about indirect usage cases detection like that,
for now just consider any ID used by another linked datablock as indirect usage case!
Also, added some error/warning reports to Outliner's remap code.
The "W" channel will get a yellowish colour (i.e. a blend between the X/R and
Y/G axis colours), while the XYZ will behave as they do for other transforms.
The create drivers operator should not use the "Transform Channel" variable type
when driving one transform with another on the same object/bone. Otherwise, you
end up with a situation which technically results in a bit of a pseudo-dependency
cycle.
The Ctrl-Shift-C operator to add constraints between a pair of selected items,
for example, between two objects, or between two bones (in the same armature).
This commit makes it possible to use this operator to add a constraint where the
target is a bone from another object - e.g. to make a deform bone follow the control
bone in another armature, or to make an object use a bone as a tracking target.
Usage:
1) Ensure you are in Pose Mode, then select the bone to use as the target
2) Shift-Select the other object and/or the bone that's going to get the constraint
3) Ctrl-Shift-C
Problem was in fact slightly wider, File space was nearly not taking into account
library navigation case and its 'virtual' directoris, except in a few places.
Add a wrapper around BLI_is_dir that also check for lib paths, and used it in
ED_file_change_dir(), such that we now always check path is a
valid directory - in the filebrowser context, not filesytem context. ;)
As far as I can see, the second issue there was that the functions receive a pointer to a member variable of the
ShaderData, which is stored in global memory. However, this means that the pointer points to global memory as well,
therefore OpenCL requires the ccl_addr_space "keyword" in front of the pointer.
With this commit, the OpenCL kernels build on Linux with the Intel CPU OpenCL runtime - however, they already did
without the change and I don't have an AMD card, so I can't really test whether the AMD runtime is happy as well now.
Those (one per ID type!) were uselessly duplicated, and badly inconsistent
(some types were actually unlinking before deletion, others were only working if already unlinked!).
Now we use same func and same API for all types, by default deletion is performed only if ID is no more used,
set `do_unlink` parameter to True to always delete ID even if still in use.
Only exception now is with Scene, since we always want to keep at least one!
Note that this will change default behavior of some types (since unlinking is never done anymore by default).
