The redo panel does not consider the position of the mouse.
So it is not possible to know the direction to redo the operator.
The solution is to add a new `direction` parameter that can be
saved and used for redo.
Differential Revision: https://developer.blender.org/D6852
NOTE: This change shouldn't have any visible effect. It's just the
first (easiest) step towards decoupling gizmo redraws from viewport
redraws.
We currently redraw the entire region whenever a gizmo needs redrawing,
which would be nice to avoid in the future, see T73198. The first step
towards this would be having a separate tag for them, which is what
this patch implements.
The term "editor-overlays" was chosen because for the forseeable future,
we'll also have to redraw non-gizmo overlays in-between drawing 3D and
2D gizmos. Namely annotations.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6838
Fix ReDo and create a new operator to display only the required properties.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6849
Don't use BKE_view_layer_context_active_PLACEHOLDER which is marked
as "never use this".
In fact, it isn't needed to lookup for camera in the tracking function
at all: camera object is always explicitly passed to it.
When an edge loop is fully occluded the direction of movement
is not calculated resulting in unpredictable behavior.
So always calculate the direction of the groups of edge loops
but continue preventing occluded edges from affecting `mval_dir`
(global) value.
Differential Revision: https://developer.blender.org/D5247
The current edge slide is executed in this sequence:
- traverses all edges to find the ones selected,
- traverses each vertex of the selected edges,
- traverses each linked edge of the vertex to finally execute the code.
However the list of vertices that are part of selected edges are already
stored in `EdgeSlideData` through the `TransDataEdgeSlideVert *sv;` member.
Therefore, the code can be simplified as follows:
- traverses all `sv` in `EdgeSlideData`,
- get the `sv->v` vertex to finally execute the code.
Differential Revision: https://developer.blender.org/D5277
Need to also offset markers in BKE_sequence_base_shuffle_time().
Also clarify/correct related comments.
Maniphest Tasks: T73014
Differential Revision: https://developer.blender.org/D6555
taking proportional size into account
Transform would always move all keyframes (e.g even when Proportional
size is 0.0).
'calculatePropRatio()' was setting td->factor correctly, but this was
not being considered in 'applyTimeTranslateValue()' if there was no
action [which greasepencil and masks do not have].
Maniphest Tasks: T55622
Differential Revision: https://developer.blender.org/D6697
The floating "Move" redo panel showed transform values with less
precision than in other places (e.g. sidebar and properties editor).
With Millimeters as unit it would even round to full integers, which
may be an issue since you typically work at higher precisions with this
unit.
Note that this only applies to the visual precision, internally we use
full floating point `float`s still.
Fixes T70367.
The `poll_modal_item` was too restrictive.
`!validSnap(t)` already solves these cases, but for better readability
(and efficiency), I found it best to keep the `tsnap.mode` test.
Note that this is a bit clumsy having both edit-mesh and mesh,
BKE_editmesh_ensure_autosmooth & BKE_editmesh_lnorspace_update
are often called together, these could be made into a single functions.
Currently the islands are created depending only on the visible UVs.
This can be confusing because compared to Edit Meshes, islands are created based on the selected elements.
T68284 shows a case where this confusion is observed.
Differential Revision: https://developer.blender.org/D6502
Currently the action channels are applied after the existing
transformation, as if the action controlled a child of the
bone. This is not very natural, but more importantly, the
transform tools are not designed to work conveniently with an
additional 'pseudo-child' transformation, resulting in effects
like an unexpected pivot location.
Implementing a Before mode that integrates the action channels
as if applied to a parent allows using the special transform
tool code intended for dealing with such constraints.
Note that in either mode, Action constraints should be added
in reverse order, putting a new constraint before the existing
ones that the Action was keyframed to work together.
In order to implement the option, extract a utility from
the Copy Transform constraint code for combining transforms
with special anti-shear scale handling that matches the
Aligned Inherit Scale mode.
The Before mode also requires switching the constraint to
the Local owner space, while the After mode can still use the
World space for efficiency as before. Since the constraint
doesn't have an Owner space option in the UI, this has to be
handled in an RNA setter.
For full backward compatibility, the original simple matrix
multiplication mode is preserved as the third option, but it
is not recommended due to creating shear.
Differential Revision: https://developer.blender.org/D6297
