The rotation direction was flipped recently.
This meant that rotation on a single axis gave negative results compared
with previous Blender releases.
This partially reverts a9b53daf23.
Differential Revision: https://developer.blender.org/D10299
This is an old bug (strange not to have been reported before).
To define the direction of rotation, the View Vector is used.
However, only the projection matrix was being considered, but in
perspective mode, the position of the pivot also matters.
This solution replaces {rBf9e994d0f463}.
That commit created an inverted orientation matrix but the 'Align to
Transform Orientation' operator doesn't work well with inverted matrices.
This new solution makes the rotate operator use the negative vector of the
axis.
This solution replaces {rBf9e994d0f463}.
That commit created an inverted orientation matrix but the 'Align to
Transform Orientation' operator doesn't work well with inverted matrices.
This new solution makes the rotate operator use the negative vector of the
axis.
In fact, the drawing was that of the local contraint axis (which is
summarized so as not to fill the screen with too much information).
Use the local contraint axis only when more than one object is selected.
Fix T81429.
This was an intentional change in rBc75a665c442e as it maintains the
same behavior as the constraint with or without modifier.
But from the user's PoV, it is better to keep the old behavior.
This makes drawing and behavior more intuitive.
This was the behavior in old versions of blender.
During a transformation operation, when pressing a contrain key, the chosen
orientation is that of the scene.
If you press the same key, the orientation changes to Global or Local.
However, if you choose another contrain axis with the orientation changed,
the orientation does not return to the set for the scene.
It remains Global or Local.
Now when changing a contrain axis, no matter what the current orientation is,
it always returns to the scene orientation.
This fixes and reverts commit c7287ffaec
Due to hardcodded keys, the modifier for auto contrain plane did not
work with custom keymaps and was in conflict with other keyitems.
Its usability is also confusing since it cannot be used without
`MOD_PRECISION`
But instead of removing it, it is better to make this modifier compatible
with custom keymaps and keep the conflict.
Now we have a better distinction of what is snap to grid and what is
snap to increments.
The code also allows the implementation of mixed snap for these modes.
This changes the drawing by drawing 2 circles with different intensity to
avoid any readability issues. This removes the need for Logic OP which is
implementation dependent.
Now all options for "snap to" affect the Vert Slide mode.
Reviewed By: campbellbarton
Maniphest Tasks: T66426
Differential Revision: https://developer.blender.org/D3440
This commit changes the behavior of 4 snapping combinations:
**1. While constraining to a plane, snap to an edge element:**
The snap is made at the intersection between the edge direction and the
constraint plane.
**2. While constraining to a plane, snap to a face element:**
The snap is made to the nearest point between the snap point and the
line that intersects the face plane with the constraint plane.
**3. While constraining to an axis, snap to an edge/line element:**
The snap is made to the nearest point on the axis to the edge/line.
**4. While constraining to an axis, snap to a face element:**
The snap is made at the intersection of the axis and the plane defined
by the face.
To avoid unpredictable jumps outside view boundaries, an alignment
check is made for each of these snapping combinations.
Resolve/fix T66422
Differential Revision: https://developer.blender.org/D5608
This feature was a hack to prevent mmb select to print the orientation from menu in pre 2.80 versions.
Removing this feature as it is no longer an issue.
