This function was only a wrapper around id_clear_lib_data(), and shapekeys
are not linkable nor shareable anyway, no point keeping this currently,
was only adding confusion about shapekey 'status' as a datatblock.
Many checks for out->rect_float being [non-]NULL are done back-to-back.
Combining them into a single check for slightly more efficient code and
less code clutter for easier readability/understanding.
Differential Revision: https://developer.blender.org/D2097
Applying cflags globally can be problematic especially with extern, intern libs.
Now flags from target named will be used when defined,
allowing for developers to define flags for modules they maintain.
Convention is CMAKE_CFLAGS_${UPPERCASE_TARGET_NAME}, (CXXFLAGS for C++).
eg: CMAKE_CFLAGS_BF_BLENDER, CMAKE_CFLAGS_MAKESDNA, CMAKE_CXXFLAGS_CYCLES_KERNEL
On Linux run `make help` for full list of names, MSVC shows these in the solution.
Accessing `bpy.app.binary_path_python does search, then swaps its getset with the string it finds.
This caused a freed pointer to be stored in bpy.app's dictionary.
Fix by using the same string for get/set access.
Recently the snap to edges has been changed to work with coordinates 2d. Thus, the lambda of the snap pointon on edge becomes different from the actual lambda in a 3d edge.
The solution to correct the lambda was this:
```
if (is_persp) {
const float fac = depth_a / (depth_a + depth_b);
lambda *= (1.0f + (fac - 0.5f) * (1.0f - lambda));
````
...
But the lambda was still not very accurate.
Now the function uses the `dist_squared_ray_to_seg_v3` to get the coordinate of the snap point on the edge. And then tests that point.
The accuracy returned to normal values.
from D2104: reference all repeated (and strange) equations (example: mul_m4_m4m4(pmat_local, pmat, obmat)) in the function `precalc_project.
This is useful for maintenance.
Current code changes the selection then then runs ED_armature_sync_selection
to copy to the bones rootsel flag from the parents tipsel.
Use this logic for entering edit-mode too.
This reverts commit 47d0d9cca4.
Reverting the commit. Not only it did not solve all the cases of proxy popping,
but also broke real cases with single proxy involved.
The snapping functions when performed in the perspective view,
have some problems in the threshold (a distortion) and in the clip plane (the normal is incorrect).
These problems can be only observed when making the snap to edges or to vertices (nearest to ray function).
This patch propose a totally different solution.
The idea is to project the edges of bvh nodes and test the 2d projection of the snap element.
For this it used the BLI_bvhtree_walk_dfs function.
It is important to pay particular attention also to the changes in `ED_transform_snap_object_project_view3d_ex`
- icon_id from ID and PreviewImage were not guaranteed to be in sync.
- PreviewImage one was not reset on file read.
- Through RNA e.g., it was possible to ensure an ID icon via its preview image,
which was running code designed for custom previews/icons system, instead
of generating correct 'auto ID icon'.
This reverts commit f12204196f.
Campbell, sorry. have to revert this for the time being.
We've missed some very important bits, such as:
- FFmpeg is usually linked against OpenJPEG
- OIIO needs OpenJPEG as well.
For FFmpeg issues we can either disable OpenJPEG there (since
we don't really use it), or bump FFmpeg to version 3.1.1 which
can use either of OpenJPEG 1.5 or 2.1.
For OIIO we do need OpenJPEG support (otherwise Cycles will
not be able to use j2k/j2c textures) and currently there is
NO solution to make OIIO working with OpenJPEG 2.1.
According to Matthias Fauconneau (aka mfv) Larry is working
on the patch to get OIIO work with OpenJPEG 2.1, but it'll
take some time still.
I've tried to look into support of some sort of build system
flag and do ifdefs, but it all becomes quite nasty, especially
with bundled OpenJPEG bumped to 2.1.
Surely such an update is something we'll have to apply to
but at this exact moment it causes quite some pain for all
developers.
Suggest to wait for until OIIO supports OpenJPEG 2.1 and then
go with the updates for real.
