This is useful when popovers are launched from operators
instead of as button popover types.
Where the connection between the button and the popover is useful to keep.
We cannot reliably use translations API from non-main threads.
Now storing translated strings in a static cache, with basic mechanism
to update it on language change.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5350
This was caused by 2D stabilization trying to be smart and lower weight
of tracks which are too close to the rotation center. This was causing
algorithm to ignore a single track which was set to constant 1 weight and
used for rotation compensation.
It is quite tricky to quantify this change without having comprehensive
regression suit, so can only hope that initial intention is still working
as expected.
Weight Painting was using mask if "Selection Mask" in Sculpt Mode is turned on.
This can be quite confusing because the option to turn it off is not available in Weight Painting and the selection is also not visible.
Now the mask is not checked in weight paint mode.
The constant variable was passed as reference to constant variable, but it's better use the new function to copy values.
This could be the problem with T67772
Sync back between proxy armature pose and linked one was not properly
clearing the posebone runtime data, ending up with shared memory between
both (direct cause of reported crash), and probably some other nasty
issues.
While this crash is not critical in itself, I would suggest to add this
fix to 2.80 branch, as it is super-safe and simple, and is probably
fixing some other un-reported issues?
Some modifier operators cannot be reliably executed from Edit mode
currently, so disable them from the generic mod ops pool function.
Have been very conservative here from now, keeping existing behavior
most of the time, and only forbidding Edit mode when code was already
doing it in its own way, or when it was obviously not possible.
Main issue in that report was that meshes generated from
`mesh_create_eval_final_view()` and the like need some
special freeing handling (as, among other things, they borrow and do not
own their potential editmesh data...).
Factorized that into a helper func also used by
`BKE_object_free_derived_caches()`.
Such reload can no longer happen directly and is to be done via dependency
graph.
Eventually, the movie cache will become shared across all copies of the
clip, but even then we still need to have dependency graph mechanism because
we need to update FFmpeg animation handle (which can not be shared across
the copies).
This change makes it so current frame is queried from a scene rather
than from a dependency graph. This makes it possible to avoid the
fact that dependency graph might not be fully evaluated yet.
There are still some cases where it frame is queried from the graph,
but those seems to be in a code path where we need to ensure valid
dependency graph anyway.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5349
The issue was caused by dependency graph always ignoring animation
update when it is first time constructed. This was a way to make it
preserve unkeyed changes on undo/redo. This, however, made it so
changes of animation data itself (such as deleting/moving keyframes)
did not trigger animation update by the dependency graph.
This worked prior to copy-on-write because animation recalc flags
were stored in the DNA and never re-set on file/undo load. This was
giving dependency graph a clue that animation is to be re-evaluated
when operator explicitly asked to (more precisely, when such operator
was undone/redone).
This change makes it so original ID's recalc flags are storing
recalc flags when ID is tagged for update as an response to user
input. This way re-building dependency graph can force animation
to be updated on redo.
Tricky part here is that ID's recalc flag is no longer to be zeroed
when loading undo step (which is the same as reading .blend file).
This is something what works differently comparing to legacy
dependency graph, which was zeroing object's recalc flags there but
not animation data's recalc flags.
Shouldn't be causing issues, since unkeyed changes are not preserved
upon opening a file anyway, at least to my knowledge.
Related reports which are to be taken into account and verified
they are not re-introduced when making changes in the area:
- T63111: Auto-Bake stuck at constant re-rendering
- T54296: Cycles viewport render stuck on constant re-render
Reviewers: campbellbarton, brecht
Reviewed By: campbellbarton, brecht
Maniphest Tasks: T66325
Differential Revision: https://developer.blender.org/D5316
The amount of triangles drawn by the button depends on its `sizex`.
See:
```
immBegin(GPU_PRIM_TRI_STRIP, (sizex + 1) * 2);
```
Therefore the `sizex` cannot be 0.
Solution a bit similar to rB56b0cd1d.
Ref T67671
Reviewers: fclem, brecht
Maniphest Tasks: T67671
Differential Revision: https://developer.blender.org/D5347
Current frame is stored in a scene, and scene might have multiple view
layers. The inactive view layers were not informed about scene's frame
being changed, so when user switched back to view after changing scene
frame it was in an inconsistent state between current scene frame and
animation.
Now we tag scene for time changes, so dependency graph can catch up
and do proper update.
Currently tagging is from quite generic place. Probably better approach
would be to tag from where frame is actually being assigned. Downside
of this is that it's easy to miss some places.
Reviewers: brecht, mont29
Reviewed By: brecht
Maniphest Tasks: T66378
Differential Revision: https://developer.blender.org/D5332
Need to copy changes from original armature to evaluated one prior to
BKE_pose_where_is(), otherwise the pose matrix in pose channels will
not be correct.
Can not use dependency graph update here, since we must not re-evaluate
possible dependencies of the changed armature.
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T67507
Differential Revision: https://developer.blender.org/D5331
