Main issue was that BKE_libblock_relink_ex was pretty much ignoring all those...
Also, unlinking of objects was not handling correctly indirect-related flags.
Refactored code into helper functions to avoid too much duplicated code.
Toggling edit-node after joining objects is redundant as far as I can see -
(dates back to first revision).
Also caused all edges to be drawn w/ meshes, redundant undo step w/ curves.
`my_memcmp` didn't work properly comparing memory sizes not aligned to 4 bytes,
this worked while we used guarded-alloc (which always wrote a guard at the end of each allocation).
Since moving to lockfree allocator it could read uninitialized memory.
It also consistently performed ~10-30% worse then glibc's.
This is typically well optimized, no need to do ourselves.
Scaling a bone on the Y axis (for a stretch effect), wasn't supported by the IK solver.
Support this by solving as uniform scaled bones by matching the X,Z axis to the Y.
Requested by @pepeland, see D2088 for details.
This should allow us to avoid a lot of useless processing when iterating over the
whole main database (unlink/remap/usages checks/etc.).
Note that some ID types report they can use any type for now, due to
fuzzyness/indefined nature of some usages (like constraints/modifiers/game logic,
or ID pointer of nodes...). Maybe we could address this (like e.g. adding defines
in relevant headers to restrict ID types used by constraints, by modifiers, etc.).
But don’t think this is top priority for now.
Those unwrap operators are a bit tricky, some are available from both 3DView and UVEditor, others only from 3DView...
Hacked around this by returning Mesh keymap for UV_OT ops for specific 3DView/MeshEditMode context.
Currently "long keyframes" are only useful for indicating where stationary
holds occur. If however you try to create a "moving hold" (where the values
are slightly different, but in terms of overall effect, it's still a hold)
then it could get tricky to keep track of where these occur.
Now it's possible to tag such keyframes (using the keyframe types - RKEY)
as being part of a moving hold. These will not only be drawn differently
from normal keyframes, but they will also result in a "long keyframe"
being drawn between each pair of them, just like if they had been completely
stationary instead.
Currently the theming/styling of these is a bit rough. They reuse the existing
theme colours for long keyframes.
A long requested feature has been to have objects appear in alphabetical order
in the animation editors, so that it is easier to find where they occur. This
commit implements support for this.
The main sticking point has been the performance impact of having this sorting
happening all the time (as the actual list of "bases" cannot be modified, as the
old depsgraph still needs random-looking unsorted order of objects for scheduling
updates). However, it recently occurred to me that perhaps by restricting it to
the one case where the ordering actually matters (i.e. when we're getting the channel
list for drawing all channels, vs operating on them), and adding a toggle to turn the
sorting off in heavy scenes when it might bog down things, that it will probably
be acceptable enough in general. Furthermore, if things get really bad, we can investigate
putting in place some sort of caching scheme for this too - though hopefully the
new depsgraph will make that unnecessary (i.e. it doesn't sort the bases directly anymore).
This commit introduces a scale factor setting for scaling all keyframe indicators
in the Dopesheet Editor up/down, in order to make them easier to select. It is perhaps
most useful for keyframe types which are usually indicated using smaller keyframes
(e.g. breakdown), which may get tricky to quickly select.
To make it easier to synchronise timing across multiple strips, if you add
markers locally to an action, these will show up in the NLA strip in the
NLA Editor. These markings can then be used to line up the start/end of
another strip, or even to make sure that the markers from two different
strips end up lining up.
By default, this is turned on, but it can be disabled (via the View menu)
if it adds too much visual noise.
This breaks any post-versionning (like IPO conversion, python handler, etc.).
rB961ebfa8c40b9909 mentions some Main being do_versionned several times (which is not desired for sure),
will try to reproduce again and find another fix.
Since SDNA was allocated for each undo step,
the new address meant it was considered different and included again.
Add an option not to duplicate the DNA string when calling DNA_sdna_from_data,
as well as avoiding a redundant copy, it writes the same address each time.
Idea is to replace hard-to-track (id->lib != NULL) 'is linked datablock' check everywhere in Blender
by a macro doing the same thing. This will allow to easily spot those checks in future, and more importantly,
to easily change it (see work done in asset-engine branch).
Note: did not touch to readfile.c, since there most of the time 'id->lib' check actually concerns the pointer,
and not a check whether ID is linked or not. Will have a closer look at it later.
Reviewers: campbellbarton, brecht, sergey
Differential Revision: https://developer.blender.org/D2082
Checking if faces exist was a bottleneck,
use a simpler version of this function for triangles.
Gives approx 1.6x overall speedup (when many edges are being collapsed).
When snapping to edge/vert, check the distance to the ray
instead of the screen-space pixel projection.
This also corrects the conversion of `dist_to_ray_sq` to `dist_px` which was being done incorrectly.
While this change was planned, it fixes T48791, caused by error in b01a56ee.
