This fixes an issue where an animated modifier property that's used as
variable in a driver wouldn't animate that driver's value.
Building the relations for the driver target creates the relation
`PARAMETERS_EVAL` → `DRIVER(variable)`. Building the relations for the
FCurve targeting the modifier property creates the relation
`ANIMATION_EXIT` → `GEOMETRY_EVAL_INIT`.
This means that there is NOT a relation `ANIMATION_EXIT` →
`PARAMETERS_EVAL`, and as a result, the driver is not properly updated
when its variable reads animated data. This is resolved in this commit
by adding the missing relation.
Differential Revision: https://developer.blender.org/D7615
`BKE_sequencer_prefetch_get_original_sequence()` didn't look in metas
and returned NULL. This caused crash in disk cache that was trying to
read seq->name.
Add function that will look in meta strips recursively and condition
that seq must not be NULL.
Reviewed By: brecht
Maniphest Tasks: T76033
Differential Revision: https://developer.blender.org/D7597
An unintentional side-effect of rBfe7528ee919b was that when
extend-selecting a selected element in the outliner, it would be
deselected and activated rather than selected and activated.
This commit restores the expected toggling behavior. Consistent behavior
for extend-selecting child datablocks is not resolvable without a much
larger cleanup of the outliner select functions.
For any modifier, the expected output when the input mesh is empty, is an
empty mesh. So this error message was useless, and could spam the
console in some usecases of the modifier stack...
Reviewed By: weasel, mont29
Differential Revision: https://developer.blender.org/D7571
This is to improve the case of T71055 where curves share the same batch
cache when they shouldn't.
This however, does not help to fix edit mode display.
The real fix would be to have a similar handling to what the mesh modifiers
do and duplicate the whole Curve data. But this is too much work/change for
the 2.83 release.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7569
A Colorband's CBData color **is not** considered `PROP_COLOR_GAMMA`.
A Brushes color **is** considered `PROP_COLOR_GAMMA`.
(PROP_COLOR_GAMMA is used for colors which would be color managed before
display, could be renamed to something better once...)
This leads to different rgb values in ColorBand.CBData of br->gradient
and brush->rgb for seemingly identical colors. (this is because color
pickers do differently in case block->is_color_gamma_picker/
ui_but_is_color_gamma)
Now it looks like `paint_brush_color_get` is expected to return a color
in sRGB (according to @jbakker this is for legacy reasons) so we need to
run the colorband colors through linear -> sRGB.
It might very well be the case that a much deeper cleanup in this area
is needed, this is just a fix to get gradient brush colors
consistent again...
Maniphest Tasks: T75985
Differential Revision: https://developer.blender.org/D7501
Should prevent issue fixed by previous commit to happen again (since
read code, especially in undo case, is not really straight forward to
follow anymore).
used
Caused by {rBa6a9a12e8f32}
Other relevant commits:
rBb8ca806b7798e2f8dd6effca8f0d081b3cd8c23f
rBde530a95dc7b482dc22c933b9b8b2a98c79b5663
The issue is caused by some leftover BONE_TRANSFORM_MIRROR flags on a
bone from previous runs (file in the report had the flag still on
forearm.R).
With these false leftover flags still set, `pose_grab_with_ik()` cannot
work correctly. Culprit commit above removed the early clearing of this
flag on all bones, this should be restored [this happened in
`count_set_pose_transflags()`].
This should only be done in the beginning of the transform process, so
now still clear the flags early in 'createTransPose()' [but dont restore
this in 'count_set_pose_transflags()' -- this will be called from
special_aftertrans_update again, so placing the clearance here only
complicates things (autokeyframe_pose() still needs to work as well)...]
Maniphest Tasks: T75810
Differential Revision: https://developer.blender.org/D7527
The current "Select Linked" operator works based on mouse position and
makes no sense to call from the menus and was removed in rB536055e1ee0b.
This patch adds an operator independent from mouse position that just
selects all bones in relation to selected bones (and adds back menu
entries, adds keymap entry CTRL+L).
The original operator is renamed to 'select_linked_pick' internally
(this is now more in line to how "Select Linked" works for meshes,
curves etc)
ref T76071
Maniphest Tasks: T76071
Differential Revision: https://developer.blender.org/D7542
Done also in 2.83 release branch to avoid too much conflicts on merging
(some of those were already done for nodes in master, and gave me
conflicts yesterday...).
passes than one in another slot
If a particular pass is not available in a slot we are switching to,
still show the menu, but with a blank name for the currently selected
item so that the user can change it to a valid value.
thx @brecht for providing the standard way Blender deals with these
kinds of situations.
Maniphest Tasks: T76179
Differential Revision: https://developer.blender.org/D7552
Fix T75279: BLI_assert failed when deleting object in debug build
(only).
And all general cases of ID pointer idproperties that would use a
data-block not referenced anywhere else in the depsgraph.
This includes idproperties from:
* All ID types;
* Bones and pose bones;
* Sequences;
* Nodes and sockets.
Differential Revision: https://developer.blender.org/D7551
The problem comes from the fact by no data being modified when switching
viewlayers.
To follow what the external render engines do, we completely reset the
viewport by freeing the GPUViewport to avoid any cached data from being
kept.
This fix case where you have wireframe on top of infront objects but
workbench AA conflicts and they appear to not be occluded.
Also T74923 is still fixed but we extend the fix to not mess the case when
using a mode that does not support infront.
It is just a quick fix for the tooltips in the graph editor, it replaces:
- "F-curve modifiers are disabled" with "Enable F-Curve modifiers"
- "F-curve is visible in graph editor for editing" with "F-Curve visibility in Graph Editor".
Reviewed By: billreynish
Maniphest Tasks: T75519
Differential Revision: https://developer.blender.org/D7387
There was an assert here as well since using the original object to read
from was having an empty runtime curve cache.
Now use BKE_vfont_to_curve_ex instead of BKE_vfont_to_curve, so we can
read from the evaluated object and write to the original curves in order
to have the modified data taken into account on next object evaluation.
(BKE_vfont_to_curve would read and write to/from the same object)
Final solution provided by @sergey in that report, thx!
Caused by rBe82827bf6ed5.
DRW_draw_depth_object calls DRW_mesh_batch_cache_create_requested with
NULL scene, but that is accessed later on...
Scene is actually available, so pass that around.
Maniphest Tasks: T76131
Differential Revision: https://developer.blender.org/D7540
Seems like this was left out when UV operators were converted to multi-
object-editing, ref T54645.
Maniphest Tasks: T76111, T54645
Differential Revision: https://developer.blender.org/D7537
