Fill-selection would only go upward in list of items to find an already
selected one and fill-select all items in-between. Now, in case upward
search fails, it will also intent to go downward, effectiviely allowing
to 'fill-select' from bottom to top.
Note that top-to-bottom keeps priority (i.e. if a top-to-bottom
fill-selection is possible, it will always happen, even if a
bottom-to-top one is also possible).
* For the T48988 fix (i.e. separate Ease In/Out properties for Bendy Bones
in Edit vs Pose modes), old animation data needed to be patched to use
the new property names. This is needed to partially fix some of the
issues in T53356 (though the Rigify code itself still needs to be patched).
* For the T52009 fix, old files needed to have the frame_start and frame_end
properties on the FModifier (base-class) updated to match that of the
FMod_Stepped type-specific class. This wasn't done in the earlier commit
since it wasn't worth going through all animation data just for the sake
of updating these relatively-rare settings, but since we're doing it anyway
now, it makes sense to include this here.
Patch from Richard Erhardt, with some additions & modifications.
Changes bevel profile shape parameter so that can get arbitrarily
near square profile as parameter -> 1.
Adds code to make profile=0 case work, at least for cube corners,
so changed hard min of profile parameter to 0 from 0.15.
Currently shouldn't make any difference, but this is something what needs to be
done to sanitize drivers relations )with the idea to re-use some generic code
to get operations for driver variables.
Those are unused, and not clear whether we will ever support this.
Seems to be better having more like "component" tags, would be less magic
involved to guess what exactly is to be tagged.
One or two are OK, but more make it rather unreadable, and future work
is likely to require more toggle specific behavior here. So switched to
bitflags, switching from short to int and using 16 upper bits for
'internal' ones defined in BLO_readfile.h, combined with 'public' ones
from user interaction, defined in DNA_space_types.h
The idea of this flag was to prevent snapping onto an object which depends on
currently modifying ones. Using single flag makes more sense here, and also
makes it possible to replace some ob->recalc based magic with depsgraph query
to set those flags.
It looks stupid to first force some flag being set and then have workaround
to ignore that flag in snapping code. Let's just not set the flag in the first
place.
The only useful situation where such snapping was usable is to move roots of
disconnected hair, which still works just fine. However, there might be some
other hidden corner case where this workaround was needed.
For some blend modes there would be no effect with factor 1.0, even if factor
0.999 would give a very different image. Now the result should have no
discontinuity.
Differential Revision: https://developer.blender.org/D2925
