In rotation-based transform operations, the rotation axis can be
determined in two ways:
1. Through "orient_axis" (X, Y or Z)
2. Through "constraint_axis"
When the axis is obtained through the constraint, "orient_axis" is
ignored, and the angle may be negated depending on the view orientation
to match the mouse movement.
However, "orient_axis" never has its angle negated. Since the default
orientation is "View", the Z axis is inverted by default, aligning with
the mouse movement but not with the constraint axis.
This causes problems in the Redo Panel because the constraint fields
are hidden in the Rotation operation, so they need to be unset for the
Axis field to work. However, if you change the value of the Rotation
field, the object may have its rotation negated unexpectedly.
This issue was partially shown in #93078. Commit c30e6a37b0 attempted
to fix it by unsetting the constraint property when the Axis was
changed. However, this solution is incomplete: if the Axis is changed
and then reverted, the negative rotation issue reappears. In addition,
it has not been implemented in all operations.
This commit resolves the issue by reverting c30e6a37b0, aligning the
behavior of "orient_axis" and "constraint_axis", and unsetting
"constraint_axis" in `saveTranform`.
A downside of this solution is that it may break operators invoked from
Python that rely on "orient_axis" as the rotation axis, as the rotation
value now needs to be negated.
Pull Request: https://projects.blender.org/blender/blender/pulls/141101
Ensure 'constraint_axis' is unset in the Rotate operator when user
sets 'orient_axis' via the operator panel. This prevents unintended
overrides and aligns with expected behavior.
Change is limited to avoid affecting Shear, Rotate Normals, and
Transform, though Rotate Normals may benefit from similar handling due
to overlapping axis properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/114779
This changes the naming of "Custom Split Normals" or "Split Normals" to be "Custom Normals"
This addresses #134744, only UI naming has been adjusted.
Internal/External APIs are left unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/140440
This removes the include `UI_interface_layout.hh` from
`UI_interface_c.hh`, and in many places this swaps the include
from `UI_interface.hh` to `UI_interface_layout.hh`.
Also, cleanups some `UI_interface.hh` includes with
`UI_interface_icons.hh` or `UI_interface_types.hh`
Start frame and especially channel picking algorithm was sub optimal. It
is much better to leave final strip placement decision up to the user
in a form of modal operation.
Move Strips property is added to strip add operators. When enabled,
strip is added to position of mouse cursor, strip overlap is allowed
and strip position then can be changed during modal seq_slide
operation, which is invoked automatically.
This property is saved and drag and drop operations do not change it,
thanks to store/restore hack facilitated by operator customdata.
If translation after strips are added is canceled, added strips are
removed.
Effects with inputs do not use this feature, as their placement is
restricted in X axis and 99% of time, it would be placed directly above
the input strip.
Since the strips are to be placed to mouse position after "modal"
filebrowser is closed, `eventstate->xy` of `wmWindow` is used to read
mouse cursor position in operator exec function.
The seq_slide operator is invoked using `WM_operator_name_call_ptr()`,
as macros or other schemes do not fit this use-case.
Ref: #136515
Pull Request: https://projects.blender.org/blender/blender/pulls/138382
This feature allows you to change postion of origin/pivot for images
without changing their position.
It is implemented as property of transform operator. It is activated
by pressing `Ctrl + .` shortcut.
Move Origin item was also added to transform menu.
Origin can be snapped to 3x3 grid on strip image. This represents
most usual anchor points.
Ref: #134251
Pull Request: https://projects.blender.org/blender/blender/pulls/134206
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
Since 40eadc75be, `ED_workspace_status_text` is now called at the
beginning of the modal function.
This clears any custom keymap and redraws the status bar.
The `Edge Slide` and `Shear` operations only update the status bar if a
modal key is pressed (not on mouse move).
The solution to avoid losing custom modal keys, and not having to
update the status bar more often is: call `ED_workspace_status_text`
only when an operation that requires redraw is performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/136101
Patch #132957 added helpful UI feedback when attempting to rotate or
scale an object whose transforms are set to "only affect locations."
But it neglected to check for invalid trackpad rotations that are
affected the same way. This patch renames the original `HLP_ERROR` to
`HLP_ERROR_DASH` to distinguish it from a `HLP_ERROR` transform cursor
with no dashed line present, which matches trackball's normal state.
Pull Request: https://projects.blender.org/blender/blender/pulls/134653
This adds support for Transform MouseInputMode INPUT_ERROR using a new
transform cursor HLP_ERROR (dashed line ending with WM_CURSOR_STOP.
This is shown when attempting an object rotation or scale when
transforms are set to "Affect Only Locations". At this time the status
bar is also cleared and an warning message is shown.
Pull Request: https://projects.blender.org/blender/blender/pulls/132957
Ever since it was added to the VSE in e49fef45ce, edge panning would
break snapping -- edge panning a strip and then bringing it back would
cause snap code to trigger at incorrect locations. This is because the
edge pan system would update the `View2D` in `t->region->v2d.cur`, but
not mouse values, and so `t->values` would end up unchanged even while
the strip was moving.
e6a557952e fixed the issue for the node editor by recalculating mouse
input values when the view changed with `transformViewUpdate()`, but
since the code was separate from VSE, that fix did not get also get
applied here.
Although the code in `view2d_edge_pan_loc_compensate()` is mostly
identical between the two and so one possibility is to move it to
`transform_generics.cc`, adapting it to allow it to be used by both
spaces, custom transform data in the node editor additionally stores and
updates a `viewrect_prev` as mentioned in e040aea7bf, which VSE custom
data does not have. Since the fix is small enough and I don't want to
risk messing with other module code, I've opted to just copy the fix
over to VSE. If further bugs crop up in the future, we can consider
combining the code.
Also fix typo in `tranformViewUpdate()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/126471
This commit changes how users can interact with handles:
Unselected handles are not drawn anymore by default. Handles are bit
thinner. If handle can't be selected, because strip is too small,
it is not drawn.
When hovering over strip handle a cursor is changed to represent a
handle shape. It is possible to select 2 handles at once if strips are
adjoined.
When tweak event happens on unselected handle, handle selection is lost
ater tweaking.
This behavior can be disabled in preferences:
Editing > Video Sequencer > Tweak Handles.
Moving strips with G key works same way as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/109522
Changes:
- Add Vert Slide and Edge Slide to 'UV -> Transform' menu.
- Add a separator for Vert Slide and Edge Slide in the context menu.
- Don't display the "Correct UVs" option in the Redo menu of UV Editor.
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Discussed in #114646.
This commit transforms the "alt_navigation" option of the transform
operators into a new modal key item. "PASSTHROUGH_NAVIGATE"
In addition to cleaning up a lot of the code, it allows you to
customize the key chosen to navigate while transforming.
This is because `TRANSFORM_OT_edge_slide` has `OPTYPE_DEPENDS_ON_CURSOR`
flag set. Due to this, invoke call to loop-cut operator was not sent
from function `WM_operator_name_call_ptr_with_depends_on_cursor`.
Since `edge slide` operator does not depend on actual cusor position, we
can remove this operator flag to fix the problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/113140
`5ed35e` introduced the warning:
`RNA_boolean_set: TRANSFORM_OT_transform.use_duplicated_keyframes not found`
This was because the `TRANSFORM_OT_transform` did not pass
the `P_OPTIONS` flag to `Transform_Properties` to define
the `use_duplicated_keyframes` property.
In the animation transform code, `T_AUTOMERGE` was used
to indicate that the duplicated keys need to be merged.
In perparation of #111051, this no longer makes much sense because
in grease pencil we cannot have two keys in the same channel at the same
frame.
This PR replaces the `T_AUTOMERGE` flag in the animation code to
`T_DUPLICATED_KEYS` to indicate that the transform is being called
with duplicated keyframes.
Pull Request: https://projects.blender.org/blender/blender/pulls/111268
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
